现有的项目里，一次功能变更可能带来了大量的缺陷。于是乎，我试着回溯项目的开发过程，寻找出导致问题的根因。现阶段，我只能想到时的只有实施技术战略性投资，也暂时也想不到更好的方法，以在开发初期解决问题。
我现在所在的项目是一个优化相关的项目，包含性能优化、架构优化等。这是一个差不多一年左右的技术型的软件项目。项目中存在着各种各样的技术挑战：文档的匮乏、缺乏经验丰富的开发者、缺乏领域专家、相关领域的专家无法提供技术支持……。总之，一系列的技术难点使得项目开发越来越困难。
尽管项目并非从无到有，但是仍旧相当多的开发工作需要大量预研。然而，由于 Deadline 的设定使得需求一个接一个的出现，而大量的开发工作又依赖于花时间的预研。因此，这个时候我们就会陷入了一个困境：
大量的功能架构在『临时性方案』之上，原有的临时方案进一步成为新的『临时性方案』的起点。因而，随着功能的进一步堆砌，即使修改少量的代码也会带来大量的问题。
我尝试把这个问题归究于上吊绳驱动开发（Deadline driven design），但是在仔细研究之后，我觉得这个归纳太广泛了。思来想去，我觉得用临时方案传染性会更为贴切一些。
临时方案传染性
我尝试去定义出临时方案传染性：
临时方案传染性是指软件开发过程中，因旧有临时方案的存在，导致新需求的设计方案无法实施，而只能再次选择设计出新的临时方案。也因此，新的方案也只能建立在旧有的临时方案之上，系统随着临时方案的蔓延进一步腐化，即所谓的传染性。
临时方案是在软件开发过程中很常见的一种模式，也并非所有的临时方案都具有传染性。这种传染性主要出现在复杂业务场景之下，又或者是严重依赖于架构设计的系统内。在这两种场景之下，我们可以发现它们都是缺乏前期设计导致的，缺少业务设计、业务转换架构的设计，又或者是架构的设计。
示例
想象一下，有这么一个需求是获取系统中的某类型的文件。首先，在初始阶段，我们已经知道了要支持所有的主流操作系统：Windows、macOS、GNU/Linux 等，而且我们也知道路径中的某一层级在未来是可变的。（PS：这是的文件操作只是代替真实案例）
但是呢，在第一个阶段，我们只需要支持 Windows 操作系统。由于文件是固定放在某个目录之下，所以我们只需要写死路径即可，如 D:\sdkblabla。接着，我们的下一个需求发生了变化，其中的一个路径会根据条件发生变化，于是乎我们用正则做了个替换，它足够的简单而且快（PS：这也只是个替代案例）。
随后，在下一个版本中，我们需要支持 macOS，于是由于时间的原因，我们依旧写成了 ~/sdk/blabla。最后，现在我们需要支持二级目录可变更，如 ~/sdk/*/blabla。这个时候，我们已经没有一个更好的方案了。
因此，在后来的版本里，我们一步步这个基础之上进行大量的临时方案，因为原先的临时方案没有改用正式方案，导致后续有更好的方案无法实施。
原因
我尝试着从我遇到的一些案例、社区上的案例里，总结出一些原因：
- 技术第二。嗯，就是技术就是成本的那些公司的观点，不愿意去重视架构。
- 需求不确定性。大部分项目常见的问题，缺少经验丰富的业务分析员、项目经理。
- 时间难以估算。常见问题
- 缺少经验丰富的开发者。这个相对比较难解决，不过还可以找专家咨询。
- 关键架构设计不确定性太多。即架构中需要分析评估的内容较多，一个评估方向出错会影响进度。
- 资深工程师占比太少。一个想稳定发展的项目应该至少应该保持在 1:1 的水平。
- 缺少必要的工具。
- 风险过多。
总结之下，无非就是三点：
- 缺乏架构师、资深工程师。也就是缺乏相关领域的经验
- 项目本身过于复杂。
- Deadline 驱动。上线时间影响了我们的技术决策
修正缺陷成本
而这些相关问题的讨论，已经是一个相当成熟的领域：
相关的学术讨论会的讨论结果表明，在大型项目的早期需求阶段进行的投稿，以及对设计的确认和验证可以把『成本-修改』的增长曲线从 100:1 降到 20:1。——《软件之道 ：软件开发争议问题剖析》
也就是说，如果我们在前期进行技术调研的话，那么我们可以将项目的缺陷率减少到 1/5。
经典应对方案
从我们了解的情况来看，事实上，团队上的大部分人都知道怎么解决问题。长期的项目经验下来，他/她们也都成了经验丰富的开发者。只是呢，没有时间。
而对于少部分团队来说，因为业务上的成功，使得团队有了更多的时间和精力（主要是钱）来解决这一类问题。也因此，解决问题就变得越加容易了。
对于业务成功的团队，它们选择了更好的方案：重写，又或者是采用新的架构（重写的一种方言），比如微服务或者 DDD 方式。
临时应对方案
为了解决临时方案带来的问题，我们当时也需要产生一些临时的应对方案。
端到端测试
在某些场景之下，可以通过端到端测试以来覆盖原有的场景，进而避免原有的功能被破坏。它只是用来建立重构的防护网，以确保修改带来的缺陷不会大量出现。
更多的相关内容可以见：《系统重构与迁移指南》 （ https://migration.ink/ ）
渐进式重构/修正
主要也是采用缓慢的方式，慢慢来确保架构能行驶在正确的路上。
嗯，同上，可以参考《系统重构与迁移指南》。
其它
架构设计的程度与腐化速度是成反比的。（当然，避免过度设计）
没有银弹。
