随着软件不断地迭代，原先优雅的架构也会随之逐渐腐化形成祖传代码（屎山）。有些团队觉得能跑就行，但如果系统架构一开始就存在明显的设计缺陷不优化也不调整，那么最终将拖慢交付速度。 笔者曾在一家公司（以下简称A公司）做PHP开发负责数据采集项目，入职不到10天项目经理给我项目代码，我下载代码后不到30秒就判断出架构存在明显的缺陷，具体表现如下：
目录结构混乱，没有用composer，第三方组件散落在不同目录里，无法清晰地了解到每个目录的代码用来做什么。 数据采集项目却没有采用ETL架构的思路来分层，各个采集源采集来的数据除了抽取过程相对独立，转换、过滤、载入3个过程的逻辑都放在上帝方法里，理解极为困难。
由于架构缺陷严重加上业务流程错误，整个采集过程没有使用事务，先污染后治理，无形中加大了很多带宽和资源开销，还会出现重复数据。
我所在的项目组共6个后端，测试多少人不太清楚，通过任务看板得知入职当月实际交付的需求占当月计划开发需求数的34%，这些需求都没有涉及前端，交付率非常低。
为什么需求交付率如此之低？本质上是架构缺陷！由于没有ETL分层架构，虽然业务流程简单但新人上手困难容易踩坑，无法通过试用期考核的概率极高，即使转正了仍可能踩雷，于是又得依靠一两个老员工当主力没时间优化架构，大量的时间都在处理细节问题，设计技术方案也得非常谨慎，交付速度被严重拖慢，新人看到这种满是“地雷”的项目也会提心吊胆，最后需求积压严重又无力偿还技术债，打补丁的需求越来越多，形成恶性循环。为了防止出现这种糟糕的局面，研发团队在日常工作中应做到如下几点：
技术层面：
1、项目初期应根据项目所属的类型选择合适的架构，杜绝用不合适的框架和架构强行适配比如用MVC适配ETL类项目。
2、每个迭代周期预留20%的时间用于处理技术债务。案例中提到的项目增加新的采集源就可以设计好分层，然后按新的分层架构完成采集过程，后续功能以它为基准将混乱的业务逻辑根据每一层的目标拆分业务逻辑并迁移到新的接口/类里。
3、使用Sonarqube等专业工具进行代码静态检测。
4、对扩展性要求极高的模块使用面向接口编程，减少改动。
5、识别异常情况：遇到任务拆分难度增大就要警惕，很可能是耦合度上升的信号。
需求层面：
1、明确产品的边界，如用CRM做APP用户行为分析，CRM以客户为单位不应混入用户维度。
2、做好顶层设计，避免出现同一业务目标存在多个不同需求的情况导致的重复建设。
3、架构缺陷严重到拖慢交付速度时，迭代计划应让位于重构。
