28 先尝试后决策

创建一个应用需要作出许多决策。有些决策涉及挑选框架和函数库，而另一类则需要选择特定的设计模式。不管哪种决策都需要架构师拿主意。平庸的架构师可能会收集手边的信息，斟酌酝酿一番，然后从象牙塔里颁布解决方案让开发人员实现。无疑，还有比这更好的方法。

玛丽.波彭代克和汤姆.波彭代克夫妇俩在著作中描述了一种制订决策的技巧。他们主张尽量推迟决定的时间，最后即使团队不作决策，决策也会自己呈现－－等待不易逆转的结果。这是种审慎的技巧，因为越晚作出决策，可利用的信息就越多。但是在很多情况下，“更多的信息”并不等于“充分的信息”，而且完美的决策只可能出现在事后。那么架构师应该如何使用这种技巧呢？

架构师应该持续关注那些马上要制订的决策。假设团队中有多位开发人员，并且代码所有权属于整个开发队伍，架构师可以在决策时间点到来之前，要求几个开发人员商量出解决方案，尝试一段时间。当决策时间点临近时，召开会议比较不同解决方案的优点和弊端。通常由于做过尝试，这时大家对问题的最佳的解决方案已经有了共识。架构师只须组织协调制订决策的过程即可，不必自己作出决策。

这个方法既适合决定简单的问题，也适用于复杂的问题。既可以帮助团队决定是否使用Spring框架提供的Hibernates模板，也可以用来决定挑选哪个JavaScript框架。但很显然，问题的复杂度会影响制订决策的时间。

对同一个问题尝试两种或两种以上的解决方案，比直接决策然后动手实现的工作量要大。但是，如果事后发现仓促决定的方案不合适，架构师将陷入进退两难的困境：无论是放弃目前的方案还是继续开发，都会造成误工和损失。更糟糕的情况是没人发现方案不合适，在这种情况下，甚至察觉不到损失。总之尝试多种解决方案可能是代价最低的选择。