你真的理解BUG吗？

创业十年，内心无感，曾经那些没命的日日夜夜，现在看起来都无力感知了。只是觉得现在要停下来，做一些新的深的思考，想想要把自己未来的5-10年安置在哪。

没有正式的告别，三个月前，我就再没有写过代码了。2004年入行，至今截断，自然而然，心不再念。在别人的眼里，我一直是一个风骚十足的程序员，一言难尽，想想，用几篇文章告别一下，或许会更好。一句话刷脸：我是大全栈，写过太多的语言，客户端，服务器，App，Flash，嵌入式，都参与过产品开发，不仅仅是接触过而已。

我问过很多人同一个问题，就是你觉得你人生最缺乏什么？程序员是多么可爱的一群人，我总觉得他们内向，压抑，直到没主见，或不轻易发表，所以我大部分时候是听不到直接的回答。当然，我的答案是人生最缺乏静静。所以，请先静静，想想你理解的BUG是什么。

这是一个多么重要的问题，我们要把它当做一个有生命的东西，想想，它的诞生，它存在的意义，它的个性，它的消亡，如何相处。因为它将陪伴整个职业生涯，你会经历很多项目，但是你却永远无法摆脱它。

比尔·盖茨说：“我们总是高估未来两年的变化，却低估未来十年的变化。不要让自己无所作为.”，这句话让我内心震惊，之后总是念念不忘。迁移过来，我们可以说：“我们总是高估自己每写一行代码的价值，低估它现在和未来的危害.”

BUG是什么？

行业类比，大部分人都会觉得建筑行业和程序行业是最相近的一个行业，很多环节都是想通的，只是我们是否想过，为什么建筑行业没有BUG，我们软件行业怎么到处都是BUG，有些开发团队甚至觉得解决了很多BUG是很有成就的事情，这太可悲了，感觉整个打开的方式都不对。下面两张图就是现状。

井然有序的建筑工地 面条代码们

所以说，软件行业极速发展，突飞猛进，但整体的成熟度也十分堪忧，从业人员的素质也非常参差不齐。高楼大厦一栋栋的竖立起来，而我们编个Hello World都可能有一堆的BUG。更别说，软件行业混乱的工种，角色随便串，CTO、架构师、设计师、程序员、产品经理、测试，虽然都有它们的定义，但是实际上，每家公司职责定位估计都不一样。

CTO不编码很正常，但是CTO不做一些CODE REVIEW，我无法接受。CTO不能只看黑盒和结果，业务成功只是一部分职责，为中国培养更多的优秀的程序员是更大的部分。回到这两张图，最值得我们借鉴的是，建筑行业随时随刻都要确保整洁干净的施工现场，那么你的架构是否清晰，你的CODING现场是否经常整理呢？

BUG如何产生的？

我觉得对于BUG来源这一点，绝大部分的程序员都是理解错误的，以至于把人生托付在了错误的技能路线上。没日没夜的编码，然后再继续没日没夜的和BUG斗争，不断提升自己的编码技能。但是，这一切都没有用的，你这样只能是等待熬出来的机会，但是其实这个行业是有很多脱颖而出的机会的，你没有获得，绝对不是因为你不够努力，主要是因为你太笨。上图。

错误的BUG漏斗

我们都认为BUG是由于编码导致的吗？上面这个图是完全倒置了的。我从业这么久，干得最爽的几件事情如下：

1.倒逼产品经理不断的理清或调整需求

2.倒逼产品经理严肃的对需求进行优先级排序

3.GITHUB的各种开源项目都了解和研究一下，绝不重复发明轮子，简单架构

4.保持每个类在300行代码

对的，请把图倒置过来，那样才是正确的BUG来源，需求不正确或不清晰，是导致BUG的最大原因，然后才是架构、设计、编码。所以也请把自己的精力重新分配一下，多多辅助产品经理出更正确的需求，多多了解需求，多多研究一些开源项目，对高质量代码，对代码可读性，保持高度的追求。

如何与BUG相处？

比较喜欢王垠，引用他的两句话。

说：“有位文豪说得好：’看一个作家的水平，不是看他发表了多少文字，而要看他的废纸篓里扔掉了多少’，我觉得同样的理论适用于编程。好的程序员，他们删掉的代码，比留下来的还要多很多。如果你看见一个人写了很多代码，却没有删掉多少，那他的代码一定有很多垃圾。”

说：“那么提高程序正确性最有效的方法是什么呢？在我看来，最有效的方法莫过于对代码反复琢磨推敲，让它变得简单，直观，直到你一眼就可以看得出它不可能有问题.”

所以要摆脱BUG，除了需求的把握之外，对于CODING层面，就是努力保持施工现场整洁干净，需要不断的重新设计和重构，转变心理，不以实现的功能数为指标，而是以保持高质量的代码为衡量指标。把握好如下4个步骤。

1.探讨需求，深入了解和挑战需求

我们只有盖5层楼的资源，但是产品经理绝对会出20层楼的需求。所以保持需求更正确，以及研发资源重点投入在哪些需求上，是整个部门的共同目标，不要期待产品经理能搞定这件事情，这是不可能的。需求讨论，不仅仅只是宣讲，而是一场交易。

2.统一可靠的架构

架构是骨架，一定要做到清楚的定义了如何嵌入一个需求/业务单元的代码。多研究GITHUB上的一些优秀的开源项目，几千颗星的要做到关注，超过1万颗星的要深入了解。一个优秀的架构师，绝对是程序员们的巨大福利。

3.简单设计，填写代码

一定要认知到代码的性质，如果是流程代码，则一定要保证瘦，如果是业务代码，则一定要保证封装，如果是算法代码，则一定要保证无状态隔离。如果你写代码，对代码的性质无感，那只能说明你的路还很远，因为你写的代码很可能无法支持单元测试，也不好调试。

4.不断重新设计和重构代码

将施工/CODING的复杂程度降到最低，虽然不一定要上单元测试，但是代码必须保证能够支持单元测试，做到很容易加新需求，也很容易DEBUG老代码。小债很容易积累成大债，我说的300行，这里肯定不仅仅是行数，而是需要你不断的重新设计和重新架构，不信你试试能不能做到300行。

说出来的道理都很简单，无可厚非，但是是否真实的理解了它们的意义，这就是区别。