讨论工程质量与加班

在大众眼里, 程序员是加班很多的, 一个新的朋友刚认识我时一般就会问我两个问题：你加班很多吧？ 你头发还茂密吗？
本篇以自己有限的经验, 聊一下加班这些事, 特别是加班与工程质量之间的关系。

首先, 本篇并不否认加班是必要的, 毕竟任何领域想取得超凡的成就, 都需要付出艰苦卓绝的努力。但是, 当努力的方向错误的时候, 越努力, 离成功便会越远。

加班, 都用来干嘛了？

回想自己的工作经历, 真正因为紧急故障或者项目进度的原因, 而加班的情况并不多, 自己也没有遇到特别push进度的团队。大部分加班的原因, 是bug, 本来已经排好了本周的工作, 但是因为无法预料的bug, 只好先放下手头的工作, 先fix好bug, 这样一来, 手头的工作便耽误了, 只好晚上或者周末去完成任务。

bug引起的原因可能是各方面的：

• 自己的代码引发的bug
• 自己的上游的bug, 影响到自己

bug, 还经常集中在一个大的变更之后, 例如某个系统某个部分的重构或者重写。所以, 想要安安稳稳过bug较少的小日子, 光是自己努力是不够的, 需要整个团队的努力才可以。

写的快就一定质量低吗？

我曾经在接手某个同事的糟糕的代码之后, 向他委婉地提出代码质量的问题, 他承认了代码糟糕的事实, 解释道"当时写很急, 一周内写完上线"。我当时认同了他的说法, 觉得也蛮有道理, 也许确实是当时赶进度吧。

后来, 我就彻底否定了我之前的想法, 在经历过一段时间打磨代码质量, 学习怎么写更优雅代码过程之后, 自己代码能力得到提升, 其实就发现写代码的速度跟代码质量并无矛盾关系。

就写出糟糕代码质量的人而言, 即便给他足够的时间, 我想无非就是多了一些手工测试的时间, 上线前多fix一些明显的bug, 但其代码结构, 模块拆分, 单元测试等等, 个人观点并不会有太大的进步。因为这些, 不是几天的功夫就可以提升很多的。

所以, 如果代码质量低的原因归结为时间不够的话, 其实在一定程度上阻挡了团队和个人进步可能性。因为当频繁地出现工程质量问题时, 便自然地想到通过加测试时间, 加QA人力的方式去解决问题。也许某种程度是有用的, 但这种方式确是效率十分低下的, 甚至因为加QA同学的缘故, 沟通成本还直线上升, 得不偿失。

我们应当做的, 是提升团队和个人的能力, 否则呢 ?

不好的工程质量对团队士气的影响

最好的提升士气的方式, 就是打胜仗。而频繁的工程质量问题, 在软件工程领域, 就是一个又一个的败仗。

• 频繁发生bug, 用户的不满会转移到团队成员身上。
• 紧急hardcode修复问题, 导致系统的坏味道更多, 系统更加混乱, 更容易发生问题。
• 长期hardcode和修复问题, 团队成员感觉得不到成长, 感觉工作没有意义。

长此以往, 团队接下来的结局也就不难推测了, 那就是分崩离析。

美好的希望

或许我们有一天可以少一些无意义的加班, 可以在下班陪伴家人和男女朋友, 发展自己的兴趣爱好。又或者进一步学习/探索先进的技术, 以备在未来的工作中创造更大的价值。