《架构之美》阅读笔记02

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

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

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

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

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

6. 技术债务管理
什么是技术债务?为了赶时间,对于不太重要的功能被砍掉,允许小的代码"瑕疵"存在,发布时避免高风险的改动。这些都应该被标记为技术债务。
应该选择合适的时间,及时集中清理这些技术债务,在后续版本中修改。

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

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

原文地址:https://www.cnblogs.com/dd110343/p/14227330.html