今天的主题是技术债，康威法则和重构
技术债的由来
最早听别人谈起过，软件版本每次迭代的需求包含两个来源，一个是业务需求，另一个是技术改造。
业务需求毫无疑问会以研发产品特殊的方式立项开发。
技术改造来源于技术内部，研发人员认为实现方法方式不合理，架构不灵活等方面都可以纳入技术改造的范畴。
在正常的公司开发流程中，业务需求总是压着技术改造被优先处理，技术遗留问题很多时候很难被发现，属于改造不改造，短期内都可以的情况。
而一旦技术遗留问题的影响逐步显现出来，往往改造的成本就会变高，如果技术遗留问题得不到及时解决，久而久之就会变成技术债。
技术债清偿计划
康威法则说过每个部门都有一堵墙，正常情况下，每个部门都在自己部门的角度来做开发计划。每个部门无法在对项目整体的技术优先级和了解业务情况下再决定技术方案和改进方案，其中最重要的就是技术选择和实现优先级。
每个项目或者核心功能点错过合适的时间档口，那就变成了技术债，之后在业务方的运行进程中，原则上不会为之前的错误，尝试，架构优化甚至是技术改造补充足够的时间档期。
说简单点，就是在该开发好的时间节奏内没有开发好。后边没有人关注的情况下，系统就在那里平躺的运行了，要付出很多代价来弥补之前的业务理解不到位，架构不合理等各种问题。
如何解决呢
关于技术债和老项目重构，本文不展开来讲，说两点比较重要的。
重构和老项目的重构改造优化，都需要得到领导和同事的支持，那么如何说服领导和团队成员对于一个老项目进行重构？
1 将问题转化为可以量化的业务指标，业务驱动，让量化的指标帮助参与者做决策。
2 将需要解决的问题分类梳理，进行重构的目标管理，看到希望就会有人支持。
end 2020 年 1 月整理
