学不动新技术怎么办
我们做开发工作时间久了，都会有一个基本的困惑，那就是，那么多的新技术新框架，到底该如何取舍呢？每次一个框架还没玩熟练，另一个新的又取代了它，总是感到有心无力，真有点儿学不动了。
尤其是前端开发的圈子，还有一个我认为不是很好的趋势。那就是技术跟风太严重，一个东西火了，大家全都要玩，没有条件创造条件也要用上，甚至招聘信息上也要立马体现。新人想找到工作，想不学都不行。最后的结果就是，简历内容同质化严重，忽视基础知识积累，浮于框架应用的表面技术。
然而，我个人对于新技术，除了偶尔玩一玩扩展下知识面外，大部分时候还是持保守态度的。一方面是因为我确实懒，另一方面是因为我是个偏实用主义的人（还可能是披着实用主意外衣的懒）。有一天我看到了英国制定宪法遵循的五大原则，我觉得特别符合我对于新技术的态度，分享给你：
- 影响来自必要性，而不是来自思辨式的推理；
- 不考虑是否严谨对称，更多的考虑是否方便实用；
- 不单纯以不一致为理由去消除不一致，除非有明显的缺憾，否则绝对不变革；
- 除非能够消除这些缺憾，否则绝不进行革新；
- 除了针对具体情况必须提供的条款之外，绝对不制定任何范围更大的条款。
单看中文翻译可能有些拗口，下面我们看看从技术的角度，应该如何理解这五大原则。
影响来自必要性，而不是来自思辨式的推理
这个很简单，对于一个新的技术架构，一定是基于业务上的必要性，而不是拍脑袋或赶时髦。在业务规模尚小或要求没有那么高的时候，不要总想着过度优化。其实跟奥卡姆剃刀（Occam’s Razor）原理是一个意思：如无必要，勿增实体，即「简单有效」。
不考虑是否严谨对称，更多的考虑是否方便实用
严谨对称，可以理解为各种看上去理所当然的一致性，比如前后台都用 nodejs 这种架构，实际上要考虑许多因素，包括业务迁移的难度，开发流程是否方便，新人上手是否容易，问题是否容易定位，服务器稳定性，并发能力等等。而不能为了统一而统一。
不单纯以不一致为理由去消除不一致，除非有明显的缺憾，否则绝对不变革
仍然是 nodejs 的例子，如果不是在高并发高 IO 上有明显的缺憾，那就没必要为了前端人员的使用方便，而使用 nodejs 作为服务端语言。既然都走上了开发的路子，多学个 PHP 或者 Go 也没什么坏处，何况 PHP 还是世界上最好的语言呢（预计此处流失 80% 读者）。
除非能够消除这些缺憾，否则绝不进行革新
如果一项技术变革或架构改变，并不能明显解决某个痛点，那么就没必要去折腾，比如曾经的各种 MVVM 框架，虽各有所长，但并无太大优势差异。重点还是看团队的选择，团队技术栈要尽量统一才方便业务开展。
除了针对具体情况必须提供的条款之外，绝对不制定任何范围更大的条款
这一条我理解为，对于开发人员要有适当的宽松氛围，在流程和编码上，除了一些必要的规范和文档外，不要制定太多的条条框框。软件开发是创造性工作，需要一定的发挥空间。在一切都工程化模块化的时代，其实个人就变成了一部机器操作员了，一定会限制大脑发育的，到头来被计算机程序控制地球。
综上所述，技术选型应该更倾向于实用主义，与个人的钻研和折腾精神是背道而驰的。对于新技术的选择，小项目可以尽情尝试，作为大型基础架构部分，再保守也不为过。有些同学在日常开发过程中，可能会自己引入新技术，然而当项目交接或者离职的时候，其他人就很痛苦了。
最后，至于实际操作中到底该如何取舍，我的观点是：业务永远第一位，放下程序员的面子与脾气，一切为了业务服务。