前端开发该如何看待新技术

做前端开发时间久了，都会有一个基本的困惑，就是有那么多的新技术新框架，到底该如何取舍。每每一个框架还没玩熟，另一个新的又取代了它，总是感到有心无力。

前端圈子还有个我认为不是很好的趋势，就是技术跟风太严重，一个东西火了，大家全都要玩，甚至招聘信息上也要立马体现，新人想找工作，想不学都不行。

然而，我个人对于新技术，除了偶尔玩一玩扩展下知识面外，大部分时候还是持保守态度的。一方面因为我确实懒，另一方面是因为我是个偏实用主义的人。

前日在书中看到英国制定宪法遵循的五大原则，我觉得特别符合我对于新技术的态度：

1，影响来自必要性，而不是来自思辨式的推理； 2，不考虑是否严谨对称，更多的考虑是否方便实用； 3，不单纯以不一致为理由去消除不一致，除非有明显的缺憾，否则绝对不变革； 4，除非能够消除这些缺憾，否则绝不进行革新； 5，除了针对具体情况必须提供的条款之外，绝对不制定任何范围更大的条款。 单看中文翻译可能有些拗口，下面我说说从技术角度的理解。

影响来自必要性，而不是来自思辨式的推理

这个很简单，对于一个新的技术架构，一定是基于业务上的必要性，而不是拍脑袋或赶时髦。在业务规模尚小或要求没有那么高的时候，不要总想着过度优化。

不考虑是否严谨对称，更多的考虑是否方便实用

严谨对称，可以理解为各种看上去理所当然的一致性，比如前后台都用 nodejs 这种架构，要考虑许多因素，包括业务迁移难度，开发流程是否方便，新人上手是否容易，问题是否容易定位，服务器稳定性等等。而不能为了统一而统一。

不单纯以不一致为理由去消除不一致，除非有明显的缺憾，否则绝对不变革

仍然是 nodejs 的例子，如果不是在高并发高 IO 上有明显的缺憾，那就没必要为了前端人员的方便，而使用 nodejs 作为后端语言。既然都走上了开发的路子，多学个 PHP 也没什么坏处，何况还是世界上最好的语言。

除非能够消除这些缺憾，否则绝不进行革新

如果一项技术变革或架构改变，并不能明显解决某个痛点，那么就没必要去折腾，比如各种 MVVM 框架，虽各有所长，但并无太大优势差异。

除了针对具体情况必须提供的条款之外，绝对不制定任何范围更大的条款

这一条我理解为，对于开发人员要有适当的宽松氛围，在流程和编码上，除了一些必要的规范和文档外，不要制定太多的条条框框。软件开发也是创造性工作，需要一定的发挥空间，在一切都工程化模块化的时代，其实个人就变成了一部机器操作员了，一定会限制大脑发育的，到头来被计算机程序控制地球。

综上，技术选型应该更倾向于实用主义，与个人的钻研和折腾精神是背道而驰的，对于新技术的选择，小项目可以尽情尝试，作为大型基础架构部分，再保守也不为过。

至于实际操作中到底该如何取舍，我的观点是，业务永远第一位，放下任何程序员屌丝的面子与脾气，一切为了业务服务，具体操作参见上文的五大原则。