观点：技术选型的4个参考原则
极客时间编辑部
讲述：杜力大小：2.06M时长：04:30
技术选型是技术领导日常工作的一部分，但就不同阶段的公司而言，技术选型的标准并非一成不变的。针对公司不同阶段关注的重点，TGO 会员、创业公司 CTO 胡键谈及了相应的标准和原则，同时结合自身给出了相应的实例。以下为具体内容。
选择并不像看上去那么美好，没有选择和选择太多都会让人痛苦，尤其是在当今技术大爆炸和开源项目满天飞的今天，“选择麻痹”应该是最让技术决策者头痛的毛病。要缓解它，就必须建立起我们自己的技术选型标准，或者说原则。
在经历了这些年多次“艰难的抉择”之后，我总结出了适合我个人的技术选型原则。
原则 1：能否简化开发任务？
这条原则显而易见，如果选择的技术无法帮助我们高效地达成目标，似乎没有理由去选择它。注意这里的关键词：简化。完成开发任务的手段并不是唯一的，在众多手段中间我们只关心哪个能够让我们生活得更容易。
同时，这里还要避免一个不那么显而易见的陷阱：虽然简化了手头的任务，但带来了其他方面的复杂性。比如，引入 Kafka 确实带来了一系列的好处：流量削峰、简化了任务分配和服务异步化等等，但由此也带来了一系列其他的复杂性，比如：运维的复杂性和事务的复杂性。那么，作为决策者就要评估是否需要这样一个复杂的方案，是否采用简单地方案就能完成目标，如：日志表 + 定时任务。
原则 2：是否符合组织内的主流技术路线？
大多数组织都会有一个主流的技术路线，技术团队如果采用的技术五花八门，会大大增加技术管理的成本。技术路线，是在进行技术选型时必须要面对的问题，尽可能地选择符合公司技术路线的技术或工具，这样有助于工作的快速推进。
当然，凡事无绝对，当可见的好处远大于学习新技术的成本和风险时，在可控范围内冒险一试未尝不可。但需要提醒的是，除非是极端情况，这种情形其实并不多见。因为当前丰富的开源工具已经提供了充分的选择，在大多数情况下能够让人找到既满足自己要求同时又符合组织技术路线的工具。这里我假设贵公司的技术路线并不是那种剑走偏锋类型。
原则 3：是否普及程度高或者学习曲线平缓？
普及程度高，有利于很快找到合适的人直接上手开干；学习曲线平缓则有利于在缺人时快速将现有人员切换到现有赛道。一般来讲，普及程度高的技术或工具，大都没有陡峭的学习曲线。反过来就不一定了，比如我公司一直使用的 Grails，在国内的普及程度就远低于所谓的 SSH 或 SSM。但其学习曲线一点都不高，而且开发效率数倍于前者。
这条原则直接着眼于技术选型对于人员管理的影响，满足这两点的技术或工具都将大大降低人员管理的成本，对于招聘和人员流动都有积极的影响。
原则 4：能否得到有效地支持？
这里的支持可以来自于两方面：外部和内部。能够方便地获得外部支持一方面说明了项目的普及程度，另一方面也反映了项目的活跃程度。前者的好处在上面已有说明，至于后者，则说明项目在与时俱进，对于新出现的使用场景大概率有较好的支持。
即使有很好的外部支持，也不意味着就应该放弃内部支持能力的建立。原因很简单，随着使用的深入和业务的发展，迟早会遇到自己公司特有的需求，而这个需求还没有广泛到从外部就可以直接获得很好地支持。此时，只能借助自己的力量把坑填平，这样才不至于以往的技术投资打水漂。
说到底，技术要为业务服务，技术选型不能是技术人的自嗨，更不能是“面向简历”的决策结果。只有把握了这个最终原则，我们才能真正客观的看待当前的技术问题，相对客观的履行作为公司技术带头大哥的职责。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
加菲猫简化开发任务，符合组织内主要技术路线，学习曲线平缓，能够得到支持是技术选型的基本原则，是架构师或技术Leader必备的能力，每一种技术或框架的出现都是为了解决复杂问题，这种技术能被长时间使用，基本都具备这样的特点
Panda选择最适合自己团队的 适合自己业务场景的技术栈 才是最好的
收起评论