技术债的由来
最早听别人谈起过，软件版本每次迭代的需求版本包含两个来源，一个是业务需求，另一个是技术改造。业务需求毫无疑问会以研发产品特殊的方式立项开发，技术改造来源于技术内部，研发人员认为实现方法方式不合理，架构不灵活等方面都可以纳入技术改造的范畴。
在正常的公司开发流程中，业务需求总是压着技术改造被优先处理，因为技术遗留问题很多时候很难被发现，属于改造不改造，短期内都可以的情况。而一旦技术遗留问题的影响逐步显现出来，往往改造的成本就会变高，如果技术遗留问题得不到及时解决，久而久之就会变成技术债。
技术债清偿计划
每个部门都有一堵墙康威法则，正常情况下，每个部门都在自己部门的情况来做开发计划。每个部门无法对项目整体的技术优先级和在了解业务情况下再决定技术方案和改进方案，最重要的就是技术选择和实现优先级。每个项目或者核心功能点错过合适的时间档口，那就变成了技术债，之后业务原则上不会为之前的错误，尝试，架构优化甚至是技术改造补充足够的时间档期。
图片发自简书App
直到现在这个阶段，我还是认为
康威法则的解释可以理解为每个部门都有一堵墙
