本文转载自微信公众号《跨界建筑师》，作者Zachary。转载本文请联系跨界架构师公众号。大家好，我是Z哥，相信每个程序员最怕遇到代码质量不好的项目。毕竟加入同样的功能，代码干净清晰的项目和代码混乱的项目在效率和质量上的差距能达到一个数量级，一点都不奇怪。但残酷的现实是，“垃圾项目”无处不在，大厂也不例外。毕竟，没有人天生就能写出极其优雅的代码。都是靠写“垃圾代码”一步步成长起来的。唯一的区别可能是增长速度。如果一个项目运气好，成为未来重要的项目，那么它还有机会摆脱掉很多“垃圾代码”，但如果运气不好，就会给后人带来损失。所以，如果你是一个新手程序员，那我不得不提醒你，一定要有一个合理的预期，而这个合理的预期就是——长期和垃圾代码在一起。所以，如果你以后遇到“垃圾代码”就骂你，这不是“代码道德”。什么？然后干脆换工作？你如何确保你接手的下一个项目会更好？在Z哥看来，一个项目变成“垃圾”被大家抛弃的原因只有一个，代码是垃圾，什么样的Code才算是垃圾代码？说多了，再分享一些常用的给大家。01组件粒度过大现在三层架构基本已经成为基本共识。只要项目不是太老，UI、业务逻辑、数据操作一起写的可能性不大。（虽然架构设计的后起之秀很多，但三层架构的市场占有率仍然最高，因为它更容易理解。）但是三层架构的每一层应该如何进一步细分和建模呢？目前还没有达成共识，统一标准或最佳实践出来了。因此，很多项目在经历了一年多的业务发展变化后，业务逻辑层往往最先倒下，大对象开始出现，成为开发效率的瓶颈。近几年火热的领域驱动设计其实已经开始深入到如何划分每一层的内部。但要达成共识还有很长的路要走。02API数量泛滥。有一定经验的程序员会用一个技巧让自己在垃圾代码中畅游。这个技巧是试图通过“添加”而不是“修改”历史代码来实现功能。这种方式确实可以避免很多“屎坑”，但是长此以往，大概率又会产生新的“屎坑”。有些核心类有几百个函数，几千行代码。03低内聚、高耦合“高内聚、低耦合”是软件开发领域的一条金科玉律，相信每个程序员都知道。但现实是很多项目存在低内聚高耦合的问题。这个问题不是大量重复代码造成的，而是过分追求消除重复代码造成的。一味追求减少重复代码，自然会导致代码过度拆分。本来，一个完整的业务流程被清晰地拆分成了多个功能。复用当然好，但是应该有一个前提：在不增加系统复杂度的情况下复用。不这样做会损害稳定性、增加复杂性并降低代码的可读性。04业务逻辑和程序处理逻辑纠缠不清Z哥认为，代码的功能其实分为两种，业务逻辑和程序处理逻辑。前者体现了软件的实际价值，后者是软件在计算机上运行必不可少的组成部分。程序处理逻辑主要是各种数据的访问、dao操作、序列化/反序列化、缓存操作、异常处理、参数和返回值准备等，如果程序的处理逻辑和业务逻辑混在一起，就像芝士拌饭，都是粘在一起的，改一个小功能，就会拉出一大段代码来看。更可怕的是如果里面填满了很多MagicNumbers，比如if(errCode==50001)。然后你必须避免咒骂。05长而宽的ifelse其实是一个被诟病很久的坏习惯。但这是几乎所有编程语言的语法，那么问题出在哪里呢？因为不管是ifelse还是switchcase，其实都是硬编码的方法。这使得修改变得困难。想象一个场景：一个新的值被添加到一个枚举中。这时候就需要把原来判断这个枚举的ifelse都检查一遍，保证新添加的业务能够正确执行。真正做过这件事的人，相信都深有体会。如果这个枚举用在几十个或几百个地方，查一下，了解一下上下文，估计至少半天就没了，很可能最后漏掉或者改错了。以上是一些常见的垃圾代码的样子。那么，在工作中遇到满是垃圾代码的垃圾项目怎么办呢？就流派而言，主要有激进派、保守派和全面派三种流派。保守的做法主要是从问题代码的局部修改入手。比如上面提到的“垃圾”代码，常见的处理思路如下。01业务层禁止层间依赖。大家可以注意观察，业务层内部的相互依赖是代码高耦合低内聚的主要驱动因素。因为这会导致一个业务方法体中往往会包含一些当前业务逻辑中没有的分支逻辑，从而逐渐提高各个方法的耦合度。因此，禁止层内依赖对降低耦合有立竿见影的效果。这也是Domain-DrivenDesign提倡抽出一个ApplicationLayer来协调各个Domain之间交互的目的。02把大功能拆成小功能，让代码恢复健康。最难的骨骼就是那些几百行甚至几千行的函数。不过，保守派避免了应用新框架进行替换所带来的许多工作。但这个最难的骨头却是绕不开的坎，否则所谓的代码重构也只是皮毛，收效甚微。03减少代码减少代码最有效的方法是调用新的系统API或使用新的框架或工具。它们可以大量替代原来冗余的“程序处理逻辑”。只是保守派会更加谨慎地使用新框架。毕竟，实施一个新框架可不是一件小事。激进派和保守派最大的区别在于，他们更倾向于使用新的框架、工具，甚至是新的技术栈和编程语言来解决问题。不过，在我看来，这些新事物在短期内确实可能解决眼前的问题，但这些问题是新技术解决的吗？还是因为使用了新技术，通过重写大量“新鲜”代码来解决？值得打个问号。最后的重启派很有意思。他们认为旧项目注定要失败，必须重做，这是比激进派更激进的流派。但是，我见过很多人从头再发，从头做的项目在别人眼里可能并没有比以前好多少，甚至过一段时间后发现自己有再次陷入了之前的困境。因为盲目乐观是我们人性的弱点。就像创业者总觉得自己是九死一生的唯一，买彩票的人总觉得自己是千万分之一的幸运儿。这三种流派没有绝对的好坏之分。不同的流派有不同的适用场景。区别在于“时间、成本、质量”三要素的取舍。所以，我们在选择方案的时候，可以根据这三个要素的具体情况来判断。因为Z哥认为一个项目的核心要素就是这三个，而这三个不能兼得，最多只能选择第二个，类似于分布式系统领域的CAP定理。Z哥有幸分别参与并主导了这三个流派的工作。根据我的经验，我认为这三种流派适用的项目如下：保守派。时间快，成本低，对质量只有最基本的要求。激进分子。有更高的质量要求，更多的时间来满足它们，或者验收成本显着增加。放下并重新开始。时间和成本完全让位于质量，在可见范围内追求最好。其实经过这样的分析，你也可以发现，老是重新发明轮子是不现实的。时间和成本就是资源，而资源总是有限的。所以，大多数时候，保守的选择是最常见的。所以，我们应该多思考如何通过保守改造，最大限度地提高项目质量，让他摆脱“垃圾”的标签。这就需要我们静下心来完成，不要老想着推倒重来。好的，总结一下。在这篇文章中，Z哥和大家分享一下我对如何处理“垃圾项目”的看法。首先和大家分析了让项目逐渐变垃圾的5个常见坏习惯。组件粒度过大，API泛滥，API数量少，内聚性高，业务逻辑和程序处理逻辑纠缠不清。long和wideifelsethen共有三种常见的保守做法：业务层禁止层内依赖，减少大函数。最后，代码从时间、成本、质量三个维度分享了处理“垃圾项目”时的三大思潮，即：保守派、激进派、推倒重来。保守派是主流，不要时不时想着推翻重来，收起浮躁之心，静下心来。嗯，希望对你有所启发。
