代码是架构师和开发者共同的产物，在公司目前这种迭代式开发和需求多变的情景下，关键代码往往会被多个项目，多个程序进行多修改，
保持代码生命力
。最近我们部门对改善代码质量提得比较多，大家也讨论得比较多，个人觉得，可以从下面几个方面去实践。一、良好的设计。
一个良好的设计是保证代码质量的第一因素。设计就是对业务需求模型的抽象，对需求把握的准确与否，直接决定了设计的成败。在项目中，我们往往在寻找一些业务名词，如APP、ISV、USER、保证金、免费、月租、订单、红包、有效期、平台等等，一些动词，如接入、订购、付费、退订、上架、下架、审核、共享、服务等等，还有之间的一些关系连线，状态迁移，数据流向等，这些就构成了我们的业务体系，再结合我们常用的SAAS平台图谱，就组成我们的架构体系。我们设计，就围绕这些点铺开。我们使用前人总结出来的多种设计模式或是设计原则来抽象，隔离变化，以便使我们的设计易扩展、可维护、健壮、职责单一，在项目迭代中保持顽强的生命力。
1、设计尽可能简单。简单是为了面对变化时有更多的选择；
2、遵循面向对象设计原则：单一职责原则、开放-封闭原则、里氏替换原则、依赖倒置原则、接口隔离原则；
3、设计的本质是抽象，目的是隔离变化。项目中我们经常发现，反复修改的地方往往就那几个，基本上都是在前面提到的使用动词的地方。
二、统一的编码规范。
统一的编码规范是高质量的保证。从机器码到高级语言的变迁，从过程式编码到面向对象设计，从小作坊式编码到多个团队的协作，这种软件变迁无一不证明可读性、易维护性的重要性。只有机器能懂的代码在现在大型的项目中实际上是没有价值的。一般来说，我们的项目组都有一个比较详细的编码规范可供参考，同时我们的软件过程中也有code review来保证规范的执行，TM或专人 review，团队交叉/结对review的方式，或是两者相结合的方式都是可行的。特别是结对，规范和一些技能能够快速地在团队新老成员之间传播，在编码风格上也比较容易统一。
三、组件化。
组件化是提高代码质量的有效方式。前面提到设计中的抽象和变化隔离，这其中不变的部分和公共的部分可以被组件化。组件按业务的相关性可以分为工具类和业务类组件。我们项目中常用的Utils，第三方包，包括工程中提取出来的一些UI组件，界面元素工具，校验工具，过滤工具，接口调用工具等都属于工具类，公共服务，API，CORE，以及一些业务封装属于业务组件。不论哪一类组件，都是封装变数，重用代码的方式，大大提高了系统稳定性。
四、单元测试，管理资料
《保持代码生命力》(https://www.unjs.com)。
单元测试其实是个好东西，但是一直都难于执行。原因可能是，可做可不做当然不做更简单，项目很紧，有投入没收益，没有好的方法或框架对单元测试支持不好……，原因很多，值得讨论。我觉得，TDD是一种很理想的保证代码质量的方法：
1、测试用例中直接和程序的期望效果关联的断言，明确了程序的内含和外延，使程序输入输出有序，不至于产生所谓“灵异事件”；
2、编写单元测试必须考虑代码的可测性，这其实也就约束了上帝方法的出现，使代码结构更合理，重用性也更好；
3、直接的好处是不用起容器，间接的好处是调试时方便定位问题所在，提高跟踪的效率。这为开发人员调试代码节省了大量时间；
4、单元测试可重复执行，代码修改者易于从测试用例中找出编写者意图;
5、给开发者好的体验。绿条带来自信，红条发现问题。
五、大胆的重构。
重构必须加上大胆。因为业务变更、代码迁移、代码反复修改、一些为修复BUG而产生的临时性代码等等多种原因，造成了代码易于在迭代中腐化。这是一个非常值得关注的问题。前段时间因项目需要对原来的admin portal进行迁移，在阅读他人编写的代码中，发现了很多不好的地方。比如说重复的类，未实现的方法，废弃的方法，因为增删而产生的垃圾代码，大段大段的不知所以的代码段注释，和当前业务完全不相干的代码，”from app center”之类整段整段的拷贝。这些，都使代码变复杂，难懂（像为了防止他人读懂拷贝而混淆过的代码；D）。像这种问题，基本上都是在项目迭代过程中产生的。问题是不可避免的会遇到，关键是，我们有什么方法可以应对它。让项目永葆青春的方法就是——重构。
重构的时机。重构的前提条件是在可控的范围之内。重构和重写不一样，不是一下子铺得很开以至没法收场，也不是改头换面，引出其它地方的问题。重构总是在不改变外部形式的前提下，对内部进行改造，使内部结构更合理。“内部”“外部”我想也没有一定的范式，可以是方法内、模块内，总之是要在可控制范围之内。重构过的部分也需要单元测试和回归测试。这里的时机，我觉得是：当你去修改某段代码感觉到了坏味道，在你完全理解了原有代码的全部意图之后，并且，项目中会有QA来进行回归测试的情况下。
重构需要勇气。我们有个愿望是我们的项目更健康，最大限度体现商业价值。重构的勇气就是来自于这个美好的愿望。一个苹果本来是好的，可能因为某个小的污点，它便慢慢腐化，一直到某一天我们意识到问题很严重了，为此付出更大的代价。
总的说来，上面的实践多借鉴了敏捷的开发方式，也是个人的一点浅陋的理解。代码是有生命的，代码的生命除了牛P们把关，更多其实还是掌握在我们这些一线开发人员手里。
本文出自：http://www.alisdn.com/wordpress/?p=623