作为程序员，应该更关注代码质量还是只需要完成功能就好了？

编写高质量可维护的代码既是程序员的基本修养，也是能决定项目成败的关键因素，本文试图总结出问题项目普遍存在的共性问题并给出相应的解决方案。

1. 程序员的宿命？

程序员的职业生涯中难免遇到烂项目，有些项目是你加入时已经烂了，有些是自己从头开始亲手做成了烂项目，有些是从里到外的烂，有些是表面光鲜等你深入进去发现是个“焦油坑”，有些是此时还没烂但是已经出现问题征兆走在了腐烂的路上。

国内基本上是这样，国外情况我了解不多，不过从英文社区和技术媒体上老外同行的抱怨程度看，应该是差不多的，虽然整体素质可能更高，但是也因更久的信息化而积累了更多问题。毕竟“焦油坑、Shit_Mountain 屎山”这些舶来的术语不是无缘无故被发明出来的。

Any way，这大概就是我们这个行业的宿命——要么改行，要么就是与烂项目烂代码长相伴。 就像宇宙的“熵增加定律”一样：

孤立系统的一切自发过程均向着令其状态更无序的方向发展，如果要使系统恢复到原先的有序状态是不可能的，除非外界对它做功。

面对这宿命的阴影，有些人认命了麻木了，逐渐对这个行业失去热情。

那些不认命的选择与之抗争，但是地上并没有路，当年软件危机的阴云也从未真正散去，人月神话仍然是神话，于是人们做出了各自不同的判断和尝试：

• 掀桌子另起炉灶派：
  • 很多人把项目做烂的原因归咎于项目前期的基础没打好、需求不稳定一路打补丁、前面的架构师和程序员留下的烂摊子难以收拾。
  • 他们要么没有信心去收拾烂摊子，要么觉得这是费力不讨好，于是要放弃掉项目，寄希望于出现一个机会能重头再来。
  • 但是他们对于如何避免重蹈覆辙、做出另一个烂项目是没有把握也没有深入思考的，只是盲目乐观的认为自己比前任更高明。
• 激进改革派：
  • 这个派别把原因归结于烂项目当初没有采用正确的编程语言、最新最强大的技术栈或工具。
  • 他们中一部分人也想着有机会另起炉灶，用上时下最流行最热门的技术栈（spring boot、springcloud、redis、nosql、docker、vue）。
  • 或者即便不另起炉灶，也认为现有技术栈太过时无法容忍了（其实可能并不算过时），不用微服务不用分布式就不能接受，于是激进的引入新技术栈，鲁莽的对项目做大手术。
  • 这种对刚刚流行还不成熟技术的盲目跟风、技术选型不慎重的情况非常普遍，今天在他们眼中落伍的技术栈，其实也不过是几年前另一批人赶的时髦。
  • 我不反对技术上的追新，但是同样的，这里的问题是：他们对于大手术的风险和副作用，对如何避免重蹈覆辙用新技术架构做出另一个烂项目，没有把握也没有深入思考的，只是盲目乐观的认为新技术能带来成功。
  • 也没人能阻止这种简历驱动的技术选型浮躁风气，毕竟花的是公司的资源，用新东西显得自己很有追求，失败了也不影响简历美化，简历上只会增加一段项目履历和几种精通技能，不会提到又做烂了一个项目，名利双收稳赚不赔。
• 保守改良派：
  • 还有一类人他们不愿轻易放弃这个有问题但仍在创造效益的项目，因为他们看到了项目仍然有维护的价值，也看到了另起炉灶的难度（万事开头难，其实项目的冷启动存在很多外部制约因素）、大手术对业务造成影响的代价、系统迁移的难度和风险。
  • 同时他们尝试用温和渐进的方式逐步改善项目质量，采用一系列工程实践（主要包括重构热点代码、补自动化测试、补文档）来清理“技术债”，消除制约项目开发效率和交付质量的瓶颈。

