今天是:

实验室资讯网

解Bug和写Bug,哪个更难?

实验室资讯网时间:2020-06-16 点击: 百度搜索 | 必应搜索 | 搜狗搜索

【导读】相信本身做代码开发的,很大很大一部分时间都是在 Debug 自己的代码,分为好几种情况: 自己做代码设计、编写、Debug。 只编写代码,同时 Debug 自己的代码。 Debug 别人的代码。 通常如果是按照职业来区分的话,有分为 FAE(技术支持)、CE(Components Engineer))、RD 等等,FAE 和 CE 偏向于只解决问题,并不去做代......
TAG标签: 架构师 解Bug 写Bug Bug Debug

解Bug和写Bug,哪个更难?

相信本身做代码开发的,很大很大一部分时间都是在 Debug 自己的代码,分为好几种情况:

自己做代码设计、编写、Debug。

只编写代码,同时 Debug 自己的代码。

Debug 别人的代码。

通常如果是按照职业来区分的话,有分为 FAE(技术支持)、CE(Components Engineer))、RD 等等,FAE 和 CE 偏向于只解决问题,并不去做代码的设计与开发,这个大概都知道,RD 即 Research And Development engineer,也就是常说的研发工程师。

虽然,RD 很多时候也是要搞别人的锅,但是总归会有一部分比例得要进行开发性的设计与实现的,而且同样是解决问题,有时候的一些侧重点和 FAE、CE 并不是非常一致。

本文准备说说这几个职位的主要职能和侧重点,同时也谈谈自己的一些想法。

FAE、CE 前面即是说,完全的偏向于纯解决问题,也就是处理 RD 留下的烂摊子。这个部分的主要工作包括但不限于下面几个层级:

对客户问题进行诊断、分流,有点儿像分级诊疗的意思,问题是多种多样的,天南海北的哪儿都有,得要快速的定位到问题在哪里,首先得确定大的模块。

对分好类的问题进行检索(人脑加资料库),看是否能够找到之前已经解决过的问题,尝试找到相似的问题来进行下一步分析。

尝试找到问题的根本原因(Root cause),如果已经有存在的案例,那么尝试 fix,如果是比较简单的逻辑问题,也可以尝试直接 fix。

如果无法短时间内 fix,那就往 RD 导入问题进行进一步的支持。

评估并提出合理的部分客户需求,导入给 RD,拒绝不合理的客户需求。

其它若干大大小小的问题。

难点在于哪里呢?首先一个就是问题的分类,因为客户报过来的问题那是不管哪个模块的问题都有的,就拿我所在的手机 Camera 模块来讲,基本上就很容易出现仿若跨行一般的 Camera 类的问题,不得不说现在的分工协作已经细到了极其发指的程度。

所以呢,这个分流的过程就是很难的一件事,你得要通过现象、log 来进行分析判断,同时客户问题一天那可是好几个,并且有时间限制,如果心理素质不过关的话心态很容易就崩了,一旦心态崩了你的效率就会极大的降低。

还有就是时间和效率,因为但凡是实时周期性的玩意儿,它的 log 不是按 KB 来算的,那动辄就是 0.X GB,问题容易复现还好,不好复现的直接奔着 2GB 去了,试问,就这种 log 你没点强大的逻辑分析能力和心脏,那怕是 Hold 不住啊,往往问题分析不会是那么简单的几个小时就可以搞定的事情,所以时间还有经验就显得极其重要了,不熟悉这个系统的话找一个问题点差不多等于大海捞针。

所以某种程度上来讲,这部分工作都是对身体和心理双重的刺激,我觉得这部分工作要想做好,难度还是有相当程度滴。

再说 RD,从前面的也可以推知,RD 这部分主要就是深度挖掘、解决问题,这部分也是有很大概率要解别人写的 bug,还有就是发现问题点不等于可以解决它,很多时候你发现了问题的本质,但是并没有办法短时间内想到解决方案,不过总体上来讲这一部分还是要比 FAE、CE 的难度小那么一丢丢。

然而,万事皆有例外,他们给过来的问题并不一定真正的找到了问题点在哪里,可能是找错了方向,这个时候有一定的可能会产生误导,要能够及时发现并把逻辑分析拉回到正确的道路上来,从这种情况来看需要对系统有更加深入一点的了解。

除了解决别人的问题,还要能够解决自己的问题,当然这部分就比较简单了,不说了。没那么简单的是 RD 会需要自己进行代码的编写调试,也就是开发部分,相信做软件的都知道,会看代码和会写代码,那玩意儿就是两个差不多独立的事件了(夸张),代码编写也分为几个层次:

在已知功能已知设计的情况下实现代码逻辑,这部分就是我们说的完全的码农状态,基本是体力活,需要注意的就是实现细节,虽不是特别简单,但是我觉得已经足够简单了。

只知道功能和大体的框架走向,代码模块结构需要自己去构思实现,哎,这个就有点意思了,他不是完全的 0->1,但是要考虑与现有系统的兼容,也要考虑实现出来之后的扩展性、可调试、可维护性、可读性等方面,要比上一个难一点。

只知道功能,需要自己去构思实现框架来完成整个功能,这个是最有意思的,差不多是完全的 0->1 的过程了,难度最高以至于有极高的掉头发风险,我觉得这个是 RD、FAE、CE 里面难度最高的以至于接近一丢丢架构师的水平了。

架构师,这玩意儿我就不放在 RD 描述里面了,高山仰止,还无法形容。

毫不要脸的说,我可能就是在第二层到第三层的过渡中间,仍需艰苦奋斗。所以对于我来讲,总体上开发性的任务难度是最高的,解决问题难度次一点点,不过后者对心理素质身体素质要求我觉得会略微高那么一点点。

话说,每个程序员都有一个架构师的梦,我呢,老实说也有,但是我不太一样,我并不觉得我一定要实现这个梦,我的想法是能够参与进去一个从零到一的、世界范围内广泛使用的软件架构开发与实现,哪怕是做一颗安安静静的螺丝钉也好,当然如果能够到扳手、脚手架、地板、承重墙甚或更高的层级就更好了。可以说现在我仅仅实现了一半,就是广泛使用这一点,想来在我退休之前能够搞出一点事情就是最好不过的了,小系统的架构师想必我还是有信心达到的,但是广泛使用就算了,毕竟自己也就是没几斤没几两的。

--------

(本文来源:百问科技)

(责任编辑:子豪)

引用地址:

TAG标签: 架构师 解Bug 写Bug Bug Debug
顶一下
(0)
0%
踩一下
(0)
0%
免责声明: 除标明《实验室资讯网》原创外,本网部分文章转载自其它媒体,转载目的在于传递更多信息, 并不代表本网赞同其观点和对其真实性负责,且不承担此类作品侵权行为的直接责任及连带责任。 如其他媒体、网站或个人从本网下载使用,自负版权等法律责任。如涉及作品内容、版权和其它问题, 请在30日内与本网联系,我们将在第一时间删除内容!
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
栏目列表
推荐内容
手机查看本页
扫描二维码,
在手机上查看本页!