软件项目中的可逆性与追踪子弹开发法
可逆性：避免决策陷阱
在软件项目中，工程师和管理者往往倾向于简单、单一的解决方案。就像数学测试中能明确得出“x = 2”的答案，比探讨法国大革命众多模糊成因的论文要让人安心得多。然而，现实世界并非如此稳定，今天适用的决策，明天可能就不再可行。
例如，在项目中决定使用某一供应商的数据库，可能到后期发现该数据库性能不佳，但由于代码中大量调用第三方产品，更换数据库将是一项巨大的工程。这体现了关键决策的不可逆性，一旦做出，往往难以更改。
为了应对这种情况，我们需要在项目中保持灵活性。遵循一些原则，如DRY原则、解耦和使用外部配置等，可以减少做出关键、不可逆决策的可能性。以数据库选择为例，如果将数据库抽象为提供持久化服务的组件，那么在需要更换数据库时，就可以更灵活地进行调整。
另外，在架构设计上，也要考虑灵活性。自世纪之交以来，服务器端架构不断变化，从大型主机到云支持的无服务器应用，再到可能回归的大型主机。我们无法预测未来的架构趋势，但可以通过隐藏第三方API、将代码拆分为组件等方式，使架构更易于更改。
同时，我们要避免盲目追随潮流。未来充满不确定性，我们应让代码具备适应变化的能力，既能在条件允许时蓬勃发展，也能在面临挑战时灵活应对。
下面通过一个表格总结可逆性相关要点：
|要点|说明|
| ---- | ---- |
|避免单一方案|现实多变，依赖单一事实或方案可能导致决策失误|
|保持灵活性|遵循相关原则，减少不可逆决策|
|架构灵活性|隐藏API、拆分代码，应对架构变化|
|不盲目追潮流|让代码适应变化|