最近由于部门的转换，到了一个新的项目组， 由于这个项目之前经过很多人的手，代码阅读和扩展已经变得不是很好，已经能明显的闻到坏代码的味道，每次新功能的上线往往伴随着更多的代码冗余和新的bug。
于是项目经理决定改善代码质量，做法是强调规范，注重流程。这是个方案估计是目前大都是项目团队解决代码质量采用最多的方法，优势在于有了一个"标准"，而标准就是为了实现通用性，但是标准只是解决了浅层的问题，要更好实现一个应用的可持续稳定扩展性，是个需要深层发掘的。
现在的企业应用一般都是遵循迭代模式开发，好处是：
1） 高效：重要的功能先开发，附属增值模块后续上线
2）底风险：一些模块启用关闭，可以在短时间内上下线，这也是web软件的优势
3）高通用：边反馈边开发，及时了解用户需要，一定成度上满足了各种用户的需求，同时也使失败几率降低
4）可控性：团队不会因为“多模块”等长期处于分散情况下
鉴于迭代的这么多优势，很多线上软件都是采用边了解需求，边上线的做法。
但是正式由于这种方式，使得软件设计代码质量的高要求，原因在于后期功能的开发往往依附于早期基石之上，在一个坏的地基上永远建不了高楼。
这是一个迭代过程：
初始：需求的了解；需求UC
细化：系统设计（测试驱动用例）；领域模型，详细类图
构造：代码实现，测试用例（规范）
发布：回归，文档备案，总结，下次迭代准备
可以看到规范只在构造中起了作用，而细化一定程度上是构造的模具，而往往被忽略的就是设计。
细化设计虽然不能带来什么效益，没有它依然能实现应用，但我们不是开发半年一年的应用，而是三五年的应用。每次的设计都需要为下次的增量而作准备。
