你见过的“垃圾”项目是这样子么？-技术圈

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「183」篇原创敬上

大家好，我是Z哥。

我相信每一位程序员最怕遇到代码质量堪忧的项目，毕竟增加一个同样的功能，在一个代码整洁、清晰的项目里与在一个代码混乱不堪的项目里，效率和质量上的差距达到一个数量级一点也不奇怪。

但是残酷的现实是，“垃圾项目”到处存在，哪怕是大厂里也不例外。毕竟，没有人天生就能写出无比优雅的代码，都是通过写“垃圾代码”一步一步成长起来的，唯一的区别可能就是成长的速度不同罢了。

一个项目如果运气好，未来成为受重视的项目，那么它还有机会摆脱不少的“垃圾代码”，但是如果没那么好运，那就苦了后来人了。

所以，如果你是一位新人程序员，那么我得提醒你，一定要有一个合理的预期，这个合理的预期就是——与垃圾代码长期为伴。因此，如果你以后因为遇到“垃圾代码”而破口大骂，这是不讲“码德”的。什么？那么索性跳槽？你怎么能确保下一个接手的项目会更好？

在Z哥看来，一个项目走向“垃圾”、人见人弃的地步，原因只有一个，代码垃圾，而什么样的代码才算垃圾代码？这就多了，我与你分享一些常见的。

01 组件颗粒度过大

现在三层架构基本已经成为一个基础共识了，只要不是太古老的项目，不太会存在UI、业务逻辑、数据操作写在一起的情况。（虽然架构设计方面的后起之秀很多，但是三层架构因为更容易理解，所以市场占有率依旧最高）

但是三层架构的每一层又该如何进一步细分，如何建模？还没有能够成为共识的统一标准或者最佳实践出来。

所以，很多项目在经历了一年以上的业务发展和变更后，业务逻辑层往往率先沦陷，开始出现大对象，成为开发效率的瓶颈。

近几年的火热的领域驱动设计其实已经开始深入到每一层的内部该如何划分上了。但是离达到共识还有很长的路要走。

02 API数量泛滥

有一些经验的程序员们会用一招来让自己在垃圾代码中游走自如。这招就是尽量通过“增加”的方式实现功能而不是“修改”历史代码。

这种方式的确能避开很多“屎坑”，但是从长期来看，这大概率是在创造新的“屎坑”。

某些核心class里几百个function，成千上万行的代码就是这么来的。

03 低内聚、高耦合

「高内聚、低耦合」是软件开发领域的一条黄金法则，相信每一位程序员都知道。但是现实是，很多项目都存在低内聚、高耦合的问题。

出现这个问题倒也不是说是由于大量的重复代码导致，而是过度的追求消除重复代码。盲目的追求减少重复代码，自然会导致代码被过度拆分，原本一个完整的业务处理清清楚楚，硬生生被拆分到多个function里去。

复用当然是好的，但应该有个前提条件：不增加系统复杂度的情况下的复用。如果不这样做，损害了稳定性，增加了复杂性，还会造成代码可读性降低。

04 业务逻辑和程序处理逻辑纠缠

Z哥认为，代码的作用其实就分为两种，业务逻辑和程序处理逻辑。前者体现的是这个软件的现实价值，后者则是让软件能在计算机上run起来必不可少的部分。

程序处理逻辑主要就是各种数据的存取、dao操作、序列化/反序列化、缓存操作，以及异常处理、参数和返回值准备等等。

如果程序的处理逻辑与业务逻辑混在一起，就好比芝士拌饭，都黏在一起，随便改一小点功能就扯出一大段代码要看。

更加可怕的是，如果里面还充斥着大量Magic Number，比如if (errCode == 50001) 。那你得忍住不要骂人。

05 又长又宽的if else

这点其实长期以来就是一直被人诟病的陋习。但是这又几乎是每一门编程语言都有的语法，那么问题到底在哪里？

因为不管是if else也好，还是switch case也好，其实是一种硬编码的方式。这就会导致它不容易被修改。

想象一个场景：某个枚举增加了一个新的值，这个时候你需要将原先判断这个枚举的所有if else都检查一遍，以确保新增的业务能正确执行。真正做过这件事的人相信有过深刻地感受，如果这个枚举被用到几十上百的地方，检查一遍外加弄懂上下文，估计至少半天时间就没了，而且很有可能最终还是漏改或者改错什么。

