22 | 如何为项目做好技术选型？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
技术选型在项目中至关重要，需要考虑时间、范围和成本约束，分析可行性和风险，以及考虑利益相关人的意见。为了科学客观地做好技术选型，可以设计一套流程，包括问题定义、调研、验证和决策。在验证阶段，实际应用技术方案是必要的。最终决策需要召集所有利益相关人一起评审，以提高做出正确决策的概率。总结时要对之前的技术选型和项目决策做总结，不断完善机制。技术选型不应过于纠结，要勇于决策并坚定执行。
《软件工程之美》，新⼈⾸单¥59
全部留言(20)
- 最新
- 精选
Y024
Appfuse（一个 Web 开发基础平台）的作者 Matt Raible 曾总结了选择 Web 框架的 20 条标准： http://static.raibledesigns.com/repository/presentations/Comparing_JVM_Web_Frameworks_February2014.pdf 同时，他也整理了一份表格，你可以根据自己的权重进行调整，产生自己的分析： https://docs.google.com/spreadsheets/d/12l0sZNVSnwxcxs3CtcjeaCcI8rXjTrrldfTBZn7grD8/pub?hl=en&output=html# 但是现实情况，大家可能更遵循的是“经济适用原则”，比如：很多人提到的，负责人会啥就用啥。或者大公司用啥或者业界流行什么就用什么。 有位大佬说过，“这个世界是，你认为有很多选择，其实只是幻觉，大多数人只有很少的选项。技术研讨会，搞一个选型：hadoop + mysql + xx 时髦技术。架构师唾沫四溅吹一下午，结果老老实实上 Oracle 单例。”作者回复: 👍非常有价值的分享！ 我觉得在纠结的时候，遵循“经济适用原则”蛮好的，不会犯大错误，老老实实选熟悉的成熟稳重的把需求满足好才是王道。 "make it Work Make It Right Make It Fast"
2019-04-2118
小伟老师后面会有介绍文档编写吗？我们组现在有mrd/prd/概要设计/接口设计/详细设计。 我的疑惑是其他团队不是这个样子的，我想问下，比较规范的文档有哪些，他们功能分别是什么？作者回复: 很抱歉我们专栏后面没有介绍文档编写的文章了。 对于瀑布模型，每个阶段结束后，都有相应的验收文档，而敏捷开发则没有那么多硬性的要求，而是根据项目需要，写必要的文档。 你说的这些文档已经算比较全面了，有些团队对于测试阶段，会有测试用例文档、测试验收报告，发布前还会有部署文档、维护手册，但现在这类文档基本上被测试工具、部署脚本替代了，也没有什么存在必要。 我觉得项目中必要的文档，主要包括这几类： 1. 设计类文档 这类文档主要用来说明、讨论需求设计、架构设计，可以用来了解、讨论和评审，以及记录后续结果。 2. 说明类文档 这类文档用来对规范、API、配置、操作等做说明，便于规范和统一 3. 报告类文档 对事情结果的报告和说明，比如说验收报告、故障报告、调研等。 而这些文档的价值，在于帮助成员了解设计、参与讨论，记录项目成果，减少沟通成本。重要的不是文档多丰富，而是这些文档有没有价值，你能不能及时通过这些文档得到想要的答案。所以你也可以对照一下你的项目中，现在的文档中，哪些是可以简化的，哪些地方是要增强的。 比如说概要设计/接口设计/详细设计是不是可以适当合并，减轻文档工作？PRD如果是不是够详细？会不会引起歧义不容易理解，要不要增加原型设计文档辅助？
2019-04-1811
易林林技术选型中，不考虑金三角理论的情况下，我会倾向于选择新酷的技术，这样有利于自己全面了解技术的发展趋势，更新自己的技术思维，感受技术革新带来的乐趣。另外，在维持项目稳定推进的状态下，尽量尝试使用新酷的技术，毕竟作为技术人总是淘汰于技术，更是成长于技术。 金三角理论很好的提供了技术选型的方向。时间短，选择项目组成员熟悉并且成熟的技术，这样发现问题也能快速的查到问题的关键；成本低，尽量减少资源的开销，比如开发APP，不使用原生开发，而使用跨平台的技术架构是比较好的选择，维护也方便；范围不明确，通过原型设计、敏捷开发的方式，逐步清晰项目范围。当然，这只是从单一的角度来考虑，考虑到金三角理论的相互组合，就要在二选一中进行平衡，更加考验当事人技术选型的综合能力。 关于“听到的当成既成事实”这一点，深有感触。现实中，有些东西听到了，即使它不是事实，也会留下一个阴影，在合适的时候一旦被催化，那在心里面就成事实啦，你会想方设法的去证明它是事实，而不会在乎其本质所在。软件技术选型也是这样，在选型的时候，我们可以参考别人的意见，搜集各方面的技术资料，来达成自己对相应技术的基本判断，不因自己不懂而去选择别人懂的技术，这样会导致项目的风险不可控。对于这点，我是有切身体会的，甚至是愧于面对曾经领导的信任，至今仍无法释怀。 最后，请教下宝玉老师，上一讲中您提到极客时间的技术架构好像不是微服务架构，您能指点下这样选型的目的和原因吗？谢谢。作者回复: 👍谢谢补充分享。 关于极客时间架构，我是从池建强那篇文章中推测的，这个我确实不了解他们选型的目的和原因。 如果是我的话，现阶段也未必会选择微服务，微服务对运维要求更高、对架构要求更高，像极客时间现阶段的重点应该是功能和稳定性，直接上微服务，必然要花大量精力在架构的重构和运维上面。 不如先用熟悉的、稳定的技术，满足好现阶段业务增长，等到业务稳定，团队规模、用户量上来以后，再考虑拆分微服务不迟。
2019-04-188- alva_xu另外，对于开源技术方面，老师有没有什么经验来指导选型？
作者回复: 开源技术选型，我的经验一般是这样的： 1. 先找朋友推荐，少走一点弯路 2. 没有推荐的话，就去网上搜索，找几个满足需求的备选。 3. 对比以下几个指标： - 代码质量、有无测试 - 文档健全度 - 看Issue处理情况、最后更新时间（无人维护的项目后续恐怕有问题都没法解决） - 看Star数量，通过Google和StackOverflow看使用情况 4. 自己按照说明试试看
2019-04-1827 
bearlu主管会C++，然后什么都是C++😂作者回复: 这确实是个事实，很多技术选型就是技术负责人擅长什么、喜欢什么而决定的。 但很多时候这也是有原因的，先抛开个人喜好的因素不说，初期的时候团队人少，没有什么好选择的，只能是负责人会什么就是什么。后面团队虽然壮大了，但是更换语言或者技术平台成本就高了。 这篇关于Youtube选型Python的文章就很有意思，也是类似的情况。 《在大型项目上，Python 是个烂语言吗？ - 布丁的回答 - 知乎》 https://www.zhihu.com/question/21017354/answer/652602653
2019-04-1827
陈珙在没有特殊要求的情况下，项目中更加倾向选择更为熟悉的技术，因为我们需要对项目的质量与交付时间负责，可以做到可控的。而新技术有着新的设计思想与强大的功能，同时也伴随着无法预知的”坑”。在后续产品迭代的时间里，有针对性的升级或者选择更换同类技术里更优的。作者回复: 是的，正式项目应该尽可能选择熟悉的、成熟的技术👍
2019-04-184- alva_xu技术选型，确实就是项目决策。考虑的角度应该可以参考“09可行性研究"中的技术可行性部分。就是从人员、技术、风险三个角度来考虑。技术有大有小，比如传统框架和微服务框架的选择，就是一个大选择。需要选型的技术在项目和产品中的重要性决定了选型时的风险偏好。团队对技术的熟悉程度，或者学习曲线，也是需要考虑的。另外，我觉得还可以用“天时、地利、人和”这三个角度来进行技术选型。 老师文章中主要讲了技术选型的流程，我想请教老师的是，有没有什么大的原则可以指导技术选型？比如技术成熟度等？
作者回复: 我认为在满足设计目标的前提下，大的原则还是在于项目约束，尤其是成本和时间，然后就是技术可行性和风险是不是可控，其他看团队风格，有的偏保守有的追新。 比如说我自己的原则： 1. 成熟的好过新酷的 2. 流行的好过小众的 3. 团队熟悉的好过陌生的 4. 简单的好过复杂的 5. 开源的好过商业的（有时候也视情况而定） 仅供参考
2019-04-183 
Aaron Cheung楼上说的 深以为然作者回复: 已回复楼上：）
2019-04-183
邢爱明项目团队的开发人员，基本都是从外包公司临时找的，水平参差不齐，稳定性差，因此技术选型更多的考虑技术的普及度和容易学习掌握，从这方面看基本不太可能选择比较小众、但在特定领域很高效的技术。 加上是企业内部管理的系统，数据量和用户数量可控，因此存在技术瓶颈的可能性很小，综合下来看就最好的选择就是最成熟和通用的技术，比如说选择java技术栈，web开发的ssm框架等，但这样长远看团队和个人的技术能力很难提升，请问老师在这方面有什么建议？作者回复: 我觉得团队的技术提升和项目的技术选型要分开，不要总想着两个都兼顾，优先保证好项目稳定、低成本运行。 技术提升这种事，需要让一部分人先成长起来，然后带动其他人。 我自己工作之外会做一些业余项目，然后在这些项目中体验新的技术，体会其中优缺点，然后再逐步应用到工作的项目中，在传授给同事们。 我也鼓励其他同事这么做，去做一点自己的项目。但工作中的项目，我是很保守的。
2019-04-202
Charles三四线城市，技术选型前期主要考虑： 当地市场什么人才比较充足，比如后端PHP人多，那就PHP，学习成本也低，几人团队协作起来也不是大问题，而且前期扩充人员也比较好招人，另外前期应该也不会在语言层面出现性能问题 然后数据库基本就mysql，够熟悉够成熟 前端的话web、小程序、ios、android之类的都统一mvvm思想进行前后端分离开发，这样各个用户端都可以统一API提升效率，这个也会从产品角度思考，如果产品就需要一个pc站，而且短期也没计划就选择传统的后端渲染web页面方案 可能会站在目前项目或经历过的项目经验去思考问题，期待老师回复指正作者回复: 我觉得你的选型思路在项目发展阶段，包括没有很大规模之前都是没有问题的。选最熟悉的、流行的往往也是风险比较低的。包括如果就一个PC站也不做SPA（单页应用），也没有必要前后端分离。还是看是不是能低成本满足好项目需求和业务发展。 有一点补充的，就是前端除了MVVM，像React的Flux和Redux的架构模式，也是一种很好的架构模式，但在非Rect/Vue的项目中应用不多。
2019-04-182
