技术选型
观点:技术选型的4个参考原则
原则 1:能否简化开发任务?
这条原则显而易见,如果选择的技术无法帮助我们高效地达成目标,似乎没有理由去选择它。注意这里的关键词:简化。完成开发任务的手段并不是唯一的,在众多手段中间我们只关心哪个能够让我们生活得更容易。
同时,这里还要避免一个不那么显而易见的陷阱:虽然简化了手头的任务,但带来了其他方面的复杂性。比如,引入 Kafka 确实带来了一系列的好处:流量削峰、简化了任务分配和服务异步化等等,但由此也带来了一系列其他的复杂性,比如:运维的复杂性和事务的复杂性。那么,作为决策者就要评估是否需要这样一个复杂的方案,是否采用简单地方案就能完成目标,如:日志表 + 定时任务。
原则 2:是否符合组织内的主流技术路线?
大多数组织都会有一个主流的技术路线,技术团队如果采用的技术五花八门,会大大增加技术管理的成本。技术路线,是在进行技术选型时必须要面对的问题,尽可能地选择符合公司技术路线的技术或工具,这样有助于工作的快速推进。
原则 3:是否普及程度高或者学习曲线平缓?
普及程度高,有利于很快找到合适的人直接上手开干;学习曲线平缓则有利于在缺人时快速将现有人员切换到现有赛道。
原则 4:能否得到有效地支持?
这里的支持可以来自于两方面:外部和内部。能够方便地获得外部支持一方面说明了项目的普及程度,另一方面也反映了项目的活跃程度。前者的好处在上面已有说明,至于后者,则说明项目在与时俱进,对于新出现的使用场景大概率有较好的支持
观点:技术选型需要考虑技术维护成本
常见的技术维护成本有如下四个方面,依次是:
技术选型成本。
这是指你在做技术选型的时候,选择不成熟的技术所带来的成本。越成熟的技术,其技术实现成本和人力成本都是相对要低的,但是并不是说,选择新技术就一定不划算,只要考虑到成本和风险,才能做出合理决策。
技术升级成本。
这是指在评估技术方案的时候,其兼容性和扩展性水平带来的后期升级的难度和成本。
问题排查成本。
在做技术实现的时候,要特别关注后续的问题排查。好的技术实现,分分钟可以排查出问题原因;而不好的技术实现和方案,查一个问题可能需要花上几天时间,成本差异不可同日而语。
代码维护成本。
在编写代码的时候,要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白,修改起来是否简单、安全。
观点:技术选型的关键要素
- 任何脱离业务的选型,都是耍流氓
- 早期不建议自研
- 擅长什么用什么
- 技术栈建议收敛
- 不自研,浅浅封装
- 规模扩大,适当造些轮子