确保简单问题有简单的解

作者：查德·拉·瓦因（Chad LaVigne）

软件架构师解决了很多非常困难的问题，但是也会去解决一些相对容易的问题，对于简单的问题，不要使用复杂的解决方案。这个建议听上去显而易见，但是遵循却不容易。软件设计者都是聪明人，真的很聪明，但是出于炫技心理，很容易陷入“杀鸡用牛刀”的误区（simple problem-complex solution trap）。如果发现自己正在设计一个非常聪明的解决方案，也许应该对此保持警醒自觉（self-aware），停下来想想：解决方案是否对症？如果答案是否定的，则需要重新设计中的各个选项。对简单问题要保持简单的解（keep the simple stuff simple）。架构师展示才华的机会多的是，只要真正的难题出现，总有这样的机会。

但这并不是说不要追求漂亮的解决方案，而是指，如果我们的任务是设计这样的系统；它只需要支持销售单一种类的基于SKU（Stock Keeping Unit，最小存货单位）的商品，那么，设计成支持可动态配置产品层次结构的系统可能就是糟糕的主意。

为复杂解决方案付出的真接成本可能看上去很小，但是其潜在成本要大得多。和开发层面的过度工程一样，架构上的过度工程（over-engineering），会导致许多问题，但其带来的负面影响则往往会成倍增加。错误的架构设计决策会使系统实现困难且不易维护，最糟糕的是，实现是无法逆转（reverse）的。在往前做出超越系统实际需求的架构决策时，不妨自问：照此实现之后，如果要再退回去会多么困难？

为有问题的解决方案付出的代价，不仅仅只是在实现和维护上。在简单问题上耗费了过多时间，则留给解决复杂问题的时间相对就少了。不当的架构决策陡然间导致了范围的蔓延，往项目中增加了不必要的风险。如果你能保证其他人也不会这么做，你的时间利用率就会大大提升。

架构师会从主观的判断或潜在不确定需求出发，产生调整解决方案的强烈冲动。请记住一点。试图猜测未来的需求时，错的概率是50%，错的很离谱的概率是49%。今天只需要解决今天的问题就好。把应用发布出去，从反馈中生成真实的需求。由于己经创建了简单的设计，当真实需求到来时，要将之整合进来就会更加容易。如果刚好运气不错，先前猜测的需求在下一个发布版本中变成了真实的需求，那现在更是成竹在胸了，与之前不同的是，现在可以估算出更合适的时间分配了，因为这次它己经变成真实的需求。不知不觉间，团队就会获得“能做出精准的预估，按时完工”的好名声了。