不要相信程序员在加班时间写的代码

更新日期: 2019-05-22阅读: 1.5k标签: 程序员

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

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

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

(不懂代码的人,看到本文中的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)

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

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


结语

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

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

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


链接: https://www.fly63.com/article/detial/9087

1024节日的由来,程序员的你最想对自己说的是什么?【1024程序员节日】

吃饭睡觉写代码,基本都程序猿的大部分生活了,作为从事最累的职业之一的我们终于有了自己的节日,那就是1024。1024向程序员致敬,向自己致敬,向未来致敬。

一个程序员的运气有多重要

互联网注定是一个不能安宁的行业,有一些人在努力引领变化,有一些人在努力适应变化,有一些人在被时代的浪潮淘汰。这个世界唯一变的就是变化,人生唯一不能停的就是学习,说到底,要想不被淘汰,只有不断的学习。

如何成为10倍速的程序员

国外有个词叫做10x Programmer,直译是以一当十的程序员。我并不认为一个技术大牛能完成10个普通程序员的工作,技术大牛会花1/10的时间把工作做完,然后用剩下9/10的时间平衡生活、爱好和未来,所以我仅把10x Programmer叫做10倍速的程序员。

优秀的程序员是不看源码的,这是真的么?

仍是要永远 ctrl+v,永远拿来主义。仍是要时时刻刻对美好满怀期待,对未来充满渴望,对经典心怀敬畏。要记住啊,能原创而不原创,有源码而远源码,才是最无知的成熟。

优秀程序员的十个习惯

优秀程序员有哪些好的习惯:1. 想清楚,再动手写代码,2. 不交流,就会头破血流,3. 文档没人看,但还是要写,4. 一定要写注释,5. 别指望需求会稳定

程序员和用户

我曾经说过,程序员不是一般的人,是具有某种超能里的人。但问题是,程序员往往意识不到自己的这种特异功能,在他们的眼里,会认为自己很普通,跟常人一样,所以,程序员能做到的事情

一个程序员送给大学生弟弟的那些话

分析自己的处境; 做适合自己的选择; 以成长为目的,担负起更多责任,打破对做事的认知; 把握机遇,去锤炼自己; 抛弃一些懒惰,多一些积极;向牛逼的人靠近,向给你提供条件帮助你学习的老师靠近。以上结合了我自己的经历,希望文章能更形象。

程序猿跳槽季,为什么你的薪水总升不上去?【转载】

现在身处跳槽高峰季,作为即将跳槽的我,在这里分享几点建议给大家。众所周知,找工作的前提是面试,面试的前提是过了简历,过了简历的前提是你怎么投。

程序员养生攻略_程序员防猝死指南

程序员在其职业生涯中,健康问题尤为突出。但是大部分程序员只顾码字,却往往忽略了自身的健康问题。这或许是因为写代码太入神,也或许是因为来自老板的压力太大。

程序员笔名、别名_适合程序员的英文名字

一个厉害的程序员,都会有一个牛逼哄哄、有辨识度有个性的英文别名。在公司同事中很更好的称呼,这篇文章翻译整理了一下适合程序员的英文名字

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!