系列目录导航👉

什么是技术选型，技术选型的重要性

• 根据实际业务管理的需要，对硬件、软件以及所要用到的技术进行规格的选择
• 狭义上的技术选型：团队决定选用哪种技术去解决问题，比如选用某个技术语言、某个技术框架去开发项目
• 广义上的技术选型：泛指项目实施过程中的各种技术决策
  • 制定了技术方案A & B，选择其中一套
  • 每个技术决策都是技术选型

案例

案例一：C轮跨境电商企业

• 贸然使用Service Mesh Istio
• 直接在开发环境中部署
• 不能很好的Hold住，遇到问题项目就延迟，经过很长时间适应期才正式上线
• 启发：决定采纳某个技术之前，做好调研，并尝试小规模引入，积累经验，经过验证后再大规模采用

案例二：某头部电商企业

• 早期使用Struts2.X，大规模使用标签 & OGNL
• 高并发场景下表现糟糕 👉 单机性能上不去
• 为什么要提升单机性能
  
• 启发：使用某个技术，甚至某个技术的功能点时，应经过一个较为严谨的测试

技术选型的误区

• 不尊重需求
• 面向流行趋势编程
• 面向牛叉（简历）编程
• 过度考虑
• 把看到的当事实

技术选型的步骤

明确问题与目标

• 当前遇到的问题是什么？
• 技术选型的目标是什么？
• 是否要引入额外的技术
  • 奥卡姆剃刀原理：如无必要，勿增实体
  • 一般来说，如果能在现有技术的基础上能够想办法实现目标，就不要贸然去引入新的技术
• 拓展技术视野的途径
  • 

对比技术的方法

技术相关的因素

• 官方活跃度：决定了在使用过程中遇到bug能否得到官方的支持
• 社区活跃度：决定了今后在使用中遇到问题，能否很快得到帮助
  • 搜索引擎关键词条目数
  • 谷歌趋势、百度指数
  • GitHub Star数
  • 第三方社区：ITeye、Spring4all、DockOne、Jdon…
• 可维护性：如果维护性不好，千万不要使用
• 学习曲线
  • 学习难不难
  • 开发难不难
  • 结合当前团队的技术特点以及熟练程度来考虑
• 性能：响应时间，TPS，存储容量，网络传输带宽要求等
  • 性能测试工具评测（JMeter、nGrinder、Gatling…）
  • 参考已有的性能评测文章
• 安全性
  • 检查它有多少的安全补丁以及严重程度，尤其是短期的安全补丁
  • eg：FastJSON、Struts2.X
  • 借助一些漏洞扫描工具，扫描是否有漏洞，eg：Tsunami
• 优先选用熟悉的技术
  • 而非高端的技术
  • “接地气”

技术意外的因素

• 是否有大规模使用并成功的案例：侧面论证技术的成熟性、实践证明了能用在生产
• 是否能够快速招募到人才
• 考虑并平衡各方利益：如果技术选型的过程中，某个利益相关的发言人没有参加过，就可能会导致不考虑他们的决策
• 法律问题
  • 商用解决方案 or 开源解决方案
  • License问题
  • 

项目、团队、技术选型的映射关系

项目维度

生命周期

• 短生命周期
  • 门槛低、简单易上手、开发速度快的技术
  • 开发过程也可相对自由
  • 糙快猛
• 长生命周期
  • 首先考虑可维护性
  • 优先考虑成熟稳定的技术

项目地位

• 边缘性项目
  • 影响面相对较小，有一定的故障容忍度
  • 项目的技术试验田
  • 尝试比较新颖的技术或者方案
• 核心项目
  • 稳定优先，做相对保守的技术选型
  • 优先选用比较成熟，团队内部已积累足够经验，同时有比较好的技术支持的技术。

项目新旧

• 新项目
  • 
• 老项目：优先选择能喝现有技术体系无缝融合的技术
  • 降低学习成本
  • 降低项目的风险
  • 便于后期沉淀到技术体系中去

探索性项目

• 不确定性高
• 既要快速
• 也要考虑到可维护性
• 优先保障简单性
• 不做太多预留
• 市场现状：初期只考虑快，等到项目爆发增长了之后，再把重心往可维护性偏移
• 通过业务敏感度、技术嗅觉、直觉，做技术上的预判

守成型的项目

• 稳定优先，不要轻易引入新技术
• 如果要引入新技术，则引入能够无缝地融入当前技术体系，且有人精通的技术
• 格局已定，不值得折腾

团队维度

技术实力

• 较强
  • 可结合项目的情况，一定程度上选择相对新颖的技术
  • 新技术往往代表技术趋势，代表更高的生产力
• 薄弱
  • 继续在现有的技术体系之下发展，不要做过多的折腾
  • 尽量平滑，控制在现有技术体系的范围之内，减少适应成本，降低风险
  • 增强团队交付纪律，定好技术上的约束
  • 走出技术薄弱的困境
    • 定期组织团队内的技术分享
    • 组织技术比赛
    • 1带n，梳理技术上的榜样

团队规模

• 小规模团队
  • 优先考虑技术的简单性、实施成本和效率
• 大规模团队
  • 团队人员能力层次不齐，汉南照顾到所有人的情况
  • 很难去听取每个人的建议和意见
  • 很难作出符合所有人利益的决定
  • 沟通噪声很大
  • 通过领域驱动设计等等思想，细分问题域
    • 把细分出来的问题，分给多个小规模团队去承接
    • 将问题交由各个团队自治，由各个团队主导去做技术选型
  • 如果无法细分，并指派给各个小团队：
    • 定好战略方向、战术方向、技术方向
    • 定好规约，把技术选型局限到一定范围内：例如只允许使用Java平台下的技术、只允许使用Spring生态相关的技术
    • 指定好团队的技术规范，让大家知道什么是不允许做的：例如禁止使用多个微服务共享一个数据库的方案、远程通信必须使用轻量级且能跨平台的协议

组织架构

• 康威定理：组织沟通方式会通过系统设计表达出来
• 项目架构其实是团队沟通协作方式而产生的一个结果
• 结合当前团队组织架构的特点：考虑选用的技术再最终技术架构中的位置、与当前团队沟通结构的匹配程度