系列目录导航👉
什么是技术选型，技术选型的重要性
- 根据实际业务管理的需要，对硬件、软件以及所要用到的技术进行规格的选择
- 狭义上的技术选型：团队决定选用哪种技术去解决问题，比如选用某个技术语言、某个技术框架去开发项目
- 广义上的技术选型：泛指项目实施过程中的各种技术决策
- 制定了技术方案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生态相关的技术
- 指定好团队的技术规范，让大家知道什么是不允许做的：例如禁止使用多个微服务共享一个数据库的方案、远程通信必须使用轻量级且能跨平台的协议
组织架构
- 康威定理：组织沟通方式会通过系统设计表达出来
- 项目架构其实是团队沟通协作方式而产生的一个结果
- 结合当前团队组织架构的特点：考虑选用的技术再最终技术架构中的位置、与当前团队沟通结构的匹配程度
