我始终认为，代码应作为架构的一部分，不如此，不足以表达代码质量的重要性。我知道，这与传统学院派对架构的定义是相悖的。一般认为，架构是描述设计蓝图的宏观过程，然而，敏捷方法的逐步普遍，却慢慢开始颠覆这种事前设计的论调，代码不仅要体现架构的原则与思想，还要通过代码对架构施加影响，甚至利用代码来补充与完善架构。
Yourdon与Constantine认为软件系统的整体成本等于开发成本加维护成本，而后者成本远远大于开发成本。维护成本包括理解、变更、测试与部署的成本。其中，所谓“理解”主要还在于维护人员如何理解代码，尤其是当变更发生时。只有清晰的代码结构，才有助于我们理解系统；也只有清晰的代码结构，才能提高代码质量。所以，我认为代码是纳米架构（Nano Architecture）的一部分。
在将代码提升到一定高度之后，再让我们来看看如何改善代码质量。除了需保持代码的清晰与可读性之外，代码的数量也开始获得了人们的关注。InfoQ最近发表了新闻《代码是债务，越少越好》，根据精益方法中的库存得到减少代码数量的结论。《修改代码的艺术》（英文书名Working Effectively with Legacy Code）的作者Michael Feathers最善于处理遗留代码，他认为“代码也是我们持有的库存，并且需要最小化。”这篇新闻中摘录的观点都是警示之语，唤起了我们对代码数量的关注。
就本人而言，我认为减少代码量的最佳做法莫过于提高代码的重用性。《程序员修炼之道》中认为，重复的类型包括：
1、强加的重复
2、无意的重复
3、无耐性的重复
4、开发者之间的重复
综合而论，我认为导致代码重复的原因有三个：
1、懒惰，所以能够容忍不好的代码；
2、技能不足，常常会出现不必要的重复代码；
3、缺乏沟通，团队之间协作不够，因而重复制造轮子。
重用的关键是保持合适的粒度，以及对关系的解耦。粒度表现在方法级，就是需要编写许多小的方法，找到类中可以重复调用的职责，抽取为单独的方法。类级的粒度可以采用辅助类，也可以通过寻找共性，以泛化的方式提取共性特征。对于模块级，则主要需考虑模块的复用原则，合理解除模块之间的依赖关系。
之所以出现很多糟糕混乱的遗留代码，主要原因还是在于职责的分配与分离做得不够好。职责的分配不准确，就可能导致代码结构不清晰，而职责的分离做得不好，就可能导致代码的重复。在经历了太多维护遗留代码的工作后，我往往发现这些遗留代码都没有做好模块的划分，而是率意为之，有时候甚至会出现一个庞大的项目，包含了数据访问、业务逻辑与界面表现等所有对象，这意味着它没有合理的分层架构。我现在在设计和开发时，非常注意对模块的划分，尽量避免模块之间的双向依赖与循环依赖。同时，还要站着发布的角度来思考模块的划分与定义。在编码时，我会思考类的归属，要让其放到合适的位置，既表达出它的职责，又不会产生纠缠不清的依赖。
我们还可以通过用例识别重用。在用例图中，存在包含、扩展与泛化关系的用例，都可能是潜在的重用点。
本文转自wayfarer51CTO博客，原文链接：http://blog.51cto.com/wayfarer/590002，如需转载请自行联系原作者
