让我们"从头开始重新设计系统"吧
在上篇文章中，笔者对架构中的第三方依赖做了分类与解释。
你的项目中的第三方依赖，一定是属于 元依赖 ， 依赖倒转 ， 替换性依赖 以及 耦合依赖 的一种。在笔者讲正确的处理第三方依赖之前，笔者先聊一个我们行业比较普遍的令人头疼的现象。
它就是 从头开始重新设计系统
''从头开始重新设计系统"
这是我们很多技术人员经常说的话，某种程度上也是技术人员心中渴望去做的事
但它对管理及付出成本的公司来说，是一个非常可怕也很糟糕的事情，但却不断的在我们行业中不断的被实施与验证，一次又一次的上演。笔者认为这也是IT行业成本一直居高不下的很重要的表现之一。
完美的1.0
笔者喜欢用 完美的1.0 来形容项目或产品初期的表现。
由于没有历史代码的负担及技术欠债，通常一个团队在一个新项目的第一个迭代或头几个月，能快速 的 完成一个可以运行的版本，笔者把它笼统的称之为 1.0
这是最快乐的时光，技术人员喜欢这样的生活，没有代码上的历史负担，可以勇敢 的 尝试新的技术，团队的整体推进速度也非常不错，如果所有的项目都只需要到1.0为止的话，估计编*会码**成为很快乐的工作。
但可惜的是，很多项目或团队在度过了1.0的最快乐的时光之后，不可避免的滑向『勉力维持』的阶段
勉力维持
当然，并不是说这会是一个必然的发展过程，但确实是很多项目会慢慢经历到的一个阶段。
导致这种现象的原因和理由可能五花八门，不一而足。但笔者认为根本上的原因在于：
代码丢失了可维护性
可能是由于管理者对进度的不恰当的期望与控制，也可能是技术团队并不重视 维护性 这个点，或者是这个团队成员能力并不足以打造一个可维护性的代码等
编写可以运行的代码非常容易，而编写出可以持续维护的代码则相当难
破窗理论
无论原因是什么，最开始放弃的是 程序员自己 。在意识到或没有意识到 窗户 出现破烂后，程序员这个时候毫无作为，任由事情继续发展。
如果你熟知破窗理论，你就明白了不可避免的，更多的窗户会破掉。对于代码来说，就是越来越多的混乱与技术债务。
然后，项目慢慢 的 呈现出一种经典的发展趋势
新的功能开发所需要的时间越来越久，稳定的功能越来越难以实现，进度越来越不可控，项目压力越来越大，管理者也越来越手足失措，开始以增加团队人员或加班等措施来尽可能维系项目运转
由于 沉没成本 的原理，由于已经在一个事情上付出了太多成本与时间，放弃它越发变得不可能，但维系它越发痛苦与困难。
这就是笔者认为的 勉力维持阶段
这对程序员来说，是一个痛苦的阶段，最大的表现就是缺失成就感，因为好的东西难以产生出来。然后经历的痛苦可能是无止境的BUG处理不完，看不到截止时间的加班，生产版本随时的各种故障给技术人员带来的心理压力等
这个阶段的一个经典表现就是： 人员流失过大
结束，失败或"重新开始"
勉力维持阶段不可能一直存在，由于维系这样的项目成本越来越高，终有一天这个阶段需要滑向下一个阶段。也就是 结束，失败或重启阶段
类似的项目，结果只能是上述三种之一： 结束 ， 失败 ， 重构
结果一：结束
一些幸运的项目，能够把这个阶段支撑到交付给客户，支撑到一个不错的 终点 ，至少这个时候系统还是能正常运行，满足客户的需求。至于未来下一个阶段能不能再继续开发，现阶段 谁关心这个呢？
结果二：失败
当然也有些类似的项目，再怎么努力，也没法撑到这个结果，可能是由于系统实在太差，客户没法接受，或客户虽然明确表示项目可以正常结束，但并不会使用这个系统。这种笔者称之为 失败
结果三: 重构
由于意识到不可维护，一部分技术人员明白持续的支撑意义不大，当前所有的努力也只是 南辕北辙 ，或是出于不想让自己陷入这种困境，期望回到 完美的1.0 的阶段，他们会提出一个令所有管理者恐慌的建议：
让我们从头开始重新设计系统
技术人员会承诺这次会有更好的版本，不会重蹈覆辙
双版本并行
一旦 从头开始重新设计系统 的建议被允许，就会出现旧新两个版本并行开发的阶段。
大家的期望是：一方面维系旧版本，另一方面快速开发新版本，直至新版本有一天能替换掉旧版本。以完成这一次的 重新开始
那结果呢？
笔者认为可能的结果会有两种，一种是 新生 ，另一种则是 轮回
Robert C. Martin 在他的书中都提到过一个真实的案例，一个被建议重新编写的系统与旧版本持续并行10年之久，仍未能替换掉旧版本。因为旧版本 永远有新的功能是新版本没有的 ，以至于 新版本 在编写10年之久后，由于又一次陷入勉力维持阶段，被技术人员再一次建议 重新开始
这不是天大的讽刺么
新生或轮回
当然，重新开始的项目的结果只能是这两种的一种。要么新生，要么再一次 轮回
而结果如何仍然有赖于我们技术人员
结论
做为 技术人员，我们需要好好思考下要怎么做，才能避免这种 轮回 一次又一次上演。编写可维护的代码应该放在你最需要重视的，而不是什么技术框架更好，性能更好，什么新语言更好等这些上面，并不是不需要重视这些，只是不能以牺牲 可维护性 为代价
重新开始设计系统是进化
当然，并不是说我们需要架构或能编写一个永远能迭代的系统。
随着业务的扩张，我们的系统旧有的架构不可避免的陷入不满足的阶段，需要重新设计一个新的架构来满足新的业务，这种情况下，重新开始设计系统是非常正确的做法。
这是进化的表现
但基于不可维护的"重新开始设计系统"，则是我们技术人员要努力避免的。这不是必然，这就是一种糟糕的事情。
技术人员的使命
笔者在2020在公司的内训上对于技术人员的使命做了一个定论：
技术人员的使命就是：维护软件的技术价值与业务价值。
这是笔者在读到Robert C. Martin在其 架构整洁之道 中对于软件的价值做了分类，将其区分为 行为价值 与 架构价值 并认定 架构价值 高于 行为价值 这个部分自己思考得来的一个感想与结论。笔者非常认同这个价值分类。
笔者使用了不同的表述词，笔者使用了 业务价值 与 技术价值 来表述这两个价值，并对这两个价值的看法及其重要性与Robert C. Martin的看法并不完全一致，稍有区别。
这个点后续笔者再来详细聊。