关于投入产出和新技术的随想

半夜写的文章胡思乱想比较多, 紧身阅读

我常常在网上鼓吹新技术, 特别是浏览器相关的技术, 感受已经被打上标签了.
我理解这个问题是一直以来浏览器的功能都是落后需求的,
那么, 大部分新的改进实际上都是解放生产力的, 不管是性能合适新功能,
特别是 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 前端开发优劣评估好而...