做前端开发时间久了,都会有一个基本的困惑,就是有那么多的新技术新框架,到底该如何取舍。每每一个框架还没玩熟,另一个新的又取代了它,总是感到有心无力。
前端圈子还有个我认为不是很好的趋势,就是技术跟风太严重,一个东西火了,大家全都要玩,甚至招聘信息上也要立马体现,新人想找工作,想不学都不行。
然而,我个人对于新技术,除了偶尔玩一玩扩展下知识面外,大部分时候还是持保守态度的。一方面因为我确实懒,另一方面是因为我是个偏实用主义的人。
前日在书中看到英国制定宪法遵循的五大原则,我觉得特别符合我对于新技术的态度:
1,影响来自必要性,而不是来自思辨式的推理; 2,不考虑是否严谨对称,更多的考虑是否方便实用; 3,不单纯以不一致为理由去消除不一致,除非有明显的缺憾,否则绝对不变革; 4,除非能够消除这些缺憾,否则绝不进行革新; 5,除了针对具体情况必须提供的条款之外,绝对不制定任何范围更大的条款。 单看中文翻译可能有些拗口,下面我说说从技术角度的理解。
影响来自必要性,而不是来自思辨式的推理
这个很简单,对于一个新的技术架构,一定是基于业务上的必要性,而不是拍脑袋或赶时髦。在业务规模尚小或要求没有那么高的时候,不要总想着过度优化。
不考虑是否严谨对称,更多的考虑是否方便实用
严谨对称,可以理解为各种看上去理所当然的一致性,比如前后台都用 nodejs 这种架构,要考虑许多因素,包括业务迁移难度,开发流程是否方便,新人上手是否容易,问题是否容易定位,服务器稳定性等等。而不能为了统一而统一。
不单纯以不一致为理由去消除不一致,除非有明显的缺憾,否则绝对不变革
仍然是 nodejs 的例子,如果不是在高并发高 IO 上有明显的缺憾,那就没必要为了前端人员的方便,而使用 nodejs 作为后端语言。既然都走上了开发的路子,多学个 PHP 也没什么坏处,何况还是世界上最好的语言。
除非能够消除这些缺憾,否则绝不进行革新
如果一项技术变革或架构改变,并不能明显解决某个痛点,那么就没必要去折腾,比如各种 MVVM 框架,虽各有所长,但并无太大优势差异。
除了针对具体情况必须提供的条款之外,绝对不制定任何范围更大的条款
这一条我理解为,对于开发人员要有适当的宽松氛围,在流程和编码上,除了一些必要的规范和文档外,不要制定太多的条条框框。软件开发也是创造性工作,需要一定的发挥空间,在一切都工程化模块化的时代,其实个人就变成了一部机器操作员了,一定会限制大脑发育的,到头来被计算机程序控制地球。
综上,技术选型应该更倾向于实用主义,与个人的钻研和折腾精神是背道而驰的,对于新技术的选择,小项目可以尽情尝试,作为大型基础架构部分,再保守也不为过。
至于实际操作中到底该如何取舍,我的观点是,业务永远第一位,放下任何程序员屌丝的面子与脾气,一切为了业务服务,具体操作参见上文的五大原则。