代码模块的功能设计规划，制定的标准，没有详细的落地。架构定了一套，开发没有严格执行。每天写代码这么忙，架构只管架构，不管细节。开发每天撸代码，只管功能，不管架构和代码质量（这个质量不是指功能实现上的质量，而是说严格执行各项统一标准的程度）。甚至说，一个高层服务，不能调用同级服务，只能调用底层服务。因为开发的没有严格执行，甚至加了数据库连接，直接去取了数据库，这样的事一旦开了口子，就像黄河决堤，不可收拾了。

所以，以上说的是架构的落地落实很重要，让所有具体的开发参与者落实同一个标准。架构就需要落实相关的设计，相关的文档，相应的执行检查。现实的情况从来没有靠文档解决一切问题的，可它能解决80%的问题，另外就尽量减少开发人员的变动，以减小换人带来的代码腐化问题。

 

防止代码腐化的建议： 代码规范标准化，统一化治理

代码的内部质量其实很难保证，规范执行也更多的靠人治，甚至个别标准化的东西，只能通过代码层面去检验，无法通过测试或其他手段进行。

另外，虽然有一些通行的默认标准，更多的标准是代码的负责人自行确定的标准，完全根据喜好来，就像前面说的缩进的长度。好比是老妈和丈母娘都跑来你家里帮你打扫卫生，老妈喜欢把厨房里的锅都一路洗好挂起来，丈母娘喜欢找一个橱柜，都放在橱柜里，你能怎么办？没关系，只要确定下一套标准，不要经常改就好了。

 

架构严格落地

像前面说的标准，特别是自定义的标准，都需要落地。第一优先文档，第二是团队内部达成共识，第三是执行。

 

严格的codereview

防代码的腐化执行是一个关键点，这个关键点就是codereview。在这个时间点，再次与开发强调标准的重要性，让开发知晓执行，让测试监督，让架构严格检查。对于不符合的，开发要再次去学习执行标准。

 

减少开发人员的变动

如果一个团队内，原本标准就是统一的，团队内实行敏捷开发，任何一个开发都可以替代其他开发工作，那么两个人交换任务就没有问题。如果团队内都不统一，这个变动就会严重影响开发，代码腐化的可能会变的很大。

而团队间，标准统一的可能性比在团队内更难，要避免团队间的项目移交才是最优的方法。

 

代码模块架构Keep it Simple&Stupid，使用一眼就明白的架构

现实世界中，业务需求永远的跑在技术需求前面，很可能架构相关的设计没有文档，没有说明，一旦架构师不在，原来的开发换人了，导致原先的标准和设计无法继续下去，一旦有交接，标准的丢失和架构的变化不可避免。这时，此条原则就能发挥作用。要使用傻瓜化的架构，就是任何一个新来的程序员，一眼就能看明白的架构。例如使用公司统一的项目代码生成器，脚手架，生成统一的代码结构，不需要程序员再投入代码结构学习的成本。而且通用架构就意味着，后续的架构师接受原先设计的可能性大增。

 

 

分层的概念很早就提出来了，为什么MVC的概念会这么受欢迎？我觉得是因为它足够傻瓜化。数据库的架构结构中，定义repository，service接口，serviceImpl的实现等也成为了很通用性的设计。

有一个挺经典的例子就是asp.net.MVC的程序组织架构

三个文件夹：Controllers，Models，Views直接约定，并强调约定大于配置。只要是开发过这类程序的程序员，都知道从Controller看路径和RestApi入口，Models看数据结构，View看Html视图。就不需要额外的学习成本。

Maven的标准目录结构也是一个例子。（见上图）

 

定期清理维护

如同像打扫房间一样，一段时间不打扫，自然会有边边角角的脏东西出来。那么有没有定期的去清理呢？还是不管他，每次看到地上的一团纸，都绕过，而不是去扔了？

定期的清理维护不单是一个维护代码的过程，更是一个重新梳理和统一标准的过程，让现有的开发和架构，再次的达成一致，以提高战斗力

 

防止代码膨胀

微服务概念的提出后，很好的解决了一个问题，我们的一个代码模块应该写多少大的问题？一个模糊的建议是一个Sprint能重写的大小，如果更大，就应该要差分。有时候代码的清理维护工作也要以这个原则来处理，不能出现过大的代码模块。因为过大的代码模块，首先带来的是程序的复杂度，让程序员理解起来要更多成本。其次，模块内部的耦合度必然也提高了，增加了难度。这时，需要的是切分出一个新模块出来。

 

总结

代码腐化是程序开发的一个经典问题。代码内部质量的降低，外部质量确可以被客户接受。程序员经常想着，等业务没那么忙的时候，做点清理，做点模块局部的微重构，我的经验告诉你，这些都是假的。如果定下了定期清理，定期检查拆分，就必须立马去做。做这些事的优先级要远高于业务需求。

 

为什么呢？想象一个程序C++的printf，里面的代码写的非常的烂，变量命名都是p，m，k完全不能直观理解含义，我们需要郑重的去处理这个模块的代码腐化问题吗？其实不需要，因为printf模块的代码需求，就是把输入的内容打印出来，永远都是这样，没有任何新需求，没有新需求就代表没有程序员需要深入内部去改它的代码，不需要改的代码，我们是没有动力去解决它的腐化问题的。有必要经常深入解决腐化问题的代码，必然是业务需求很多，经常要变更的代码。不要等到它已经腐化到代码生命周期都快走到头了，才想起来去维护清理它，要经常维修一下，才能更好的让它发挥作用，是吧？一辆不打算开的老爷车，发动机坏了就坏了，一辆经常开的二手奔驰，定期维护少不了。