要不要引入新技术?先思考这几个问题

来源: OSCHINA
编辑: h4cd
2019-03-02

我们应该使用这种新技术,你看它多快、多好,又多么优雅,可以加快开发进度啊。

你看,我上周末实现了一个原型而且它还可以跑生产,这新技术就是这么牛 X。

……

说好的要让员工在公司里学习和成长呢?

……

呵呵,干里凉,辣鸡公司,我唔捞喇。

这样的对话熟不熟悉?作为开发,你有没有经历过想要在工作中引入新技术却阻力重重,而且很多时间就花在了这样的争论之中,最后还搞得心力交瘁。

前 Etsy CTO Kellan 发表了一篇文章,他认为技术团队中沟通成本太高,有时候总是需要花时间与精力去讨论一些难以达成统一观点的问题,比如上边这种典型的“是否要引入一项新技术”。

如何去避免呢?

Kellan 介绍了自己已经使用了十多年的“问题列表”,在想要引入一项新技术之前把该列表的问题都思考一下,而不是去无休止地讨论,甚至于辞职。

问题列表比较简短,思考过这些问题之后,也许就不用去争论了:

  • 我们到底是要解决什么问题? (永远不应该因为自己的目的而引入新技术)
  • 我们可以怎样用当前的技术栈解决这个问题?(如果答案是做不到,那么可能对这个问题没有进行深入思考;如果可以,那么思考下一个问题)
  • 我们当前的技术栈为什么不能以金钱、人员与时间等方面经济有效的方式去解决这个问题?
  • 我们是否明确了新技术会带来的新成本?(监控、员工培训、学习精力等)
  • 如果这项新技术可以替代目前的一些方案,那么我们能不能保证将来把相关的开发都迁移到这项新技术上?还是说我们针对这一个问题其实会有多种解决方案的尝试?(这个新技术路线会不会稳定下去?)
  • 有没有我们信任的人在使用该新技术?我们和他们谈过这个东西吗?他们是什么想法?新技术有什么是他们不喜欢的?(如果他们不讨厌它,那么他们还没有深入使用过)
  • 怎样低风险去尝试?
  • 有没有组织各个部门的高级别员工逐一回答上述各项,有没有文档记录?

你的想法呢?

展开阅读全文
69 收藏
分享
加载中
精彩评论
目标技术栈的生态丰富度应该是最最重要的,其次是社区活跃度
2019-03-02 08:12
7
举报
做什么事之前,多多思考,是没有坏处的,思考的越深,后期踩的坑就越少
2019-03-02 12:18
2
举报
我觉得这样挺好,不过通常我让持不同意见的小伙伴列一下优缺点,然后我下定论说服不采纳的一方
2019-03-02 15:22
1
举报
第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
2019-03-02 12:46
1
举报
最新评论 (11)

引用来自“笨笨D幸福”的评论

第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
哈哈,这个java7更新java8就没那么多事。。。虽然这变革已经算很大了。
2019-03-02 21:54
0
回复
举报
跟风赶时髦=面向简历开发
2019-03-02 21:34
0
回复
举报
新技术坑多,最近公司压测发现spring cache有bug,在高并发情况下暴露出来,不是新的技术就适用
2019-03-02 21:02
0
回复
举报
新技术一般会节约开发时间
2019-03-02 17:47
0
回复
举报
我觉得这样挺好,不过通常我让持不同意见的小伙伴列一下优缺点,然后我下定论说服不采纳的一方
2019-03-02 15:22
1
回复
举报

引用来自“笨笨D幸福”的评论

第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
还有,更新技术导致的人力时间成本,大部分领导都不愿意出
2019-03-02 12:49
0
回复
举报
第二个问题是个坑,大部分情况都是一切都OK,但是新旧业务交叉,复杂度太高,领导要求“无损”重构和迁移(<=这点是不可能的)
2019-03-02 12:46
1
回复
举报
做什么事之前,多多思考,是没有坏处的,思考的越深,后期踩的坑就越少
2019-03-02 12:18
2
回复
举报
说的很好
2019-03-02 12:17
0
回复
举报

引用来自“MrXionGe”的评论

目标技术栈的生态丰富度应该是最最重要的,其次是社区活跃度
赞成!还有一点就是持续性!
2019-03-02 08:55
0
回复
举报
更多评论
11 评论
69 收藏
分享
返回顶部
顶部