架构之美02

1. 新代码的定位

一开始就有系统结构清晰的总体视图，所以，新的功能单元可以添加到正确的功能区域，而不是为了一时方便，代码随意添加。（这样，有的时候开发者的工作会需要动写脑筋，但是在系统维护和扩展时，就变得容易了）

 

2. 系统的一致性

顶层设计的良好风格和决定，为底层代理好处，代码是统一、整洁的。清晰的定义，确保没有重复的代码、接口惯例和常见设计模式被普遍使用、没有特殊生命周期的对象和资源管理问题。（这个重点是在于减少功能重复）

 

3. 架构增长

没有什么是一层不变的，架构应该是方便扩展、可重构的。这样，代码可以快速增长，同时又保持好的内部结构，添加新的功能不是问题。

 

4. 延迟设计决定

这部分应该是需求问题。YAGNI（如果不是马上需要，就不要去做），早期只设计中要的部分，将余下的决定推迟。特别是，不确定的需求，需要猜测。

 

5. 保持品质

结对编程、对代码复审、单元测试。对不正确、不合适的变更都要拒绝。开发者需要对设计负责。

 

6. 技术债务管理

什么是技术债务？为了赶时间，对于不太重要的功能被砍掉，允许小的代码"瑕疵"存在，发布时避免高风险的改动。这些都应该被标记为技术债务。

应该选择合适的时间，及时集中清理这些技术债务，在后续版本中修改。

 

7. 单元测试 打造设计

单元测试在很大程度上定性了代码设计，它迫使我们实现好的结构，保证可测性。

 

8. 遵守设计

新的成员可以比较容易地拿起代码开始工作。开发团队动态地遵守架构设计，项目原则规定没有人"拥有"某部分设计，而是所有人都应该写出高品质的代码，可以改动系统的所有地方。