程序员在加班时间写出的代码质量无法保证

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

其中最重要的就是这条:程序员在加班时间写出的代码质量无法保证

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

(不懂代码的人,看到本文中的Java代码可以略过,不影响理解。)

创造力的时限

写代码,与写文章、绘画、思考复杂问题,并没有本质上的区别,都是创造性的活动。

每个人的创造力,都会随着身体状态而波动。广为人知的是,一个人年老体衰后,相比年富力强时,创造力会急剧下降。其实,人每天的状态起伏,也同样会剧烈影响这一点。

如果是拧螺丝,那么在精疲力尽、拧不动以前,身体状态对结果不会产生太大影响。因为拧螺丝的指标非常简单——拧紧,要做的事也非常机械化——拧,直到它紧,换下一个。

但如果是写代码,有些事,是不能在状态不好的时候完成的。

比如,在Java里,遍历一个外部的List,做一些处理。如果状态不佳、做事前想的东西少了点,那么很可能直接这么做:

    public void handleAList(List 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 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)

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

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

结语

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

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

所以,最理智、客观的观念就是:欲速则不达,程序员在加班时间写出的代码质量无法保证

本文文字及图片出自 www.jianshu.com

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注