项目失败往往源于代码质量不佳。本文通过分析代码质量的重要性，揭示了项目衰败的常见诱因——代码质量低下，特别是组件粒度过大、API泛滥，低内聚高耦合以及无处不在的if else等问题。提出了解决方案，包括采用倒金字塔结构的业务逻辑组件、打造自定义lib和framework、业务模板Pattern of NestedBusinessTemplate，以及使用充血枚举类型（Rich Enum Type）来提升代码质量，从而提高项目的稳定性和可维护性。
- 这个度需要你为自己去评估和测量，如果目前的质量水平还在两者之间，那么就应该重点改进项目质量。当然，现实世界中很少看到哪个项目质量高到了不需要重视的程度。
===========================================================================================
一个项目的衰败一如一个人健康状况的恶化，当然可能有多种多样的原因——比如需求失控、业务调整、人员变动流失。但是作为我们技术人，如果能做好自己分内的工作——编写出可维护的代码、减少技术债利息成本、交付一个健壮灵活的应用架构，那也绝对是功德无量的。
虽然很难估算出这究竟能挽救多少项目，但是在我十多年职业生涯中，经历的和近距离观察的几十个项目，确实看到了大量的项目正是由于代码质量不佳导致的失败和遗憾，同时我也发现其实失败项目的很多问题、症结也确确实实都可以归因到项目代码的混乱和质量低下，比如一个常见的项目腐烂恶性循环：代码乱》bug 多》排查问题耗时》复用度低》加班 996》士气低落……
所谓“千里之堤，毁于蚁穴”，代码问题就是蚁穴。
接下来，让我们从项目管理聚焦到项目代码质量这个相对小的领域来深入剖析。编写高质量可维护的代码是程序员的基本修养，本文试图在代码层面找到一些失败项目中普遍存在的症结问题，同时基于个人十几年开发经验总结出的一些设计模式作为药方分享出来。
关于代码质量的话题其实很难通过一篇文章阐述明白，甚至需要一本书的篇幅，里面涉及到的很多概念关注点之间存在复杂微妙关系。
推荐《设计模式之美》的第二章节《从哪些维度评判代码质量的好坏？如何具备写出高质量代码的能力？》，这是我看到的关于代码质量主题最精彩深刻的论述。
===============================================================================
先贴几张代码截图，看一下这个重病缠身的项目的病灶和症状：
-
这是该项目中一个最核心、最复杂也是最经常要被改动的 class，代码行数 4881；
-
结果就是冗长的 API 列表（列表需要滚动 4 屏才能到底，公有私有 API 180 个）；
- 还是那个 Class，头部的 import 延绵到了 139 行，去掉第一行 package 声明和少量空行总共 import 引入了 130 个 class！
- 还是那个坑爹的组件，从 156 行开始到 235 行声明了 Spring 依赖注入的组件 40 个！
这里先不去分析这个类的问题，只是初步展示一下病情严重程度。
我相信这应该不算是特别糟糕的情况，比这个严重的项目俯拾皆是，但是这也应该足够拿来暴露问题、剖析成因了。
分层的理念早已深入人心，尤其是业务逻辑层的独立，彻底杜绝了之前（不分层的年代）业务逻辑与展现逻辑、持久化逻辑等混杂的问题。
但是好景不长，随着业务的复杂和变更，在业务逻辑层的复杂性也急剧增加，成为了新的开发效率瓶颈， 问题就出在了业务逻辑组件的划分方式——按领域模型划分业务逻辑组件：
-
业界关于如何设计业务逻辑层 并没有标准和最佳实践，绝大多数项目（我自己经历过的项目以及我有机会深入了解的项目）中大家都是想当然的按照业务领域对象来设计；
-
例如：领域实体对象有 Account、Order、Delivery、Campaign。于是业务逻辑
最低0.47元/天 解锁文章
扫一扫
202
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
