架构师技术选型的思考

朋友在规划公司内部的技术栈，梳理现有项目技术栈不够规范的问题。涉及的项目种类较多，在给出建议后，我觉得可以写一篇文章说下。

朋友提出的实际包含两类问题，第一类涉及现有项目的改造，第二类对新项目技术栈的选型决策。这篇文章主要讨论第一类问题，第二类问题可以后面再介绍。

首先在评审选型决策的时候，需要重点关注：1）支撑事实是否充分，技术决策需要有严谨的事实支撑，已有的事实可以引用，不清晰的需要调查或预研。决策前技术人员沟通需要提供的各类维度/指标，决策时审查每个纬度的支撑事实是否充分；2）是否仔细考虑了技术风险，对主要的技术风险点识别往往是项目成败关键。

具体到这类问题，我的几个建议是：

1 思考原则(Principles/Rules)

原则是明确的，方向性的指导意见，可以是战略(Strategy)，战术(Tactic)或更细执行层面的。例如大的层面：某公司要求核心技术必须自研，旗舰手机必须使用自研芯片；项目早期版本某些模块使用更昂贵的器件先实现功能验证模式，后续再考虑压缩成本(Cost Reduction)；实现层面：某项目物联网协议设计使用JSON，而非0/1硬编码。

明确原则的好处有 1）有利于和领导沟通，理解老板的真正需求(Needs, not Wants)，把握正确的方向；2）有利于向下沟通，避免信息传输过程中过度流失 3）有利于在原则的指导下应对变化，例如"不拿群众一针一线"，遇到新情况，"群众的鸡蛋也不能拿"。4）有利于授权，明确目标，在达成目标的框架内提供灵活性/信任 5）避免过早进入不必要的细节，干扰大的决策。

这里要提一点的是沟通方面一种不易察觉的情形：很多时候不能达成一致，或争论不休是没有意识到看起来在讨论同一个内容，但实际上是在不同层面讨论，各说各话，讨论者应意识到对方在哪个层面讨论问题，把他拉回或者跳到他所在的层面展开讨论，从基础的共识开始逐步建立(Buildup)更大的共识。如果基础共识层面没有达成一致，要看障碍/分歧在哪，先消除分歧或在假设的前提下继续讨论。

2 掌握业务形态/需求(Requirements)

技术为业务服务，提高系统稳定性/开发/运维效率等，要考虑如何更灵活/快速地支撑业务需求（能够快速适应新的需求，这是技术人员一个大的成就感来源）。不同的业务有不同的形态，需要根据业务形态来选型，适应业务的变化。例如：项目对稳定性要求高，而团队缺乏该方面的经验时，尤其在项目初期，技术选型中考虑购买有较好生态支持的商业模块的权重会比较高。

有时是业务驱动技术，有时是技术带动业务，架构本身也是变化演进的，没有一开始就设计好的万能架构，设计不足和过度设计都会带来伤害。项目的各阶段会有其不同的任务/侧重点。

当系统支撑的业务量快速增长时，之前的架构一定会需要优化演进，很多人担心因此对系统的影响，这种类型的问题是我们通常说的good problem，业务高速发展，项目的成功会吸引大量的资金和更优秀的人才进来，比项目起步阶段的形势会大幅改善，还有什么好担心的呢？

但如果一开始就考虑太复杂，团队技术不够聚焦，系统的复杂度显著提升，反而容易失败。最稳定可靠的系统是简单的，逻辑清晰的系统。

技术应聚焦于项目/产品目标的达成，是依于当前形势/人员结构/需求成熟度/市场情况所能做的决策，也要防止和避免马后炮思维。

3 调研和收集反馈(Research&Feedback)

涉及到项目改造需要考虑改造的价值，技术风险，人才结构，改造时间点，改造范围等等。充分收集和听取包括领导，项目骨干及其它各方的反馈，谨慎决策。沟通必须分阶段尽早沟通。

越是重大的决策越要冷静，避免陷入拍脑袋思维模式。高级的技术人员，往往在决策时会越谨慎和细心。

另外，简单提下开会收集意见。

开会的时候要鼓励发言，尤其是对有不同意见的同事要保护，反对意见往往会促成反向思考；要识别每个人的特点，有些同事表达意见较强势滔滔不绝，有些同事需要round table或者点名才发表意见；有的同事有时会上不善于表达意见，可以私下先征求意见。差异化是一个团队珍贵的财富。

有些同事听不得不同意见，或者觉得已经够清晰了，不需要再讨论了，觉得在浪费时间，实际上多花一些时间听听是值得的，否则容易打击发言者的信心，下次反而没人说话了。

运作一段时间后，大家都清楚，只要是对项目有利的，什么时候都能说，说什么都鼓励，即便是临近交付（阶段性的交付其实从2～5年或者更长的产品周期来看，很多时候是处于早期阶段），都敢于大胆提出来（诚实意味着可信赖）。是项目就会存在问题，问题一旦提出不管是短期的还是长期的一定会有解决办法，技术人员要有这个意识和信心。

4 需要思考清晰的路线图(Technical Roadmap)

技术路线图体现了在满足业务需求，综合考虑时间/成本/质量的情况下，对技术的实现做的规划。这里有很多因素要考虑，例如产品的路线图，技术成熟度，技术风险的清除/验证，核心技术竞争力的构建周期，团队对产品的理解力/经验爬坡/团队组建磨合过程等。这里面有时候要顶住一些业务的交付压力，避免返工/伤害质量/过度承诺。

例如需改造项目以适应未来的业务发展，在其它方面权重差不多的情况下，可以考虑挑选一些比较典型的，技术风险相对低的项目开始(这里面也要考虑产品处在其生命周期的哪个阶段)。首先可以验证你的组织结构是否合理，人员是否到位，流程是否顺畅，也相对容易鼓舞士气，增强领导及各方面继续推进项目的决心/信心，在复盘后推进更有难度的项目。

技术人员要和产品运营等紧密合作，在项目进行过程中持续跳出来思考，正在做的和将要做的是解决什么问题和目标，哪些是核心价值，这个和OKR理念比较类似。产品或者其变种往往是在核心竞争力外面包装的不同产品形态。

这篇文章先介绍到这，要补充一点的是，不同项目，或者同一项目进行过程中业务/人员/形势都是不断发展变化的，决策并不是一层不变的，每个时期有它的重点，要分析影响维度，也要识别哪些是关键因素(Dominant factors)，根据实际情况调整决策。

作者：客柳新王剑

来源：从零开始学架构