在实践中，绝大多数软件开发项目在初期都会配备相对资深的设计人员，他们通过自己的经验以及设计/实施能力往往能够确保项目成功启动并且步入正轨。当项目进入成熟期以后，出于成本的考虑，这一部分资深人员往往会被调离项目，从而对技术交接带来了很大的挑战。在我过去几年参与过的项目中，这种情况就屡屡发生。在我刚刚离开的一个项目上，初期投入的几名资深人员（一名架构师，一名高级DBA，一名高级程序员）先后在不同阶段被调离了项目，而项目的tech lead也在一年半之内更换了三位。这就直接导致了项目的一些关键设计思路没有被很好地理解和传递下去（当然，我们也不能理所当然地认为所有的初期设计思路都是对的、都需要保留）。

举例来说，项目初期采用了领域驱动的设计方式，tech lead领导团队对目标领域中的核心概念进行了分析，并提炼出了一套当时行之有效的模型。然而，具体的代码虽然容易理解，而为什么要进行领域建模、如何建模、建模时到底追求哪些目标、有哪些东西是我们想通过设计去避免的……这些最根本的东西却很难通过短时间被所有开发人员理解。换句话说，领域驱动设计的过程要远比它所产生的结果重要，而这个过程代表着一种能力，是一个成长中的团队很难在短时间内真正掌握的。这也就导致了tech lead几度更换、代码基数越来越大以后，不断产生的代码质量不高，一些核心的设计点被破坏。比如说，一些本应被封装在领域模型里的代码被直接写在服务层里，一些实体对象的唯一标识（identity）并不唯一等等。

解决这种问题没有什么妙方，项目的管理人员应该对项目的设计能力有一个客观的把握，而且要随着时间的变化注意观察这种能力，在设计能力与商业成本之间尽可能做出一个平衡来。这一点其实往往挺难做到的，因为在现实中，特别是在外包这个成本敏感的领域里，商业决策往往影响着甚至直接决定着技术决策（如果有可能的话一定避免这么做！）。比如在我曾经服务过的一家软件公司里，项目上的高级技术人员往往在展露自身实力后就被调离到其它项目去，要么负责启动，要么负责救火。这种情况下指望原有团队能够不失真地把设计思路接下来是很难的。

当然现实也并不总是这么悲观，良好的团队内部沟通在很大程度上能把潜在的问题降到最低。比如说，敏捷开发所提倡的结对编程就在实践层面上对解决这一问题提供了一种思路。设想一下，如果一名有经验的开发人员和一名初级开发人员有着充足的结对时间，那么前者的一些好的设计思路、开发经验甚至编程习惯就会潜移默化地影响到后者，这对于帮助后者提高自身设计能力是再好不过的方式了