最近跟朋友交流平台化与软件重构的一些问题，发现了一些有意思的现象。
1、新产品或者新平台上线之初，轰轰烈烈，成就了一批领导及优秀员工。
2、三年后产品的红利期过去，伴随内部维护的消耗越来越大，尾大不掉。团队的待遇下降，开始不可避免走向优化和重构。
3、优化和重构的难度远超预期，要么推到重来，要么开辟新产品。
当然这个三年是虚数，可能是三年，也可能是五年。但规律是一样的。
无独有偶，历代王朝也有一个300年的周期。
创业难、守成难、开拓难、中兴则难上加难。
为什么中兴这么难呢，引入一个熵增理论，那就是熵不断的增加，增加到一定程度，想要一点点的减成本大到可怕，只能爆炸，然后重新开始。
想要中兴，唯有变法。而历代变法者鲜有善终。核心是利益分配问题，衍生出来问题的就是三方面。
1、权利。想要变法需要绝对的权利，而权利本身就是需要制衡的。变法者如不顺着昌逆着亡，则新法推行不了。变法须结党，而屠龙者可能化身恶龙。王朝中后期，势力盘根错节，有几个君王有这个魄力，又有几个君王有这个威信？没有这个魄力和威信，变法执行者必然举步维艰。
2、历史包袱。法须，因地制宜、因时制宜。然而漫长的周期造就了一批既得利益者和众多旧法深度绑定的人群，动不了也不敢动。
3、稳定性。元朝末年，黄河泛滥，当时的中兴派主张救灾，救灾没问题，然而一救灾大元很快就完犊子了。一个病人，要想治好病，必须手术，然而手术过程中他可能就挂了，或者术后恢复不了，挂了。如果保守治疗的话，可能还可以活个三五年，怎么选择？
那么，兴替周期可不可以打破？又如何打破呢？
首先我们必须尊重规律，规律就是：
1、两面性。任何方案都是两面性的，没有只有优点没有缺点的方案；
2、发展性。因为有两面性，所以要掌握平衡，而平衡是动态的。不同时期要掌握不同的平衡，而不是长时间不做调整。
我们来复盘一个不得不推倒重来的项目，看看它是怎么病入膏肓的。
每个不可救药的项目，可能都有它辉煌的时候；项目创建之初，也都是组织了一群精兵强将来做的；然而一定遇到了一些受限因素，包括但不限于：
1、又快又好。领导要求快速启动、快速发版、快速占领市场。理想很丰满，现实很骨感，怎么做更合理，可能都知道，然而因为时间和成本，不能那样做。 领导只要结果，资本只要利益。然而又快又好的代价就是，现在的坑，以后填。那是下任领导的事儿，只要自己不是接盘侠，那先可劲儿造吧。
2、执行者和维护者自身的能力和素质问题。设计之初就没考虑长远，并没有把可扩展性、可维护性、耦合度作为一个重要的衡量标准。
3、时代问题。受限于当时的理念和水平。
那如何降低这几个因素的影响呢？答案是能用技术手段解决的，技术手段解决；技术手段解决不了的，靠规范解决。
接下来就是老生常谈了。我归纳为两方面：
一、主体结构。
主体结构就不得不谈架构了。我们公司的很多同事其实连架构是什么都模糊不清，把开发框架、脚手架、工具等等混在架构里，一团乱麻。
在架构之前是需求，需求之后是设计，设计之后才是架构。如果需求是把大象装冰箱，那么设计是分三步，架构是，冰箱打开模块、物品装入模块、冰箱关闭模块；然后因为冰箱打开和关闭有其公共属性和操作，所以打开和关闭可能要抽象出公共能力模块。这个是业务架构。
当然也有代码层次的架构，需要多少服务，服务内需要多少类和对象，类和对象之间什么关系，如何交互等等。
那么对于架构来说，需要的是稳定性和可扩展性。稳定性来源于对业务的深刻理解，比如，把大象装冰箱分三步，三到五年甚至五到十年，它就一直不变，它不变，那它就是稳定的。
如何保证可扩展性呢？设计模式告诉我们，要职责明确，要最小知道，要遵守契约，要互不影响。所有的原则都在说一件事儿，那就是面向接口编程。
业务合理的模型化拆解造就了稳定的架构和接口。
而面向接口编程又保证了业务代码和接口的稳定性。
如何业务模型化拆解呢？
1、学会分层。复杂问题按层分解，参照网络通信模型。各层解决各层的问题，层与层之间按协议来。
2、归纳本质。一个产品的核心业务其实并不多，将核心业务模型化的根本是，看到业务根本的共性。
如何保证面向接口编程？
1、业务模型化是基础，它决定有哪些核心接口。
2、遵循必要的设计模式。
二、细节。
其实就是代码规范。
首先，代码规范是什么？
1、可读性。怎么写别人更容易能看懂呢？大家都按照一个路子写，那就容易看懂。多些注解，别人容易看懂。
2、不踩坑。怎么写能避免那些容易踩的坑。
3、可扩展性、安全性、性能等等。怎么写在这些方面能及格线以上。