程序员debug三大定律

声明

首先声明，本文其实是写给管理程序员的人看的。如果你是程序员，看了以后可能会对你的职业生涯产生负面影响，慎入!

至于其他闲杂人等，可以了解一下码农的工作状态，看个乐子。

什么是debug？

程序员的debug，即除虫，把没有按照预期方式正常运行的代码块修正。

这个过程分为3个步骤：

1. 找到它

2. 想办法解决它

3. 确认它已经被解决（并且没有引入其它问题）

debug并不是容易的事。很多时候找到bug并不难，但很多时候，真的很难！即使找到了，也通常不容易解决。最糟糕的莫过于，有时候难以验证是否已解决。

值得庆幸的是，大多数的bug都比较简单。因此，虽然海量的bug填满了程序员的工作时间，但软件项目仍然能跑。

至于能不能按时跑完，那就要看程序员的效率了。

一个程序员，效率的最大因变量，毫无疑问是个人能力。

如何提高自己的能力？这是程序员职业生涯中永恒的追求。本文避而不谈，只说程序员自己不能改变的一些外部环境因素。

第一定律：效率并不是时间的均匀分布

对于有正常生活规律的人来说，这条可以这么描述：

• 早上debug，解决一个大于一个

• 下午debug，解决一个等于一个

• 晚上debug，解决一个小于一个（注：可以小于零）

毫无疑问，debug是一项智力活动。头脑清醒的时候，效率最高；头脑不清醒的时候……嘿嘿……我们喜欢称之为埋雷。会不会在下一次以另一种形式，炸到自己或后面的人，这就管不了了，至少当前的这坑填了。

很多bug，不好好解决，就是这样

当今码农界，弹性工作制（免费加班）已经蔚然成风，996已成做项目的常态。

但是，朝九晚九，甚至到凌晨，真的能解决？请看上图。

晚上搞到精疲力尽，第二天的状态真的正常？请看上图。

周末仅休息一天，真的能不影响下周的状态？请看上图。

996，强行把早上变成了“晚上”，把晚上变成了“下午”。短期来看也许效果不错，但是长期下来，如果人员不流动，或者项目与项目之间有足够的间隙，那么必然整个团队都效率低下。并不是说解决的bug少了、慢了，而是让bug总量增多了。

八小时工作制不仅仅是曾经的人文追求，也具备生物学上的合理。人，毕竟是一种周期性的生物。

第二定律：效率和程序员的心情正相关

一直以来，在文学和影视作品中，都宣称着：

• 诗人的心情，会影响诗歌的意境（语文试卷上不知写过多少遍）

• 乐手的心情，会影响音乐的内涵（“高山流水”的典故）

• 厨师的心情，会影响食物的味道（还记得那碗“黯然销魂饭”？）
  ……

  
  

星爷英姿时瞻仰

一首诗，同一个开头，可以有不同的结尾；同一个意思，可以用不同方式表达——这是语言赋予的高自由度所致。而诗歌无论是叙事的、咏志的、还是抒情的，都是智力创造的结果。从脑中创造的东西，很难不受当时脑中充斥的“心情”的影响。

对debug来说也是一样。

编程语言的自由度虽然比自然语言低多了，但是还是非常高。同一个小功能，让不同的人来从零开始实现，一定会有不同的代码。也许实现同一功能的软件，没有什么好坏之分，但编译之前的代码，一定有高下之别。

找bug时，看到整洁的代码，和看到乱七八糟的代码，效率是完全不同的；解bug时，是写整洁的代码，还是写乱七八糟的代码，心情真的很重要。

这就是为什么很多新兴互联网公司要效仿Google那样的顶级企业：水果随便吃、饮料随便喝、甜点随便拿——开心就好。这也是为什么最近在炒作一个职业，叫程序员鼓励师……

当然了，前面说的是程序员认真负责debug的情况，不包括携程那小哥儿。

在内部搞技术破坏，真的很简单

携程对那个程序员干了什么?

第三定律：效率和分配时间的自由度正相关

debug是程序员把既有代码加载到大脑中模拟执行并且找出其中错漏的一个过程。

如果有多个bug，那么解决它们的过程，类似于操作系统的进程调度。程序员需要根据bug的优先级、难易度、相关性、重要性等，自行分配处理问题的顺序以及时间，以达到最高的总体解决效率。

而这时候，就怕有个人站出来，说那个bug必须先解决；更怕有一群人依次站出来，各自指出一个bug要求先解决。

每当从一个bug切换到另一个时，代码会在大脑中重新加载。遗憾的是，人的大脑在这件事上，比电脑差太多，会异常耗时。因此，bug顺序的外在调整，必然带来效率的损失；而长期如此，待解bug的队列，只会越来越长。

当程序员在大脑中重新加载一段程序，你知道他要死多少脑细胞吗？

debug并不是一件越给压力、越催促就越能越快速完成的工作。需要被鞭子撵着干活的，是驴、是牛，不是脑力劳动者。

最高效的办法，就是让程序员自己分配自己的时间，只注重结果。

第零定律

短期高效，往往是长期低效；长期高效，往往是短期低效——以上三条“定律”，都不过是这一条的具现。人的脑力劳动，就是这么样一种活动，不可能长短兼得。

既希望得到短期高效，又希望收获长期高效，强行违背规律的结果，就是徒劳无功。

今天给你10万，或者一年内，分批给你200万，怎么选？

一年内给你200万，和十年内给你5000万，怎么选？

十年内给你5000万，和百年内给你20亿，怎么选？

人不可能在职场工作百年，而时间也一定会带来货币贬值。但是，最值钱的资产，不会是当前的存款，而是未来稳定的现金流。

只要不是临时的开发Team，那么长期而稳定的高效，才是真正的高效。

不仅仅是debug，coding的工作也有类似规律。debug是在既有代码的基础上，依次解决一些被打包为bug的问题。而coding则是，把一件较大的开发任务，拆分为一个个小的task，然后逐一去完成。

也不仅仅是写代码，所有脑力劳动，都有类似规律。

我到底在表达什么

如果你是管理程序员的人，读完了并且不认同，我建议多想想。

这不是什么新鲜的论调，三十年前的《人月神话》《人件》，都提到过类似的思想。直到今天，很多管理者都承认这俩的地位，但仍然对压榨员工的生命力奉行不悖——因为这样有最好看的短期成果可以呈现给上级。

而今，整个中国互联网都构建在对程序员的压榨上，好像没有什么不合理。似乎加班是王道，主动加班才是上进。

但是，任何强行达到短期高效的手段，最终都将损失更多的长期利益。要么欲速则不达，要么降低软件的质量，要么留不住优秀的员工。

加班、高压、催逼，这些手段，可以做好一个产品，不能做好一个系列；可以做一个品牌，不能做好一个品牌。

如果不能尊重自己手下的脑力劳动者，那么你作为管理者，一生成就也就那样了。

如果你是程序员，呃……我建议你当没看见，继续“上进”去吧。

屁股决定脑袋，屁股应该决定脑袋。在其位谋其政，不在其位不谋其政。

没事像我一样看技术以外的书，想技术以外的事，结果就是对老板的诸多做法不以为然，反驳起来还头头是道。最终……

人就应该知足。脑力劳动者往往有智商上的优越感，这已经是难以根治的劣根性了。如果再加上情商上的过度自信，那真是可以目中无人了。

请虚怀若谷，假装不知道吧。