码迷,mamicode.com
首页 > 其他好文 > 详细

架构之美02

时间:2017-02-06 23:20:12      阅读:163      评论:0      收藏:0      [点我收藏+]

标签:重复   允许   开始   应该   技术   快速   资源管理   功能区   开发者   

1. 新代码的定位

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

 

2. 系统的一致性

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

 

3. 架构增长

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

 

4. 延迟设计决定

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

 

5. 保持品质

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

 

6. 技术债务管理

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

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

 

7. 单元测试 打造设计

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

 

8. 遵守设计

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

架构之美02

标签:重复   允许   开始   应该   技术   快速   资源管理   功能区   开发者   

原文地址:http://www.cnblogs.com/hanzhu/p/6371981.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!