模版-技术调研文档
参考文献
思考
- 在决定是否需要进行技术调研时,可以从以下几个关键点出发来评估其必要性:
- 新技术的应用: 当考虑采用一种新的技术时,如果该技术的社区支持尚未成熟,可能存在一定的实施风险.此时,进行详细的技术调研有助于全面权衡利弊,确保选择最适合项目的解决方案.
- 功能验证的需求: 如果对某个特定功能的实现可能性存有疑问,建议通过构建一个简易的演示项目(demo)来进行初步验证.这不仅能帮助你了解该功能的实际可行性,也能为后续开发提供宝贵的经验.
- 框架或库的选择困惑: 面对多个可供选择的框架或库时,不确定哪一个最符合项目需求.在这种情况下,技术调研显得尤为重要.它可以帮助你深入了解各个选项的特点、优势以及潜在局限,从而做出最佳决策.
- 时间成本考量: 值得注意的是,对于那些仅需花费几分钟就能明确答案的问题,可能不需要进行全面的技术调研.合理评估投入与产出比,确保资源的有效利用.
技术选型四板斧
- 需求分析
- 方案调研
- 方案对比
- 方案确定
方案调研
- 资料收集
- 搜索: 谷歌/Github
- 书籍/Github stat/日常阅读/笔记库
- 现有已知项目是否有类似的方案?
- 明确方向
- 业界竞品: 主要看文档-能力版图/领域知识
- 开源: 看实现
- 类似方案: 看机制
- 确认细节
- 调研到什么程度?
- 你必须完全知道每一个关键细节是如何实现的
- 调研到什么程度?
方案对比
- 没有最完美的方案,只有最合适的方案
- 合适 = 现实 * 期望
合适原则
- 合适原则: 合适优于业界领先
- 简单原则: 简单优于复杂
- 演化原则: 演化优于一步到位
- 务实
- 合适但是也不能太落后
- 简单但是要能满足现在以及未来可见范围内的需求
- 演化但是要底子要好,必须要赢在起跑线
稳定依赖原则
- 稳定依赖原则: 依赖关系必须要指向更稳定的方向.
- 预期会经常变更的组件都不应该被一个难以修改的组件所依赖,否则这个多变的组件也将会变的难以修改.
- 稳定性指标 = 出依赖 / ( 出依赖 + 入依赖 )
确定方案
- 可扩展性
- 协议上支持,但是不实现
- 接口上支持,但是不开放
- 存储上支持,但是不使用
模版正文
背景
- 说明一下为什么需要调研,即列举一下需求文档以及其他相关文档,方便后续他人了解上下文
现存方案
- 该段落主要收集市场上一些正在使用的方案或一些开源的方案并说明一下这些方案解决什么问题或痛点?
方案对比
-
对比关键的几个方案(已匹配需求),详细对比它们的优缺点.基于以下几个方面展开对比:
-
官方介绍
-
提取理论依据: 仔细阅读官方文档、
GitHub
仓库中的README文件以及相关的GitHub Issues
.这可以帮助您了解每个方案的设计目标、主要功能及其适用场景. -
用户反馈: 查看GitHub上的用户反馈和问题讨论,特别是那些与需求直接相关的问题,从中获取第一手资料.
-
-
活跃度
-
社区活跃度: 通过观察
GitHub Issues
的频率、npm
趋势等指标来评估项目的活跃程度.一个活跃的社区通常意味着更快的问题解决速度和更好的长期支持. -
贡献者数量: 项目贡献者的数量也是衡量其活力的一个重要标志,更多的贡献者往往意味着更快速的功能迭代和bug修复.
-
-
可维护性
-
使用复杂度: 考虑API设计是否直观、易于理解和使用.一个好的方案应该具有较低的学习曲线,便于团队成员快速上手.
-
额外学习成本: 除了基本的使用方法外,是否需要掌握额外的知识或工具来有效利用该方案.
-
业务侵入度: 评估方案对现有业务逻辑的影响程度,理想情况下,应选择那些能最小化对当前系统改动的方案.
-
最佳实践: 查阅社区中关于如何更好地使用该技术的最佳实践案例,这些信息对于确保项目的可维护性和扩展性至关重要.
-
-
性能
-
依赖体积: 检查引入该方案后对项目整体大小的影响,特别是在前端项目中尤为重要.
-
执行效率: 可以通过官方提供的性能数据或者第三方benchmark测试结果来比较不同方案的运行效率.
-
社区
benchmark
: 查找社区内已有的性能对比测试,以获得客观的性能评估.
-
-
原理
-
理解原理: 对于小型库而言,尝试深入理解其背后的实现原理,这对于判断它是否真正符合您的需求非常有帮助.同时,在未来遇到问题时也能更有效地进行排查.
-
匹配度确认: 基于原理分析进一步确认该方案是否真的能够满足您的具体需求,避免表面看起来合适但实际上并不契合的情况发生
-
-
-
根据以上几个维度形成对比表格,方便直观的看出优缺点.
结论
- 给出一个清晰的调研结论,不能遗留不确定的问题
参考文档
- 贴上一些关键文档,作为调研结论的支撑依据