以上就是一些常见的垃圾代码的样子。那么，在你的工作中如果遇到充满垃圾代码的垃圾项目该怎么办呢？从流派上说，主要有三大流派，激进派、保守派、重头再来派。

保守派的做法，主要是从局部修改问题代码入手。比如前面提到的这些“垃圾”代码，常见的处理思路是以下这些。

01 业务层禁止层内依赖

你可以留意观察一下，业务层内的内部相互依赖，是导致代码高耦合低内聚的主要推手。因为这会导致一个业务方法体内部经常容易囊括一些不在当前业务逻辑内的分支逻辑，使得每个方法的耦合逐渐提高。

所以，禁止层内依赖对降低耦合有立竿见影的效果，这也是领域驱动设计提倡专门拉出一个Application Layer来协调各个Domain之间的交互的目的。

02 将大函数拆小

让代码恢复健康，最难啃的骨头就是那些动辄几百上千行的函数。保守派虽然避免了大量应用新框架进行替换所带来的工作量。但是这个最难啃的骨头是避不开的坎，否则所谓的代码重构只是隔靴搔痒而已，并没有多大效果。

03 减少代码

减少代码最高效的方式是调用新的系统api或者使用新的框架或者工具。他们可以大批量的代替原先冗余的「程序处理逻辑」。只是对保守派来说，他们会更谨慎地使用新的框架。毕竟，运用一个新框架可是一个不小的手术。

激进派与保守派最大的区别在于，他们更倾向于使用新的框架、工具甚至是新的技术栈、编程语言来解决问题。不过在我看来，这些新东西，可能在短期的确能解决眼前的问题，但是这些问题到底是新技术解决的？还是因为使用新技术而大量重写“新鲜”的代码解决的？值得打上一个问号。

最后的重头再来派很有意思。他们认为老项目已经没救了，必须重做才行，这是比激进派更激进的一个流派。

可是我见过好多重头再来派的人员，重头再来做出的项目，在其他人眼里可能并没有比之前好多少，甚至在过了一段时间之后，发现重新陷入了之前的困境之中。

因为盲目乐观是我们人性的弱点。这就像创业者总觉得自己是九死一生中唯一生的那个，买彩票的人总觉得自己是那个千万分之一的幸运儿一样。

这三个流派，并没有绝对的好坏之分，不同的流派都有不同的适用场景，区别就在于「时间、成本、质量」这三个要素上的取舍不同。所以，我们在选择方案的时候可以根据这三个要素的具体情况来判断。

因为Z哥认为一个项目的核心要素就是这三者，并且这三者无法兼得，最多只能取其二，类似于分布式系统领域的CAP定理。

Z哥有幸分别参与和主导过这三个流派的工作，以我的经验来看，我认为这三个流派分别适用的项目情况如下：

保守派。时间快，成本低，对质量仅有最基本的要求。
激进派。有较高的质量要求，满足时间较宽裕或者接受成本大幅增加其中的一点。
推倒重来派。时间和成本完全给质量让步，追求可见范围内的最好。

其实这么一分析你也能发现，总是推倒重来是不现实的，时间和成本这种属于资源，资源总是有限的。所以，大多数情况下，保守派的选择才是最常见的。因此我们更应该思考的是如何通过保守改造最大化提高项目的质量，让他摆脱“垃圾”的标签。这需要我们沉下心来才能完成，不要老想着推翻重做。

好了，总结一下。

这篇呢，Z哥和你分享了我对如何应对“垃圾项目”的看法。

首先和你分析了5个常见的使得项目逐渐变得垃圾的陋习。

组件颗粒度过大
API数量泛滥
低内聚高耦合
业务逻辑和程序处理逻辑纠缠
又长又宽的if else

然后分享了三个常见的保守派做法：

业务层禁止层内依赖
将大函数拆小
减少代码

最后分享了应对“垃圾项目”时的三大流派，分别是：

保守派
激进派
推倒重来派

从时间、成本、质量三个维度的权衡来看。保守派才是主流，所以不要动不动就想着推倒重来，收起浮躁的心，沉下心来。

好了，希望对你有所启发。