如果把一个问题项目比作病入膏肓的病人，那么这三种做法分别相当于是放弃治疗、截肢手术、保守治疗。

2. 一个 35+ 程序员的反思

年轻时候我也是掀桌子派和激进派的，新工程新框架大开大合，一路走来经验值技能树蹭蹭的涨，跳槽加薪好不快活。

但是近几年随着年龄增长，一方面新东西学不动了，另一方面对经历过的项目反思的多了观念逐渐改变了。

对我触动最大的一件事是那个我在 2016 年初开始从零搭建起的项目，在我 2018 年底离开的时候（仅从代码质量角度）已经让我很不满意了。只是，这一次没有任何借口了：

• 从技术选型到架构设计到代码规范，都是我自己做的，团队不大，也是我自己组建和一手带出来的；
• 最开始的半年进展非常顺利，用着我最趁手的技术和工具一路狂奔，年底前替换掉了之前采购的那个垃圾产品（对的，有个前任在业务上做参照也算是个很大的有利因素）；
• 做的过程我也算是全力以赴，用尽毕生所学——前面 13 年工作的经验值和走过的弯路、教训，使得公司只用其它同类公司同类项目 20% 的资源就把平台做起来了；
• 如果说多快好省是最高境界，那么当时的我算是做到了多、快、省——交付的功能非常丰富且贴近业务需求、开发节奏快速、对公司开发资源很节省；
• 但是现在看来，“好”就远远没有达到了，到了项目中期，简单优先级高的需求都已经做完了，公司业务上出现了新的挑战——接入另一个核心系统以及外部平台，真正的考验来了。
• 那个改造工程影响面比较大，需要对我们的系统做大面积修改，最麻烦的是这意味着从一个简单的单体系统变成了一个分布式的系统，而且业务涉及资金交易，可靠性要求较高，是难上加难。
• 于是问题开始出现了：我之前架构的优点——简单直接——这个时候不再是优点了，简单直接的架构在业务环境、技术环境都简单的情况下可以做到多快好省，但是当业务、技术环境都陡然复杂起来时，就不行了；
• 具体的表现就是：架构和代码层面的结构都快速的变得复杂、混乱起来了——熵急剧增加；
• 后面的事情就一发不可收拾：代码改起来越来越吃力、测试问题变多、生产环境故障和问题变多、于是消耗在排查测试问题生产问题和修复数据方面的精力急剧增加、出现恶性循环。。。
• 到了这个境地，项目就算是做烂了！一个我从头开始做起的没有任何借口的失败！

于是我意识到一个非常浅显的道理：拥有一张空白的画卷、一支最高级的画笔、一间专业的画室，无法保证你可以画出美丽的画卷。如果你不善于画画，那么一切都是空想和意淫。

然后我变成了一个“保守改良派”，因为我意识到掀桌子和激进的改革都是不负责任的，说不好听的那样其实是掩耳盗铃、逃避困难，人不可能逃避一辈子，你总要面对。

即便掀了桌子另起炉灶了，你还是需要找到一种办法把这个新的炉灶烧好，因为随着项目发展之前的老问题还是会一个一个冒出来，还是需要面对现实、不逃避、找办法。

面对问题不仅有助于你把当前项目做好，也同样有助于将来有新的项目时更好的把握住机会。

无论是职业生涯还是自然年龄，人到了这个阶段都开始喜欢回顾和总结，也变得比过去更在乎项目、产品乃至公司的商业成败。

软件开发作为一种商业活动，判断其成败的依据应该是：能否以可接受的成本、可预期的时间节奏、稳定的质量水平、持续交付满足业务需要的功能市场需要的产品。

其实就是项目管理四要素——成本、进度、范围、质量，传统项目管理理论认为这四要素彼此制约难以兼得，项目管理的艺术在于四要素的平衡取舍。

