半夜写的文章胡思乱想比较多, 紧身阅读
我经常在网上鼓吹新技术, 特别是浏览器相关的技术, 感觉已经被打上标签了.
我理解这个问题是一直以来浏览器的功能都是落后需求的,
那么, 大部分新的改进实际上都是解放生产力的, 无论是性能合适新功能,
特别是 CoffeeScript, Flexbox, React, 都是对效率的巨大提升.
当然我的心态某种程度上也延伸到了更多的技术上, 比如 ClojureScript, Elixir,
应该说并不是所有新技术都值得关注, 我也不止一次被提醒, 不要追太前面.
但是我想首先我盟不能无视国内的大环境, 就是整体技术落后国外,
为了更多人能在编程行业赚钱并且得到培养, 就需要足够稳定健壮的互联网创业环境,
在这个追赶的过程当中, 必然是国外一旦有领先技术, 国内就值得注意的.
特别是经过时间检验能够获益的技术. 我们有必要利用后发优势.
同时问题也就来了, 时间没检验成功的技术怎么办? 投入不投入?
这就特别是一些开源项目, 或者试验性的技术, 大家都抱着观望的态度.
当然, 从最终的结果来看, 我们希望投入有足够的产出的, 很简单的一个原则.
问题在于, 在风险不确定的时候如何决断? 如果打算冒险, 如何投入?
至少总是要有人足够深入地去了解技术, 以便能获取到足够的信息,
对于 Web 服务器来说, 似乎很明确, 线上的性能怎样, 运行的稳定性怎样?
其次还有人员的储备和培养的问题, 以及整体生态来说各种细节.
具体到公司具体到业务也许当事人不会头太多的选择吧, 不难决定,
我怀疑也就是前端这个奇葩的领域, 同个领域技术能重叠到大家相互能吵架的程度.
王煜全对于技术的看法带了了我不少感想. 特别是科技的研究和科技的应用的区分.
科技在实验室被发明, 跟科技大规模量产从而服务用户, 两个有巨大差别,
实验室技术并不是很好的投资对象, 接近量产和应用的才是安全可靠的目标.
似乎由于涉及到测试和各种认证, 接近量产的科技总是会有一些时间表的,
就像自动驾驶分成几个等级, 几几年大致能到怎样的程度, 多少都能判断出来.
另一方面, 没有科技含量的技术随时有着的在竞争中被轻松赶超的威胁.
我不确定细节, 至少推演起来是挺清晰的一个问题, 技术专利和产品研发的关系.
作为对比, 编程领域的各种技术并没有清晰的界线, 而且变化的范围比较大,
一个前端开发好的类库, 可能随时就会用到生产环境当中, 或者很快被替换,
另一方面, 类库功能支持似乎很难评估, 除非维护者提供明确的时间表,
React 什么时候哪些功能会完工, Weex 什么时候会有什么功能, 公司外面知道吗?
而且对于前端来说, 上层的应用代码, 底层的 js 引擎优化, 一直在发生变化,
至于说性能究竟可以优化到怎样, 开发效率可以提升多少, 很难准确评估出来.
这样那样的原因, 比如 Elm 是否靠谱, cljs 是否靠谱, 大家只能根据自己的经验,
React 和 Vue 开发的应用效果究竟怎样, 开发人员的时间消耗怎样, 很难说,
而且开发效率的问题, 由于大家有着各自不一样的编码习惯, 其实也挺难准确评估的.
用什么样的编辑器, 开发当时的心态, 业务安排的时间, 都是比较大的变量,
而且即便能统一, 代码当中出现的 bug 呢? 基础架构当中出现的故障呢? 难以预估时间.
整个事情被我说得就跟编程还处在手工业阶段一样, 难以标准化, 难以大规模协作.
问题在哪? 整个行业的基础工具链不够成熟么? 人员培训的素质不够么? 好吧我也不知道.
回到 CSS Grid Layout 的事情上. 好像早在 2011 年 Grid Layout 就在提了,
栅格系统很早就是平面设计师的工具, 然而在网页上并没有好的表格系统,
当然, 基于 CSS 实现的网格局部逐渐也有成熟, 但我了解不够, 难以展开叙述,
后来还有 Flexbox 解决了布局当中很多问题, 但是从 Grid Layout 回头看, 那是不够的.
从前不容易实现的界面对齐和元素间隔, 借助 Grid Layout 有了比较简单的方案,
我相信这能够压缩不少繁复的工作. 话说回来, 怎样评估对于效率具体有多少提升呢?
同时由于旧某些浏览器技术换代的问题, 兼容或者等待更新的成本又有多少?
再说到 ClojureScript 这边的事情, 好像身边很多人对这个语言态度暧昧,
回头对照, 确实有一些问题, 官方对于功能和性能没有承诺的时间表,
同时, 由于语言性能过于强大, 高手可能写出效果数倍于新手的代码, 导致难以评估时间,
同时这也带来了人员培养的麻烦, 特别是很难花短时间培养新手程序员进入业务.
可以说, 从 Flexbox 到 Grid Layout, 投入一些成本, 会有明确的产出,
但是把 js 替换成 cljs, 产出倒是还有, 可是成本就难以评估, 而且肯定成很大的.
就像的实验室烧钱还是要有人冒风险去研究一样, 我是还得投入 cljs, 但是风险也真是.
绕回到前端框架的争议话题上, 各种方案投入产出, 时间成本和产品的可靠性如何?
有点好玩, 因为投入的明显是人力和脑力嘛, 而且两个因素有着巨大的不稳定性,
有些框架照顾 js 程序员多, 有些照顾 Java 程序员多, 有些还照顾模板引擎用户,
这样对于不同的人群而言都有着不小的差异, 成本的估算和人员的能力关联很大了.
然后产品质量, 可变数据不可变数据在易用性和可靠性方面讨论挺多了, 有点跑题,
说得不清楚, 产品质量好非常多因素相关, 架构设计只是基础的一部分, 开发方案因素也不小.
不过结果还是要回到差异性太大, 成本难以估算, 产出也难以估算的问题.
前面扯多了, 想到人员培养的问题其实特别明显. 特别是前端技术种类混杂如此严重.
而且对于前端来说很多学习依赖业余时间自觉完成, 这个就有了非常大的不确定性.
当然, 枯燥的填鸭的培训是个更可怕的办法, 结果也许是从业人员都变得越来越少,
我猜想的一个可能还是, 尽量减少开放当中对人这个不确定因素的依赖,
比方说强类型, 比如说 Prettier, 还有模块化, 总之减少人在其中的不确定因素,
甚至日程的代码编写, 既然大家都是去 StackOverflow 上抄, 能不能做得更激进一点,
我的意思是把常用代码整理起来, 方便业务中用到时候抄上去. 总之让人类的工作更可预测.
扯了半天好像结论反而是学点 Kotlin 不要没事找事去学 Clojure...
找个时间再刷一篇关于 ClojureScript 前端开发优劣评估好而...