Question

逻辑是因为其必要性的存在而存在的。

田忌赛马中的胜负并不一定是由马的脚力决定的。即使田忌的马都比齐威王的好，他也不能场场都胜；就算是胜了，最好的法子也是把马献给齐王。所以，“赛马以取胜”这一逻辑，是因 “若与齐王赛马取乐，则不能常输”而存在的。一旦田忌将军是常胜，那上面的逻辑必要性也就不存在了，那时“赛马求败”反倒是可能的逻辑。

架构角色往往追求系统整体的必要性，他因此必须预见到“何谓系统整体”，并判断出系统整体的、核心的目的。以田忌赛马而言，系统整体是田忌与齐王双方，目的是使君臣齐乐，最后才决断出“取胜”的必要性。以具体软件系统的架构而言，架构师必须判断的是哪些地方该考虑性能高低，哪些地方该做功能增补；哪些地方宜先实施而后优化，哪些地方又必须先找出最优解再做实施；哪些地方可以通过产品选型来购置，哪些地方必须自主研发……这些都是架构在系统的组织结构上要考虑的事情。但如果相同的事情交由程序员来判断，则答案可能就缺乏了轻重缓急的权衡；交由项目经理来判断，则答案又可能偏离系统的事实而难于实施。

架构是最没有安全感的角色。在架构师的眼中一切都可能存在，也都可能湮灭于一霎：千日之功，亏于一篑。之所以架构师对任何一个选择都没有绝对的信心，是因为架构这一角色对系统提供的总是“可能性”，而非必然性。从这一点出发的架构师有三种。第一种是 殚精竭虑型 的，这种人总会认为系统的一切与自己都有关，也将一切的安危系于自己一身；第二种是 置身事外型 的，这种人总认为系统的成败其实只是系统自我发展的结果，而架构师只是系统的观察者、考量者与守护者。以上两种架构角色其实都过于极端，对系统的发展都是趋害的。第三种架构师则会 在这二者之间觅求平衡 ，他应知轻重缓急，熟稔何时把握什么，争取什么，以及推动什么；他还应知刚柔曲直，攻守并济，把生死看成系统的第一要务，把时间看成调节生死的阀门。

好的架构师会在系统出现急难之前就对你发出警告，更好的则已经提出过解决方案，再好一些情况下，架构角色已经要求你与团队一起预演过这样的方案了。但是一旦急难发生，你需要的是技术高手，是实施团队，是那些在代码中摸爬滚打的程序员。因为这时候再谈架构，无异于房子着火了却仍在埋怨“我们没有安消防栓”。若“着火了，且没安消防栓”已是既成事实，那就应该加大水的输送或鼓动消防队员奋勇争先，尽一切可能去灭火，这才是上策。我们可以追究一个架构师在“如何部署消防栓”和“没有提供着火时的应急措施”这两件事情上的失职，但这种追究或是在事前，或是在事后，切不可以事中。

架构的危险性也正在于此：架构师的失职是无法补偿的。架构师只有尽可能全面地评估系统中“所有可能的”问题与方案，并尽可能使团队与系统处于安全边界以内。退而求其次，危机一旦发生，架构也要保证提供可能的应对之策。

架构师要做的事情，任何一个角色都可以去做，但架构师所需的素质，却在“做”那些具体事务的能力之外。这并不表明架构师眼高于顶、手低于足。须知架构这一角色必备的是眼界与敏锐：放开眼界，才能看得到危机；切中利弊，才能控制系统代价。我们可以要求架构师是行动派，但架构师必须控制自己不要变成冲动派。

行成于思，毁于随。