总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 jianshu.com/p/d531ddbbd7f3 「匿蟒」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

作为一个最底层的程序员，我先记录一些只有底层程序员才会知道的事情。如果多年后，我违背自己进入这个行业的初心，走上管理岗位，也能回想起一些禁忌，避免一些错误。

其中最重要的就是这条：不要相信一个程序员在加班时间写出来的代码。

（软件工程的学说表明，连正常时间好好写的代码，也不要太相信。不过这不是本文的重点，略过不提。）

（不懂代码的人，看到本文中的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，连我也跟着一起焦头烂额。

不解决问题地debug

借着这个例子，回头再说一下创造力的时限。

这位同事，之所以不去找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）

但是，我不能用自己的道德准绳去要求别人，对吧？

而且，永远不要指望一个人在承受不道德的对待时，仍然能谨守原来的道德。

结语

作为一个软件项目的领导者，你在要求某个程序员加班时，其实就已经在冒险；而如果你经常这么干，不要奇怪为什么项目总是延期，或者一到关键时候，总有突发事件。

只要试验次数够多，可能性再小的事也会发生；而只要试验次数更多，小概率事件也会连续发生。

所以，最理智、客观的观念就是：欲速则不达，不要相信一个程序员在加班时间写的代码。

文章目录
  1. 1. 创造力的时限
  2. 2. 失误率的飙升
  3. 3. 烦躁的后果
  4. 4. 来自项目最底层的复仇
  5. 5. 结语