原创版权标志从实战解决问题过程中了解程序员解决问题的方式

作者:codexia  发表时间:2016/11/24 21:11:46  阅读:471
[摘要]程序员在面对问题的时候基本都是直接面向问题,解决问题,而不是论和自己有没有关,以一起协作解决问题为目标。如果说了什么对方的问题,也只是为了定位问题,没有推脱责任的说法。
文章来源:C++技术网 原创文章版权所有,未经授权,禁止转载。

    昨天到今天解决了一个困扰已久的问题。在此记录一下。因为这个过程,我发现了一些程序员解决问题的方式,当然也就是我自己为蓝本来说明。

    昨天下午去深圳横岗六约公交站出差,给公交站的充电桩升级程序。经过一番的工作之后,都升级好了程序。然后刷卡试验,结果发现密码错误。按照之前的安装手册里的说明,参数都设置好了。但是依然密码错误。这个卡是我的软件发的,桩上是读卡的。卡里的密码要和桩上预设的一致,卡才能被正确识别。出现卡密码错误问题,其实双方都可能有问题。

    但是,参数设置完了,却还是不行。我开始质疑是不是我的软件有问题。也就是那一瞬间的质疑。然后又被我自己否决了。毕竟都发了那么多卡,不至于会在这个基本问题上翻船的。因为我作为技术人员过去,他们都重点关注我。而且,既然我好不容易去一趟,决不能不解决问题吧。这会让公司形象大减,对我自己来说,那也是打击哦。我是核心技术人员,怎么能解决不了这个问题呢?而且,我必须解决问题。

    现场的客户人员态度都挺好,去的时候穿的少,晚上好冷,吹成了SB。哈哈哈。还好他们给了一件工衣挡了一下风。

    在解决问题之前和解决问题之后,我都不会指责谁的问题。就是客户的问题,也不能有任何的抱怨。如果是其他程序的问题,那也是很正常的。如果是自己的问题,更没有必要担心害怕。出问题是很正常的,关键是在问题出现之后能不能及时积极的去解决问题。可能很多人还是喜欢推脱责任,喜欢将与自己无关的事情高高挂起。而程序员一般都是已解决问题为己任,非常积极,请勿有任何的抱怨对待程序员。虽然程序员脾气好,只是懒得去计较这些事情。

    昨天就是升级好了程序,后台和充电桩的。然后理清了公交站的运行情况,然后将日志拿回来了,晚上就回来分析。加班?当然啦,解决问题要趁热打铁。

    因为在桩上面的错误不明确,也让我们不好排查问题。所以,我建议同事将程序的错误提示区分一下,然后今天给了客户升级。昨天不仅是去升级,更主要的是教会了客户自己升级。这样我们给了程序,他们可以自己升级,不用我们跑过去了。

    因为昨天分析日志的时候,发现日志数据量太大,没有归类,导致分析非常困难。所以就连夜将日志打印功能进行了归类。将断网的日志单独抽离出来了。今天给客户远程升级了后台程序。这样我远程控制,得到了预期的日志,然后开始了分析。

    下面是分析的记录:

程序员解决问题的方式点滴分享程序员解决问题的方式点滴分享

    其实断网问题已经积累好久了,总是没有很好的解决。代码也查不出什么问题,很是郁闷。昨天去升级程序的时候,就有点隐隐的担心可能是什么低级错误。但是就是不知道可能出现在哪里。

    为了缩小错误的范围,所以要精确的寻找问题。所以,将日志分类之后,可以很快的找出规律。我跟踪了一个桩的日志,然后发现1-2分钟内一定会断网。这个很没有道理。我开始还以为所有桩都会出现断网情况。不过我想,可能只是一部分的断网。所以,我们开始来看每一个桩的情况。结果发现很多桩并没有断网过。将69个日志都分析了之后,只有26个枪有断网情况。也就是说,有一部分一直都不会断网。

    既然如此,那就很可能不是软件的问题。不过,这么多桩,还是不知道为什么呀。我知道一个桩有多个枪,每一个枪都是独立的IP。我将断网的枪根据编号进行分组,结果发现很多都是一个组里的,并不是零散的分布。这能说明什么呢?

    如果是程序出错,那肯定不会分组的。因为每一个充电枪都是一个独立的IP,在程序里是没有组的概念的,只是在物理的设备上放在了一个机柜里而已。所以,如果形成了分组的断网,那很可能是和桩本身有关。这里印证了我隐隐约约的担心的低级错误。只是还是不太清楚。

    我开始尝试怀疑是不是硬件错误,毕竟是桩那里出现了集中现象,可能是硬件引起的,当然也可能是其他与桩相关的东西,比如设置参数之类的。

    去与同事讨论这个发现的时候,恰好他属于负责硬件相关的开发。当然我很明确表示,我们是协作去解决问题,不是推脱责任。我只是说出我的推断。不过我不知道硬件的运作,怀疑一下也是很自然的。当然我是去请教他这方面,去验证我的想法,毕竟他是专家。

    不过,也没得到验证。还是不太确定。似乎峰回路转走回了死胡同。不过因为我发现了这个分组错误的现象,比之前线索还是多了许多。我们只能从网络这方面去检查桩的情况。我们想到的就是ping。

    然后我将断网的桩列出来给工作人员,并请他将断网的桩的IP都对应的抄下来。然后我们去测试网络。如果是硬件问题,可能就会在ping的过程中掉包。

    当他在抄IP的时候,给我打电话,说很多桩IP都重复了。问我要不要改过来。我说先不改,先将这些断网的桩IP抄下来再说,后面再统一改。然后我得到了IP和桩对应的关系,结果出现断网的IP都被重复设置过了。这一下击中了分组出现断网的情况。也让我知道了那个低级错误是什么了。

    局域网大量ip重复,导致ip冲突,引起断网提示。因为局域网里分配IP是大概1-2分钟一次,所以也就在分配IP的时候导致一些IP冲突而产生延迟。也就超时提示断网了。
    程序员在面对问题的时候基本都是直接面向问题,解决问题,而不是论和自己有没有关,以一起协作解决问题为目标。如果说了什么对方的问题,也只是为了定位问题,没有推脱责任的说法。
    这是程序员解决问题的方式。我是程序员,哈哈哈。当然在解决问题的时候,有些人会有责任关系的担心,有事不关己高高挂起的做法,可能会有情绪变化,但是程序员一般都会忽略别人情绪,而是针对问题来解决问题的。

    在这个过程中,我关注了我情绪的变化,开始的信心满满,然后出现问题的开始质疑,质疑自己的程序是否有问题,然后被自己否决,再去寻找问题。但是至始至终,都没有去抱怨谁,没有推脱责任,而是就问题本身去寻找解决问题。如果没有解决问题,也不会气馁,只是有点失落。然后还会继续找问题,以解决问题为使命。

    最后最重要的一点,和程序员一起共事的时候,别用情绪眼光来看问题,以免气着自己,或者降低了解决问题的效率哦。

文章来源:C++技术网 原创文章版权所有,未经授权,禁止转载。



返回顶部

关于我们 QQ群 广告服务 增值服务 捐款资助 版权声明 RSS订阅 站点地图 百度网站地图 意见反馈
鄂ICP备14001349号-2, Copyright © 2014-2017, CJJJS.COM/CJJJS.CN, All Rights Reserved

在线提问
问题标题:
问题描述:(简陋的描述会导致问题被最后回答、没有针对性回答甚至无法解答。请确保问题描述的足够清楚。)

C++技术网群聊