软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

22 | 如何为项目做好技术选型?

宝玉 2019-04-18
你好,我是宝玉,我今天分享的主题是:如何为项目做好技术选型?
在架构设计过程中,肯定绕不开技术选型这个话题,大到架构、框架、语言选择,小到用什么组件、设计模式。
这也是最容易引起争议的话题,无论是现实中还是网上,到处有各种语言、框架的争论:Java 好还是 C# 好?前端框架是 Vue 好还是 React 好?跨平台手机开发,该选 React Native 还是 Flutter……
虽然这种争论从来没什么结果,但当你做技术选型时,却很容易受到这些信息的干扰,尤其是你身边有几个某种语言或者框架的狂热粉丝的话,他们会不停地在你旁边吹风,说他喜欢的语言或框架的各种好处。
包括我们自己做技术选型时,也会有很多个人偏好在里面。比如我以前对微软技术栈特别熟悉,也特别喜欢,做技术方案就会偏向微软技术栈;我喜欢 React,做前端技术选型,也会偏向 React 的方案。
通过上一篇架构设计的学习,我们知道,架构设计的主要目标,是要能低成本地满足需求和需求变化,低成本地保障软件运行。然而对技术的个人偏好,很可能让你在技术选型时,忽略架构设计的目标,导致满足需求的成本变高,或者运行成本居高不下。
所以今天,我们一起来探讨一下,在软件工程中,怎么样才能避免这种选型的倾向性,科学客观地做好技术选型。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(17)

  • 极客不落🐒
    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-21
    9
  • 小伟
    老师后面会有介绍文档编写吗?我们组现在有mrd/prd/概要设计/接口设计/详细设计。

    我的疑惑是其他团队不是这个样子的,我想问下,比较规范的文档有哪些,他们功能分别是什么?

    作者回复: 很抱歉我们专栏后面没有介绍文档编写的文章了。

    对于瀑布模型,每个阶段结束后,都有相应的验收文档,而敏捷开发则没有那么多硬性的要求,而是根据项目需要,写必要的文档。


    你说的这些文档已经算比较全面了,有些团队对于测试阶段,会有测试用例文档、测试验收报告,发布前还会有部署文档、维护手册,但现在这类文档基本上被测试工具、部署脚本替代了,也没有什么存在必要。

    我觉得项目中必要的文档,主要包括这几类:

    1. 设计类文档
    这类文档主要用来说明、讨论需求设计、架构设计,可以用来了解、讨论和评审,以及记录后续结果。

    2. 说明类文档
    这类文档用来对规范、API、配置、操作等做说明,便于规范和统一

    3. 报告类文档
    对事情结果的报告和说明,比如说验收报告、故障报告、调研等。

    而这些文档的价值,在于帮助成员了解设计、参与讨论,记录项目成果,减少沟通成本。重要的不是文档多丰富,而是这些文档有没有价值,你能不能及时通过这些文档得到想要的答案。所以你也可以对照一下你的项目中,现在的文档中,哪些是可以简化的,哪些地方是要增强的。

    比如说概要设计/接口设计/详细设计是不是可以适当合并,减轻文档工作?PRD如果是不是够详细?会不会引起歧义不容易理解,要不要增加原型设计文档辅助?

    2019-04-18
    6
  • kirogiyi
    技术选型中,不考虑金三角理论的情况下,我会倾向于选择新酷的技术,这样有利于自己全面了解技术的发展趋势,更新自己的技术思维,感受技术革新带来的乐趣。另外,在维持项目稳定推进的状态下,尽量尝试使用新酷的技术,毕竟作为技术人总是淘汰于技术,更是成长于技术。

    金三角理论很好的提供了技术选型的方向。时间短,选择项目组成员熟悉并且成熟的技术,这样发现问题也能快速的查到问题的关键;成本低,尽量减少资源的开销,比如开发APP,不使用原生开发,而使用跨平台的技术架构是比较好的选择,维护也方便;范围不明确,通过原型设计、敏捷开发的方式,逐步清晰项目范围。当然,这只是从单一的角度来考虑,考虑到金三角理论的相互组合,就要在二选一中进行平衡,更加考验当事人技术选型的综合能力。

    关于“听到的当成既成事实”这一点,深有感触。现实中,有些东西听到了,即使它不是事实,也会留下一个阴影,在合适的时候一旦被催化,那在心里面就成事实啦,你会想方设法的去证明它是事实,而不会在乎其本质所在。软件技术选型也是这样,在选型的时候,我们可以参考别人的意见,搜集各方面的技术资料,来达成自己对相应技术的基本判断,不因自己不懂而去选择别人懂的技术,这样会导致项目的风险不可控。对于这点,我是有切身体会的,甚至是愧于面对曾经领导的信任,至今仍无法释怀。

    最后,请教下宝玉老师,上一讲中您提到极客时间的技术架构好像不是微服务架构,您能指点下这样选型的目的和原因吗?谢谢。

    作者回复: 👍谢谢补充分享。

    关于极客时间架构,我是从池建强那篇文章中推测的,这个我确实不了解他们选型的目的和原因。

    如果是我的话,现阶段也未必会选择微服务,微服务对运维要求更高、对架构要求更高,像极客时间现阶段的重点应该是功能和稳定性,直接上微服务,必然要花大量精力在架构的重构和运维上面。

    不如先用熟悉的、稳定的技术,满足好现阶段业务增长,等到业务稳定,团队规模、用户量上来以后,再考虑拆分微服务不迟。

    2019-04-18
    6
  • bearlu
    主管会C++,然后什么都是C++😂

    作者回复: 这确实是个事实,很多技术选型就是技术负责人擅长什么、喜欢什么而决定的。

    但很多时候这也是有原因的,先抛开个人喜好的因素不说,初期的时候团队人少,没有什么好选择的,只能是负责人会什么就是什么。后面团队虽然壮大了,但是更换语言或者技术平台成本就高了。

    这篇关于Youtube选型Python的文章就很有意思,也是类似的情况。
    《在大型项目上,Python 是个烂语言吗? - 布丁的回答 - 知乎》
    https://www.zhihu.com/question/21017354/answer/652602653

    2019-04-18
    5
  • alva_xu
    另外,对于开源技术方面,老师有没有什么经验来指导选型?

    作者回复: 开源技术选型,我的经验一般是这样的:
    1. 先找朋友推荐,少走一点弯路
    2. 没有推荐的话,就去网上搜索,找几个满足需求的备选。
    3. 对比以下几个指标:
    - 代码质量、有无测试
    - 文档健全度
    - 看Issue处理情况、最后更新时间(无人维护的项目后续恐怕有问题都没法解决)
    - 看Star数量,通过Google和StackOverflow看使用情况
    4. 自己按照说明试试看

    2019-04-18
    4
  • 陈珙
    在没有特殊要求的情况下,项目中更加倾向选择更为熟悉的技术,因为我们需要对项目的质量与交付时间负责,可以做到可控的。而新技术有着新的设计思想与强大的功能,同时也伴随着无法预知的”坑”。在后续产品迭代的时间里,有针对性的升级或者选择更换同类技术里更优的。

    作者回复: 是的,正式项目应该尽可能选择熟悉的、成熟的技术👍

    2019-04-18
    3
  • 邢爱明
    项目团队的开发人员,基本都是从外包公司临时找的,水平参差不齐,稳定性差,因此技术选型更多的考虑技术的普及度和容易学习掌握,从这方面看基本不太可能选择比较小众、但在特定领域很高效的技术。
    加上是企业内部管理的系统,数据量和用户数量可控,因此存在技术瓶颈的可能性很小,综合下来看就最好的选择就是最成熟和通用的技术,比如说选择java技术栈,web开发的ssm框架等,但这样长远看团队和个人的技术能力很难提升,请问老师在这方面有什么建议?

    作者回复: 我觉得团队的技术提升和项目的技术选型要分开,不要总想着两个都兼顾,优先保证好项目稳定、低成本运行。

    技术提升这种事,需要让一部分人先成长起来,然后带动其他人。

    我自己工作之外会做一些业余项目,然后在这些项目中体验新的技术,体会其中优缺点,然后再逐步应用到工作的项目中,在传授给同事们。

    我也鼓励其他同事这么做,去做一点自己的项目。但工作中的项目,我是很保守的。

    2019-04-20
    2
  • Charles
    三四线城市,技术选型前期主要考虑:

    当地市场什么人才比较充足,比如后端PHP人多,那就PHP,学习成本也低,几人团队协作起来也不是大问题,而且前期扩充人员也比较好招人,另外前期应该也不会在语言层面出现性能问题

    然后数据库基本就mysql,够熟悉够成熟

    前端的话web、小程序、ios、android之类的都统一mvvm思想进行前后端分离开发,这样各个用户端都可以统一API提升效率,这个也会从产品角度思考,如果产品就需要一个pc站,而且短期也没计划就选择传统的后端渲染web页面方案

    可能会站在目前项目或经历过的项目经验去思考问题,期待老师回复指正

    作者回复: 我觉得你的选型思路在项目发展阶段,包括没有很大规模之前都是没有问题的。选最熟悉的、流行的往往也是风险比较低的。包括如果就一个PC站也不做SPA(单页应用),也没有必要前后端分离。还是看是不是能低成本满足好项目需求和业务发展。

    有一点补充的,就是前端除了MVVM,像React的Flux和Redux的架构模式,也是一种很好的架构模式,但在非Rect/Vue的项目中应用不多。

    2019-04-18
    2
  • alva_xu
    技术选型,确实就是项目决策。考虑的角度应该可以参考“09可行性研究"中的技术可行性部分。就是从人员、技术、风险三个角度来考虑。技术有大有小,比如传统框架和微服务框架的选择,就是一个大选择。需要选型的技术在项目和产品中的重要性决定了选型时的风险偏好。团队对技术的熟悉程度,或者学习曲线,也是需要考虑的。另外,我觉得还可以用“天时、地利、人和”这三个角度来进行技术选型。
    老师文章中主要讲了技术选型的流程,我想请教老师的是,有没有什么大的原则可以指导技术选型?比如技术成熟度等?

    作者回复: 我认为在满足设计目标的前提下,大的原则还是在于项目约束,尤其是成本和时间,然后就是技术可行性和风险是不是可控,其他看团队风格,有的偏保守有的追新。

    比如说我自己的原则:
    1. 成熟的好过新酷的
    2. 流行的好过小众的
    3. 团队熟悉的好过陌生的
    4. 简单的好过复杂的
    5. 开源的好过商业的(有时候也视情况而定)

    仅供参考

    2019-04-18
    2
  • dancer
    首先确认当前技术选型要达成的主要目标,个人感觉可以分为提升开发效率、解决性能瓶颈、提升部署和运维效率、解耦强依赖的结构关系等。但是真的做选型时,往往还是会青睐自己喜欢和熟悉的技术,真的有点当局者迷的味道

    作者回复: “做选型时,往往还是会青睐自己喜欢和熟悉的技术”

    完全能理解,所以需要配合一些流程规范来尽可能避免,这就是为什么需要有技术评审这样的环节,要调研要试点。

    2019-04-18
    2
  • sotey
    我们是调研还没做完就直接决策了

    作者回复: 建议以后可以更慎重一点,这样可以避免因为决策不慎重导致的返工、技术债务等。

    2019-04-18
    2
  • Aaron Cheung
    楼上说的 深以为然

    作者回复: 已回复楼上:)

    2019-04-18
    2
  • 大王叫我来巡山
    我每次听到什么我们的数据量很大了,mysql和oracle 等关系型数据库已经支撑不了了,所以我们要用Hadoop,就想发飙,不过是穷而已,有钱我还是很愿意用oracle的,mpp对离线分析一样能做的很好,技术选型很大的原因就是要经济适用

    作者回复: 👍
    技术选型要考虑经济极成本和时间成本

    2019-08-02
    1
  • 刘晓林
    个人感悟:先明确自己的需求,对业务做领域建模,然后参考对应领域中主流的解决方案,这样即能控制尝新带来的风险,又不至于技术上掉队,导致代码一写出来就过时了。然后还要考虑时间、成本、范围的约束。

    作者回复: 👍谢谢总结分享

    2019-04-21
    1
  • 小先生
    目标,调研,验证,决策。

    要和利益相关人一起讨论,不要先入为主。

    可以引入金三角理论来分析调研。

    时间,成本,范围。

    作者回复: 👍赞总结

    2019-04-19
    1
  • Felix
    现学现卖:走快的唯一方法是先走好

    作者回复: 👍欲速则不达

    2019-04-20
  • 小先生
    定目标,
    2019-04-19
收起评论
17
返回
顶部