软件从“能运行”走向“成熟”，不仅仅是把功能做出来、把问题解决掉就行，更关键、更重要的是形成稳定、规范、可持续的软件研发方式。

结合实际研发经验，总结了几个基本原则。

1. 不图一时轻松：不以“实现快”替代“架构正确”

软件研发不能为了追求短期轻松和快速见效，而选择明显违背系统架构的简单实现。

一个局部看似省事的方案，如果破坏了既定架构、模块边界或长期演进能力，后续往往需要付出更大的代价进行修补。

成熟研发首先服从架构，其次才考虑实现便利。

2. 不钻牛角尖：局部最优必须服从系统完整性

“钻牛角尖”往往表现为围绕一个局部问题反复死磕，却忽视这个问题在整个系统中的位置和代价。

脱离整体架构、资源约束和模块协同去解决单点问题，即使最终实现，也可能带来复杂度上升、接口破坏、性能下降，甚至影响其他模块。

任何局部技术方案，都必须放回整个系统中评价；不能用一个点的漂亮，换整个面的混乱。

3. 必须建立完整的版本管理机制

没有完整版本管理的软件，本质上就是不可管理的软件。

代码、配置、脚本、依赖、接口以及发布版本，都应纳入统一管理，使每一次修改都能够追溯来源、比较差异，并在出现问题时及时定位和回退。

成熟软件不是“现在能跑”，而是知道每个版本为什么这样、改了什么、出了问题如何回退。

4. 未经过完整性测试的修改，不得进入主干

软件合并不能只验证“这个问题修好了没有”，还必须验证“这个修改有没有破坏其他地方”。

功能新增、缺陷修复和性能优化，都应根据修改范围完成必要的单元测试、接口测试、集成测试、回归测试和关键场景验证，再进入稳定主干。

测试不仅要证明新功能是正确的，更要证明原有系统没有被破坏。

写在最后

成熟软件研发追求的是：

在不破坏系统架构和整体完整性的前提下，以可追溯、可验证、可持续演进的方式解决问题。

归纳起来，就是四句话：

架构优先，整体优先；
版本可溯，合并必测。