关于软件工程和项目管理的理论和著作已经很多很成熟，这里我从程序员的视角提出一个新的观点——质量不可妥协：

• 质量要素不是一个可以被牺牲和妥协的要素——牺牲质量会导致其它三要素全都受损，反之同理，追求质量会让你在其它三个方面同时受益。
• 在保持一个质量水平的前提下，成本、进度、范围三要素确确实实是互相制约关系——典型的比如牺牲成本（加班加点）来加快进度交付急需的功能。
• 正如著名的“破窗效应”所启示的那样：任何一种不良现象的存在，都在传递着一种信息，这种信息会导致不良现象的无限扩展，同时必须高度警觉那些看起来是偶然的、个别的、轻微的“过错”，如果对这种行为不闻不问、熟视无睹、反应迟钝或纠正不力，就会纵容更多的人“去打烂更多的窗户玻璃”，就极有可能演变成“千里之堤，溃于蚁穴”的恶果——质量不佳的代码之于一个项目，正如一扇破了的窗之于一幢建筑、一个蚂蚁巢之于一座大堤。
• 好消息是，只要把质量提上去项目就会逐渐走上健康的轨道，其它三个方面也都会改善。管好了质量，你就很大程度上把握住了项目成败的关键因素。
• 坏消息是，项目的质量很容易失控，现实中质量不佳、越做越臃肿混乱的项目比比皆是，质量改善越做越好的案例闻所未闻，以至于人们将其视为如同物理学中“熵增加定律”一样的必然规律了。
• 当然任何事情都有一个度的问题，当质量低于某个水平时才会导致其它三要素同时受损。反之当质量高到某个水平以后，继续追求质量不仅得不到明显收益，而且也会损害其它三要素——边际效用递减定律。
• 这个度需要你为自己去评估和测量，如果目前的质量水平还在两者之间，那么就应该重点改进项目质量。当然，现实世界中很少看到哪个项目质量高到了不需要重视的程度。

3. 项目走向衰败的最常见诱因——代码质量不佳

一个项目的衰败一如一个人健康状况的恶化，当然可能有多种多样的原因——比如需求失控、业务调整、人员变动流失。但是作为我们技术人，如果能做好自己分内的工作——编写出可维护的代码、减少技术债利息成本、交付一个健壮灵活的应用架构，那也绝对是功德无量的。

虽然很难估算出这究竟能挽救多少项目，但是在我十多年职业生涯中，经历的和近距离观察的几十个项目，确实看到了大量的项目正是由于代码质量不佳导致的失败和遗憾，同时我也发现其实失败项目的很多问题、症结也确确实实都可以归因到项目代码的混乱和质量低下，比如一个常见的项目腐烂恶性循环：代码乱》bug 多》排查问题耗时》复用度低》加班 996》士气低落……

所谓“千里之堤，毁于蚁穴”，代码问题就是蚁穴。

接下来，让我们从项目管理聚焦到项目代码质量这个相对小的领域来深入剖析。编写高质量可维护的代码是程序员的基本修养，本文试图在代码层面找到一些失败项目中普遍存在的症结问题，同时基于个人十几年开发经验总结出的一些设计模式作为药方分享出来。

关于代码质量的话题其实很难通过一篇文章阐述明白，甚至需要一本书的篇幅，里面涉及到的很多概念关注点之间存在复杂微妙关系。

推荐《设计模式之美》的第二章节《从哪些维度评判代码质量的好坏？如何具备写出高质量代码的能力？》，这是我看到的关于代码质量主题最精彩深刻的论述。

4. 一个失败项目复盘

先贴几张代码截图，看一下这个重病缠身的项目的病灶和症状：

• 这是该项目中一个最核心、最复杂也是最经常要被改动的 class，代码行数 4881；
• 结果就是冗长的 API 列表（列表需要滚动 4 屏才能到底，公有私有 API 180 个）；

• 还是那个 Class，头部的 import 延绵到了 139 行࿰