作为一个最底层的程序员，我先记录一些只有底层程序员才会知道的事情。如果多年后，我违背自己进入这个行业的初心，走上管理岗位，也能回想起一些禁忌，避免一些错误。
其中最重要的就是这条：不要相信一个程序员在加班时间写出来的代码。
（软件工程的学说表明，连正常时间好好写的代码，也不要太相信。不过这不是本文的重点，略过不提。）
（不懂代码的人，看到本文中的Java代码可以略过，不影响理解。）
创造力的时限
写代码，与写文章、绘画、思考复杂问题，并没有本质上的区别，都是创造性的活动。
每个人的创造力，都会随着身体状态而波动。广为人知的是，一个人年老体衰后，相比年富力强时，创造力会急剧下降。其实，人每天的状态起伏，也同样会剧烈影响这一点。
如果是拧螺丝，那么在精疲力尽、拧不动以前，身体状态对结果不会产生太大影响。因为拧螺丝的指标非常简单——拧紧，要做的事也非常机械化——拧，直到它紧，换下一个。
但如果是写代码，有些事，是不能在状态不好的时候完成的。
比如，在Java里，遍历一个外部的List，做一些处理。如果状态不佳、做事前想的东西少了点，那么很可能直接这么做：
public void handleAList(List<Integer> aList) {
for (int i = 0; i < aList.size(); ++i) {
// Do sth with List#get(int)
}
}
这样做是从C/C++带来的一种很直观的做法。有什么问题吗？
假如外面传入的aList是一个ArrayList，那么List.get(int)的时间复杂度是O(1)，算上外面那重循环则是O(n)；而假如aList是一个LinkedList，那么List.get(int)的时间复杂度是O(n)，算上外面那重循环则是O(n2）！
（为不懂算法时间复杂度评估的人解释下：在这个场景下，O(n)代表最优、最快，而O(n2)代表不可接受地慢。）
如果时间充分，那么可以去查看handleAList()的调用位置，看看它传递的是哪种List；而如果思考得够充分，考虑到这两种情况都有可能，那么代码就会做兼容处理，改成这样：
public void handleAList(List<Integer> aList) {
for (int i : aList) {
// Do sth with i
}
}
这使用了for-each语法，实际上是用Iterator来做遍历，无论对哪种List都是总共是O(n)的开销。
注意，这通常不被看做一个bug，普通的黑盒与白盒测试都是无法发现的。只是你的App会比较卡，或者后台会比较慢。当需要解决这种性能问题时，可能需要非常经验丰富的程序员，在海量代码里找数周时间——而这一切，在开发之初，只要那个程序员状态好一点，就可以避免。
一个人，每天的创造力是有时限的。在时限外，他不再是一个优秀的创造者，而是一个笨蛋。
（为了便于理解，这个例子非常简单，以至于不够贴切。对Java来说，优先使用for-each或Iterator来遍历，已经是一个共识，是技术素养的一部分。）
失误率的飙升
程序员在写代码的过程中，每天做得最多的应该就是等价变换。
把
if (isSthTrue()) {
// Take some actions.
}
变换成
if (!isSthTrue()) return;
// Take some actions.
这只是最简单的一种逻辑反转，实际上还有更多、更复杂的形式。通过这类变化，对代码做出调整后，程序员可以把代码变得更好，或者做到以前不能做的事。
而在加班时间、大脑不那么清醒的情况下，很可能会写成这样：
if (isSthTrue()) return;
// Take some actions.
区别仅仅只是少了一个符号，而意义则完全走样。
这个例子比较简单，出错后也很容易在调试过程中发现、纠正。但是，请不要怀疑，的确会有程序员为了这么个简单的问题，调试整整一个晚上！
(、!、i，（字体未配置好时）本就难以区分，眼睛疲劳昏花时，在数百个字符里扫来扫去，难以分辨(!i中是否少了个符号，也并不奇怪。而如果换成第二天早晨，很可能只需要瞥一眼。
大多数管理者，往往会对熬夜的程序员给出一些肯定，并且允许第二天可以休息一天（有些甚至只给一早上）。但如果他们知道内情，会发现自己其实亏了一天。如果程序员正常下班，第二天花一小时解决这个问题，剩下的七个小时可以继续开发。
还有很多比这复杂得多的变换，或其它类型的代码改动，即使在大脑清醒的情况下也需要花费一些时间，认真思考、小心调试。而如果来了一个问题，你说“必须要今天下班前搞定”，那么程序员会很烦躁，并且越来越烦躁。
烦躁的后果
一件需要冷静思考、谋定后动的事，如果逼迫人们在烦躁的情况下去做，那么往往会得到意想不到的糟糕结果。
我有一位前同事，技术实力且不论，心性也不太稳（实际上，像我这种少年老成、未老先衰、找不到妹子都不急的青年，还真不多）。他是一个可以解决问题的人，但是在烦躁的情况下，也经常做出令我瞠目结舌的事。
比如，有一天，项目组要求某个bug必须解决。他搞到晚上9点还没搞定，找我帮忙。我当时水平也很差，不然也不会那时还在加班，没能帮他解决，只是因此而知道这件事。他后来在10点半时采用了一个规避方案，然后下班了事。
具体一点是这样的：在一个class中，有多个地方调用同一个Method。其它地方没有问题，唯独某个位置的结果不正确。他改成这样：
private boolean isSthTrue(int sth) {
// Implementation A
}
private boolean isSth1True() {
// Implementation B
}
private boolean isSth2True() {
// Implementation C
}
本来isSthTrue()是可以做通用判断的，他没有在规定时间内找到根本原因（Root Cause），实际上当时他也根本没有往发现根本原因的方向去查找代码，而是一晚上都在做一些无效的调试。最后没办法调试出好的结果，于是给出问题的地方一个特殊处理——新增了isSth1True()和isSth2True()去那个出错的地方顶替。结果，那个bug的确是解决了，但是后来带出来了另外一个bug。
不过他也达到了目的，当天下班了。
而后来，我在代码里发现了另外一组更早就有的接口。
private boolean isTrueSth1() {
// Implemented like B
}
private boolean isTrueSth2() {
// Implemented like C
}
我问了一下这两个Method的作者（另一位同事），他根本没有看到有isSthTrue()。
这件事的最终结果是，解决了一个bug，后来又引起了多个bug，连我也跟着一起焦头烂额。
借着这个例子，回头再说一下创造力的时限。
这位同事，之所以不去找Root Cause，是因为项目组的催逼和自身的烦躁，他平时是可以解决问题的。但是为什么一个简单问题会这么难解决，为什么代码里之前就有一套他要的Method，他却新写一个？
外部代码环境就不说了，这个class共有2000行。2000行可能并不是特别直观的数目，既不能说多，也不能说少，取决于这个class干什么事。
后来，另一个比较老道的同事，重构（refactor）了这个class，只用了不到500行——这就说明了一个问题，这个class之前就太过冗余。
约半年后，我水平也提高了些，总体的项目时间也松散了些，我花了六周重写（rewrite）了这个不大的代码库。这个class最终只用了100行，部分功能都独立封装到了其它class中。
如果之前，在这个代码库写就之初，就能有一个充分的时间做一个好的架构设计，不需要rewrite就可以只有100行；而如果时间不太充分，却能给应有的时间好好写，也起码能有refactor后的水平，也就是500行。无论是100行，还是500行，后面出的一大堆问题，都不会出现，或者更容易解决。
这个代码库是怎么来的？
当初某领导，交给了一个比较厉害的同事，只给一周时间。这位同事加班加点，一周当成两周用，从别的代码里剥离、拼凑出来了一个编译能通过的东西——这就是交给我们维护的代码库。
来自项目最底层的复仇
前面说的，无论是写出隐蔽的bug，还是解决一个带出俩，其实都是这类事情的阳光面。你没看错，这是阳光的一面。
还有我不想多说的阴暗面。
前面说的事情，没有一类是故意的。无论出事的原因是程序员的技术素养不足、加班情况下大失水准、还是原先的代码就非常容易诱导失误，都是程序员在认真努力的情况下，不可自控地犯错。
还有一类是故意的。
比如，去年（2015）携程那小哥儿，就是怒删数据库。当然，他不是为了加班严重而如何如何，而是心爱的运营妹子被公司某高层给……（另有一说，虽然有什么内部的QQ、微信截图，但这仍然是谣言，实际上是黑客攻击。）
什么程度的压迫，就会得到什么程度的反抗。
要知道，即使是很努力地去做，也仍然可以出各种问题。而如果要故意捣乱，很多手段，虽然不会引起老板的注意，甚至可以不被认真的代码审查者（reviewer）警觉，但是会客观地影响产品的品质，让用户讨厌一个产品，或者让一个爆款产品最终失败。
我只能说，就我个人而言，最多辞职，不会故意乱搞。这关乎职业道德，关乎我是否意念通达、心境澄明。(坐等穿越去修真:P）
但是，我不能用自己的道德准绳去要求别人，对吧？
而且，永远不要指望一个人在承受不道德的对待时，仍然能谨守原来的道德。
结语
作为一个软件项目的领导者，你在要求某个程序员加班时，其实就已经在冒险；而如果你经常这么干，不要奇怪为什么项目总是延期，或者一到关键时候，总有突发事件。
只要试验次数够多，可能性再小的事也会发生；而只要试验次数更多，小概率事件也会连续发生。
所以，最理智、客观的观念就是：欲速则不达，不要相信一个程序员在加班时间写的代码。
其中最重要的就是这条：不要相信一个程序员在加班时间写出来的代码。
（软件工程的学说表明，连正常时间好好写的代码，也不要太相信。不过这不是本文的重点，略过不提。）
（不懂代码的人，看到本文中的Java代码可以略过，不影响理解。）
创造力的时限
写代码，与写文章、绘画、思考复杂问题，并没有本质上的区别，都是创造性的活动。
每个人的创造力，都会随着身体状态而波动。广为人知的是，一个人年老体衰后，相比年富力强时，创造力会急剧下降。其实，人每天的状态起伏，也同样会剧烈影响这一点。
如果是拧螺丝，那么在精疲力尽、拧不动以前，身体状态对结果不会产生太大影响。因为拧螺丝的指标非常简单——拧紧，要做的事也非常机械化——拧，直到它紧，换下一个。
但如果是写代码，有些事，是不能在状态不好的时候完成的。
比如，在Java里，遍历一个外部的List，做一些处理。如果状态不佳、做事前想的东西少了点，那么很可能直接这么做：
public void handleAList(List<Integer> aList) {
for (int i = 0; i < aList.size(); ++i) {
// Do sth with List#get(int)
}
}
这样做是从C/C++带来的一种很直观的做法。有什么问题吗？
假如外面传入的aList是一个ArrayList，那么List.get(int)的时间复杂度是O(1)，算上外面那重循环则是O(n)；而假如aList是一个LinkedList，那么List.get(int)的时间复杂度是O(n)，算上外面那重循环则是O(n2）！
（为不懂算法时间复杂度评估的人解释下：在这个场景下，O(n)代表最优、最快，而O(n2)代表不可接受地慢。）
如果时间充分，那么可以去查看handleAList()的调用位置，看看它传递的是哪种List；而如果思考得够充分，考虑到这两种情况都有可能，那么代码就会做兼容处理，改成这样：
public void handleAList(List<Integer> aList) {
for (int i : aList) {
// Do sth with i
}
}
这使用了for-each语法，实际上是用Iterator来做遍历，无论对哪种List都是总共是O(n)的开销。
注意，这通常不被看做一个bug，普通的黑盒与白盒测试都是无法发现的。只是你的App会比较卡，或者后台会比较慢。当需要解决这种性能问题时，可能需要非常经验丰富的程序员，在海量代码里找数周时间——而这一切，在开发之初，只要那个程序员状态好一点，就可以避免。
一个人，每天的创造力是有时限的。在时限外，他不再是一个优秀的创造者，而是一个笨蛋。
（为了便于理解，这个例子非常简单，以至于不够贴切。对Java来说，优先使用for-each或Iterator来遍历，已经是一个共识，是技术素养的一部分。）
失误率的飙升
程序员在写代码的过程中，每天做得最多的应该就是等价变换。
把
if (isSthTrue()) {
// Take some actions.
}
变换成
if (!isSthTrue()) return;
// Take some actions.
这只是最简单的一种逻辑反转，实际上还有更多、更复杂的形式。通过这类变化，对代码做出调整后，程序员可以把代码变得更好，或者做到以前不能做的事。
而在加班时间、大脑不那么清醒的情况下，很可能会写成这样：
if (isSthTrue()) return;
// Take some actions.
区别仅仅只是少了一个符号，而意义则完全走样。
这个例子比较简单，出错后也很容易在调试过程中发现、纠正。但是，请不要怀疑，的确会有程序员为了这么个简单的问题，调试整整一个晚上！
(、!、i，（字体未配置好时）本就难以区分，眼睛疲劳昏花时，在数百个字符里扫来扫去，难以分辨(!i中是否少了个符号，也并不奇怪。而如果换成第二天早晨，很可能只需要瞥一眼。
大多数管理者，往往会对熬夜的程序员给出一些肯定，并且允许第二天可以休息一天（有些甚至只给一早上）。但如果他们知道内情，会发现自己其实亏了一天。如果程序员正常下班，第二天花一小时解决这个问题，剩下的七个小时可以继续开发。
还有很多比这复杂得多的变换，或其它类型的代码改动，即使在大脑清醒的情况下也需要花费一些时间，认真思考、小心调试。而如果来了一个问题，你说“必须要今天下班前搞定”，那么程序员会很烦躁，并且越来越烦躁。
烦躁的后果
一件需要冷静思考、谋定后动的事，如果逼迫人们在烦躁的情况下去做，那么往往会得到意想不到的糟糕结果。
我有一位前同事，技术实力且不论，心性也不太稳（实际上，像我这种少年老成、未老先衰、找不到妹子都不急的青年，还真不多）。他是一个可以解决问题的人，但是在烦躁的情况下，也经常做出令我瞠目结舌的事。
比如，有一天，项目组要求某个bug必须解决。他搞到晚上9点还没搞定，找我帮忙。我当时水平也很差，不然也不会那时还在加班，没能帮他解决，只是因此而知道这件事。他后来在10点半时采用了一个规避方案，然后下班了事。
具体一点是这样的：在一个class中，有多个地方调用同一个Method。其它地方没有问题，唯独某个位置的结果不正确。他改成这样：
private boolean isSthTrue(int sth) {
// Implementation A
}
private boolean isSth1True() {
// Implementation B
}
private boolean isSth2True() {
// Implementation C
}
本来isSthTrue()是可以做通用判断的，他没有在规定时间内找到根本原因（Root Cause），实际上当时他也根本没有往发现根本原因的方向去查找代码，而是一晚上都在做一些无效的调试。最后没办法调试出好的结果，于是给出问题的地方一个特殊处理——新增了isSth1True()和isSth2True()去那个出错的地方顶替。结果，那个bug的确是解决了，但是后来带出来了另外一个bug。
不过他也达到了目的，当天下班了。
而后来，我在代码里发现了另外一组更早就有的接口。
private boolean isTrueSth1() {
// Implemented like B
}
private boolean isTrueSth2() {
// Implemented like C
}
我问了一下这两个Method的作者（另一位同事），他根本没有看到有isSthTrue()。
这件事的最终结果是，解决了一个bug，后来又引起了多个bug，连我也跟着一起焦头烂额。
借着这个例子，回头再说一下创造力的时限。
这位同事，之所以不去找Root Cause，是因为项目组的催逼和自身的烦躁，他平时是可以解决问题的。但是为什么一个简单问题会这么难解决，为什么代码里之前就有一套他要的Method，他却新写一个？
外部代码环境就不说了，这个class共有2000行。2000行可能并不是特别直观的数目，既不能说多，也不能说少，取决于这个class干什么事。
后来，另一个比较老道的同事，重构（refactor）了这个class，只用了不到500行——这就说明了一个问题，这个class之前就太过冗余。
约半年后，我水平也提高了些，总体的项目时间也松散了些，我花了六周重写（rewrite）了这个不大的代码库。这个class最终只用了100行，部分功能都独立封装到了其它class中。
如果之前，在这个代码库写就之初，就能有一个充分的时间做一个好的架构设计，不需要rewrite就可以只有100行；而如果时间不太充分，却能给应有的时间好好写，也起码能有refactor后的水平，也就是500行。无论是100行，还是500行，后面出的一大堆问题，都不会出现，或者更容易解决。
这个代码库是怎么来的？
当初某领导，交给了一个比较厉害的同事，只给一周时间。这位同事加班加点，一周当成两周用，从别的代码里剥离、拼凑出来了一个编译能通过的东西——这就是交给我们维护的代码库。
来自项目最底层的复仇
前面说的，无论是写出隐蔽的bug，还是解决一个带出俩，其实都是这类事情的阳光面。你没看错，这是阳光的一面。
还有我不想多说的阴暗面。
前面说的事情，没有一类是故意的。无论出事的原因是程序员的技术素养不足、加班情况下大失水准、还是原先的代码就非常容易诱导失误，都是程序员在认真努力的情况下，不可自控地犯错。
还有一类是故意的。
比如，去年（2015）携程那小哥儿，就是怒删数据库。当然，他不是为了加班严重而如何如何，而是心爱的运营妹子被公司某高层给……（另有一说，虽然有什么内部的QQ、微信截图，但这仍然是谣言，实际上是黑客攻击。）
什么程度的压迫，就会得到什么程度的反抗。
要知道，即使是很努力地去做，也仍然可以出各种问题。而如果要故意捣乱，很多手段，虽然不会引起老板的注意，甚至可以不被认真的代码审查者（reviewer）警觉，但是会客观地影响产品的品质，让用户讨厌一个产品，或者让一个爆款产品最终失败。
我只能说，就我个人而言，最多辞职，不会故意乱搞。这关乎职业道德，关乎我是否意念通达、心境澄明。(坐等穿越去修真:P）
但是，我不能用自己的道德准绳去要求别人，对吧？
而且，永远不要指望一个人在承受不道德的对待时，仍然能谨守原来的道德。
结语
作为一个软件项目的领导者，你在要求某个程序员加班时，其实就已经在冒险；而如果你经常这么干，不要奇怪为什么项目总是延期，或者一到关键时候，总有突发事件。
只要试验次数够多，可能性再小的事也会发生；而只要试验次数更多，小概率事件也会连续发生。
所以，最理智、客观的观念就是：欲速则不达，不要相信一个程序员在加班时间写的代码。
