關於投入產出和新技術的隨想

半夜寫的文章胡思亂想比較多, 緊身閱讀

我常常在網上鼓吹新技術, 特別是瀏覽器相關的技術, 感受已經被打上標籤了.
我理解這個問題是一直以來瀏覽器的功能都是落後需求的,
那麼, 大部分新的改進實際上都是解放生產力的, 不管是性能合適新功能,
特別是 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 前端開發優劣評估好而...