技术选型
- 狭义：解决技术问题
- 广义：技术决策
误区
不尊重业务需求
随波逐流
面向简历编程
过度考虑
把别人的主观当事实
步骤
明确问题与目标
- 遇到了什么问题
- 目标是什么
- 评判技术选型标准
调研
- 真的需要额外的技术吗
如无必要，勿增实体
候选技术
- 从团队内部交流找到
- 从搜索引擎
- 日常积累
拓展技术视野路径：
- 开源中国
- thoughtworks技术雷达
对比
- 风险
- 成本
技术因素
如何选择开源技术: 聚焦于是否满足业务，而不需要过于关注开源项目是否优秀
- 官方活跃度
- 发布周期
- 提交历史
- README说明
- issue回复解决率
- 社区活跃度
- 搜索引擎热度、数量
- 辅助参考 star数
- 第三方社区
- 可维护性 可运维能力
- 学习曲线 难不难
- 性能
- 安全性
- 安全补丁及严重程度
- 熟悉程度
在线上使用开源组件，需要注意：
- 先深入研究，仔细测试
- 逐步灰度上线 持续观察
- 做好应急
- 数据备份
- 后备方案
非技术因素
- 被大规模采纳并获得成功
- 能不能快速招到人
- 平衡各方利益
- 法律问题
- license
- 炒作
方法
- 因素加减法
- SWOT分析
验证
- 小型原型验证
决策
- 相关人员 评审会议
落地
- 初期小规模试水 降低风险
总结复盘
技术选型与项目
短生命周期 糙快猛
长生命周期 成熟稳定的技术
边缘项目 可用来做实验尝试
核心项目 成熟、经验足够、拥有较好技术支撑
新项目 灵活
老项目 能与现有体系融合
探索项目 既要快 也要可维护 保障简单性
守成型项目 稳定第一
技术选型与团队
强 未来趋势 激进
薄弱 在现有体系下 加强规约
- 走出薄弱
小团队 简单性
大规模 细分问题域 自治技术选型
技术选型与组织架构
- 康威定律
技术栈版本
- 使用
- 功能
- 升级
- 新旧版本不兼容 使用新版
- 观望最新发布的次版本
- 使用BOM(bill of material)统一管理版本
- 尽量使用正式版
- 尽量LTS版本
- 关注软件间的兼容关系
失败补救
- 统一抽象逐步使用新实现替换老实现
对开源项目二次开发
- 尽量不要去动它本身的代码 把它包装起来提供外部接口 我们通过外部接口使用它
- 现在我们的基础框架就是这样 因为自身的业务需要对核心框架直接改动 导致升级框架版本很痛苦 升级也很容易出错
- 另外一个使用的Maxkey这个项目 初期改了很多 后面也升不动
当然，如果一个开源项目需要改动很多 那么证明其实这个项目并不适合你的业务 应该考虑自己造轮子了