现在走捷径，将来付利息

作者：斯科特·麦克菲（ScotMcphee）

长远看来，系统维护将比项目初期的开发消耗更多的资源。进行系统架构设计时，牢记这点非常重要。在项目开发初期走捷径，可能会以日后付出高昂的维护费用为代价。

例如，你可能觉得单元测试并不直接产生价值，于是就让开发人员跳过这些严格的测试工作。这将导致所交付的系统在未来更难修改，而且在修改时信息不足。即使只做了一些修改，也需要对系统做出大量的手动测试，这将导致系统极为脆弱，维护成本不断攀升，其设计也将远逊于经过全面测试的系统，更别说和使用了测试先行（test_first）的设计相比了。

如果以为“使用既有系统多少可以节省成本”，于是试图生搬硬套某个既有系统，则是犯了严重的架构错误。例如，你可能会将BPEL组件和数据库触发器（trigger）结合起来开发异步消息系统。这样做或者坚持要这样做也许是出于便捷，也可能是因为自己或客户对这样的架构更熟悉。但是，在需求明确后，最先确定选用、不可或缺的应该是消息架构（messaging architecture）。项目之初的糟糕决策，会让重新设计系统架构以满足新需求的费用变得更为高昂。除了要避免在开发初期走径捷，发现有不当的设计决策时就要尽快修正，这点也很重要。设计不当的特征可难会成为后续特征的基础，将来需要花很高的成本来更正。

例如，假使发现为实现某个潜在功能而选用了不适合的类库，那就要赶紧把它们替换掉。否则，为使他们适用于新的需求，将不得不设计更多的抽象层次（layers of abstractions），以弥补前一层次的不匹配性。这样，每增加一层，都无异于将自己置身于一团乱麻之中，剪不断理更乱，系统终陷入无法维护的境地。

碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低时就动手。搁置越久，为之付出的利息也将越高。