网络空间的攻防对抗看似高深，但追踪溯源下去很可能是由一个小问题引发的。一枚小小的Bug，可能引发"蝴蝶效应”，牵动广泛关注。

新年伊始，我们一起来看看一位资深程序员关于Bug的年终思考。

"小小一枚Bug，认真处理了

一个新的技术创新点可能被激发

一个新专利可能诞生

一次新的架构升级可能由此起航"

怎么认识Bug?

写程序，这个多年前只有科学家才能干的事情，越来越普及。可谓：旧时王谢堂前燕，飞入寻常百姓家。

bug本意为臭虫，是指潜伏在程序命令中的问题，像臭虫一样可恶，所以程序界以这个意为程序中的问题。bug也像幽灵一样，让每个程序员如坐针毡、如履薄冰。

首先，它是一个客观的存在，绝对唯物。我们首先要认识到：程序员出bug并不可耻，人哪有不出错的时候呢？既然是客观存在的，我们怎么来对待bug这种事物？常见的状态有三种：

① 极端克制

② 相杀相爱

③ 习以为常

先说第一种：虽然bug在所难免，但我们还是可以通过努力，极端克制，做到bug尽量少出现，这是一种处事态度。有些人利用更多休息时间能让自己维护的代码bug极少出现，克制自己不要好大喜功,一件件事在客观规律周期内做好。甚至有人就算时间周期有限，也可以高质量无bug情况下完成任务。这类人，有态度，有担当。优秀的程序员，多半从这类人群中诞生。

第二种，对待bug的态度是相杀相爱，很憎恨但可容忍。显然，相对第一种人他们态度是明确的：错误是要犯的。这类人群很大，原因也很简单，多数人都很懒，这东西和聪明程度没啥关系。所以写代码的时候可以普普通通搞架构，普普通通想算法，普普通通写代码。完事之后发现：唉？这东西居然有问题？先忍忍，先忍忍，默念几分钟之后解脱了自己。这个不可怕，但可怕的事，他忘了这件事……最后居然很坦然地把问题埋藏在内心深处，不出大问题，永远不去解决。其实程序员把功能做完是知道哪儿有坑的，只是经过测试了，他认为这东西测试都没出现，抱着侥幸心理，结果某个时候就可能捅个大篓子。

第三种，对bug习以为常。听起来简直无法忍受是不是？是的，这类人很多。在他们脑海里，出现bug正常啊，不写几个bug都没存在感。甚至为了实现一个功能不惜留下很多坑。为了所谓的抢时间，赶快上一个功能，留下一堆关于修复bug的故事。这个问题是要深思的：要么这个功能在客观情况下根本完成不了老板让你搞，是老板的问题；要么这东西你知识面太窄想的太简单，你自己的问题；要么好高骛远好大喜功地去刷存在感，也是你自己的问题。这类人不会算账，你本应该用1天写个功能，非得半天写完，最后不得不多用1天解决bug。结果是时间多花了，自己的口碑下去了，对外项目口碑下去了。

很多情况下，管理者不自省、程序员不自省，长期以往，市场给你的反馈是一条负斜率的曲线，而且不可逆。

怎么处理Bug?

优秀的程序员，是真正把bug当做臭虫的，他们眼睛里留不得这粒沙子。

所以，他们会极端克制bug的出现。就算出现了，他们也可能寝食不思，就因为这粒沙子的存在。这东西不需要有多聪明，是一种态度。其实一个bug的出现，是给你了一次机会，一次层次越级的机会。工程师的本质工作是解决问题，出现问题不解决是可耻的。

当一个bug出现的时候，首先要查明原因。这个步骤，就像侦探分析案情的过程。是对你判断定位能力的考验。很多时候，解决起来代码几行，但是查问题用了几小时。这里考验了你几点：对自己写过的代码的再思考的能力、逻辑思考能力。好的程序员会根据问题出现的场景，第一感觉就可以定位到是哪个模块的什么文件出了问题。如果你做不到，就可能是对代码不够熟悉，对使用的框架理解有问题。问题出现之后，接下来思考一下怎么来解决，这里是普通程序员和优秀程序员升级的分水岭。

为什么一个简单的bug就是你技术提升的机会呢？普通的人会想，我堵住这个窟窿就可以了，解决了一个bug，可量化的出现在你的工作报告中。但优秀的人是可以看透这个bug背后的问题，比如架构是不是有问题？算法是不是有问题？使用的框架是不是有问题？根据经验，一般此时是可以成长的最快的机会。如果你看到了架构出了问题，你敢不敢给他重构换一种更好更稳当的架构？如果算法出了问题，你敢不敢去研究新的算法替换掉它？如果你敢去这么做了，假以时日，你不想成为高手都难。但绝大多数人，原地的修复了这个窟窿再也没有前行，由此失去了成为高手的可能。人最害怕的是做一件件重复的事情，且自我认为做的多就是好。你解决了1000个bug，和你写一个框架的更新，谁的技术含量更高呢？答案显而易见。

深度处理bug，需要做好这几点：

1. 面向技术方案解决问题。不要面向问题本身，问题的出现，有其必然原因。此时多思考，把解决一个问题解决成一个方案。

2. 按理想来设计技术方案。如果本身技术方案或者框架出现了问题，在理解它的前提下，按最优化的理想方案画出方案图，这样才能跳出原来的圈子。

3. 按工程思维来实施方案。架构里面有很重要的一种思维是面向领域建模。用在实际中是一样的，它的思路不一定是一个很大的系统。分解成某个领域内也可以被分割成某个领域。试着想想如果在理想情况下出了一种技术方案或者框架，本次由于工程上时间上的要求无法完成怎么办？很简单，把理想情况下适合当下的领域的工作完成。通俗一点，就是常说的把这个场景的粒度分离出来，留个接口，供外面使用就好了。以后再持续的在整体理想的设想框架内其它方面逐步按这个逻辑完成即可。

所以，小小一枚bug。认真处理了，一个新的技术创新点可能被激发；一个新专利可能诞生；一次新的架构升级可能由此起航。

常有人说：“所有的成长，都是反人性的”。你需要克服懒惰、欲望，更加勤奋地思考、执行。成功都是从小事做起，作为程序员，我想没有比bug更小的事情了吧。

关于作者

葛山 奇安信集团网络安全专家，拥有专利70余项、授权30余项。

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。