架构取舍，权衡利弊，稍微资深程序员常说的话。今天，来聊聊我对架构取舍的理解。
取舍是你在做决策时就会出现的。当你决定要什么的时候，你心里应该要明白，你不可能，”既要，又要，还要“，所以你要取舍。当你有决策权，你会考虑去保留什么，而取舍则意味着你要放弃些什么。
就拿你站在食堂门口，思考今天中午吃什么（打工人的日常烦恼，痛点）？我想脑子里会浮现出一些想吃的清单（习惯本能），这时潜意识已经默默为你做了第一次取舍，为你保留一些可选项，然后你还会参考其他的因素，比如价格，心情，天气，朋友的意见等等，最终可能就是，全家便当。。。。。。
以上是我们日常小决策过程，其中我们会根据过往经验，朋友交流，咨询商家等方式，得出当前最佳的选择。
下面还想再讲个关于国家制定分税制改革的决策。
我们都知道，财政乃国之根本，国库“无粮”，其他一切事情都很难推进。在八十年代，那个处处搞承包制的年代，农村搞承包，城市搞承包，连政府财政也是搞承包。承包形式一般就是按分账比例，地方会根据比例上缴部分收入。该政策起初风生水起，效果极好，但随着社会逐渐转型等因素，国家财政需要付出更多的基础建设，财政入不敷出。于是国家决定调整上缴策略，先是向各地派遣专家进行一一调研，收集信息，分析后，给出了分税制的政策，对于大部分省份，都是非常愿意配合，但遇到上海，浙江，广东等大户，就非常难搞，部长亲自督办协商。。。。。。，原因也很明确，无非就是利益。（故事就不拓展了，有兴趣可以参考《置身事内》和《激荡三十年》）
以上是两种层面上做决策的方式，其实大体上大家的做法都差不多，只是面对的问题不一样，面对的利益相关人不一样。而今天说的架构也是如此。
日常在企业中做架构的机会，其实并不多（专职架构师除外），架构的机会是不多，但写代码是常事，你也会遇到很多需要自己思考取舍的地方，比如要不要抽公共方法，比如要不要运用策略模式等等。所以小事做好决策，大事来了也不慌。
从我的角度，架构取舍，权衡利弊，可能有以下几点：
还原问题的本来面貌
找背景，找现状，通找一手资料，还原问题的来龙去脉。其实就是理解问题。
与不同相关人沟通问题
做决策你需要有足够的输入，在搞不懂的情况下，那不是再做决策，而是在掷骰子。但这不意味你需要所有的知识，因为信息不全面时做决策往往也是常态。
收集分析思考，得出新的问题解
需要考虑，
定义问题的目标及范围，正如《演进式架构》一书中说的【适应度函数】，你需要有像轨道一样的框框，防止火车脱轨。
ROI（投资回报率）包括实现的成本，别人配合你改造的成本，及最终达到效果的成本。
根据成本，你可能会有 长期方案，过渡方案。
与相关人反复确认方案
人与人认知总是有偏差的，需要带动别人帮你思考，帮你完善方案。
之前领导说过，你需要把利益相关人放在同一条船上。
最后，不要怕犯错误。
好了，以上四点是我现阶段能想到的，做好架构取舍的需要做的事情。
这就是我对架构取舍的理解，不仅仅停留于取舍二字字面意思之上。
