架构决策非一成不变：用三项技术实践留后路

作者在给出一整章的架构选型建议前，先明确提醒读者：任何建议都是危险的礼物——单凭几分钟或者一本书的描述，作者不可能替某个具体项目做出真正合适的决策，读者对自己项目的了解永远胜过作者，这些建议的作用应该是推动读者自己思考，而不是替代思考；最终决策和后果都由读者自己承担。好在架构决策不是刻在石头上的：架构重构确实很难、代价也常被低估，但并非不可能。作者给出的兜底建议是——即便对极限编程整体不感兴趣，也应该认真采纳三项具体技术实践：持续集成、测试驱动开发、重构。这三项实践不是万能药，但它们共同的作用是让系统在日后需要改变架构决策时变得”更容易改”——换句话说，与其试图一次性做出完美的、不可撤销的架构判断，不如投资于让判断本身具备可修正性的工程基础设施。可迁移启发：面对信息不充分、无法保证正确的架构决策，与”追求一次性做对”相比，”保留低成本纠错的能力”往往是更现实、也更划算的策略。