卓越工程之开发过程管理

在「我理解的卓越工程」一文中，描述了达到卓越工程的一系列的手段。但是，开发过程管理是软件工程中的一个重要环节，上述的措施怎么落实到开发过程管理中，也是最终是否可以达到卓越效果的一个重要保障。

不管是瀑布式还是敏捷开发，开发过程都涵盖了如下环节：需求、设计、开发、测试、发布和运维。瀑布和敏捷的区别无非是一个流程还是多次迭代的区别。

对于整个开发过程，我们需要有如下的认识和实践，能帮助我们取得好的结果：

第一，纠错的成本，越往后越大。所以，我们对于需求和设计环节，需要足够的重视。敏捷开发只是将一次交付编程了多次的迭代性交付，后期纠错成本比前期大这个规律还是没有被打破。甚至后续迭代如果需要纠正前面迭代的设计问题，代价会更大。重视需求分析、领域建模和系统交互、接口契约设计。

第二，好的软件是设计和开发出来的，而不是 CR 和测试出来的。所以在设计阶段，需要对领域模型、系统交互、接口契约、主要的程序逻辑做深入的分析和反复的论证；在开发阶段，需要有很好的框架设计，很好的代码规范。做过 CR 的同学都会知道，在 CR 的过程中，比较容易做的是代码结构以及代码规范上的检查。对于一些业务逻辑的检查，可能性就低一点。对于模块结构或者系统交互上的检查，可能就更困难了。

同样的，对于测试而言。功能测试阶段，集中在黑盒，是对于需求的验证，测试用例做的再好，也就能覆盖需要交付的功能部分。一个软件的功能测试，能把和用户交互逻辑相关部分做到百分之百覆盖已经很了不起了。对于软件的结构是否合理，可延展性如何，未来迭代重构的时候会不会有坑，这些很难要求在测试阶段的发现问题。

第三，KISS 原理。越简单的东西越能做好，以及越有生命力。在后期的运维阶段，如果一段代码的逻辑极其复杂，或者模块之间有千丝万缕错综复杂的交互，这样的软件运维一定是一个灾难。所以，在前期的设计阶段，我们需要在架构上保证简单和可运维：

• 单向依赖：类似责任链的模式，A 依赖 B，B 就把自己该做的做到位，不要反过来再依赖 A。

• 低耦合：B 提供一个能力，就把能力提供全了，而不是要上游通过多个服务的组合调用来实现某个功能。声明式优于命令式。

• 封装/高内聚：本领域内部的概念不要对外露出。不要让上游感知除了契约以外的概念。

• 杜绝微微服务化：根据功能拆分服务，不要根据架构域或者技术拆分服务，以至于服务粒度过细，从而导致系统复杂度和运维难度陡增。

• 可观测性：日志打清楚、异常描述清楚，同时具备可探测的能力。

总之，我们要认识到：软件质量的决定性因素在架构和代码；软件质量在前期就差不多决定了，后续的测试和发布运维只是在前期搭的框架内部做到质量最大化。