我們是否應當剋制對新技術的追求?

流光飛舞發表於2019-02-25

  毋庸諱言,程式開發是一個快速發展的行業,尤其是最近幾年,從Web/移動到雲、容器、DevOps、大資料、大前端、VR、區塊鏈、人工智慧,我們似乎有永遠學不完的新技術;同樣明顯的是,程式設計師這個開發群體也極其熱衷於追求各種更新、更酷、更強大、更優雅的技術。很難全面地評價這究竟是好事還是壞事,似乎我們已經把這當成一種不言自明的事實。

  但最近,我聽到了一些特別的聲音,雖然它們來自不同技術背景的開發者,立場和觀點也不盡相同;但這些內容似乎指向同一個結論,即:一些被認為是“老舊”的技術實際上是被低估了;而另外一些為眾多開發者所追捧的新技術,它們未必真正達到如預期的那種生產力提升,並且,使用“老舊”的技術實際上可以達到同樣的效果。無論如何,這些確實來自真正的一線開發者的實際經驗總結。我希望你能夠聽一聽他們的聲音。

 在我的職業生涯中,沒有一種技能比 SQL 更有用!

  作者是一個以 Postgresql 為主要產品的雲服務提供商負責人。他的核心觀點如下:

在我的職業生涯中,我學到了很多技能,但沒有一種技能比 SQL 更有用。SQL 在我看來是最有價值的技能,

  1. 它對於不同的職業角色和學科來說都是有價值的;
  2. 一旦學會了就不需要重新再學;
  3. 它讓你看起來像個超級英雄。一旦你掌握了它,而其他人不懂,你就顯得特別強大。

  我的意見:部分同意作者的說法。在這些年中,我觀察到的一個有趣的趨勢是:各種 NoSQL 技術開始時都標榜自己和傳統 RDBMS 的不同,但隨著產品的發展,他們最終還是發現自己需要 SQL (或類似的東西)。不過,我認為 SQL 也有自己的問題,那就是作為數十年前釋出的技術,它沒有包含關於如何分散式執行的內容,而這是從 Google 的早期論文到現在的各種資料平臺一直在致力解決的。此外,目前似乎有一種令人討厭的趨勢,即隨便哪個公司都聲稱自己在應用大資料。我相信很多小公司的資料問題是可以在 SQL 的層面得到解決的。

  關於作者的觀點,有一個有趣的佐證,那就是 TIOBE 的程式語言趨勢報告。

TIOBE Programming Index

  從圖中我們可以看到,在排名前 20 的語言各自都有不同程度的起起落落,唯有 SQL 從 2004年以後就保持了驚人的穩定,幾乎沒有任何浮動。為什麼 SQL 能保持如此穩定的分數,TIOBE 並沒有太多公開的細節可供參考,但這確實在一定程度上證明了作者的結論。從長期來看,SQL 或許應當被看作一個回報率不算突出、但非常穩定和值得信賴的投資。在投身學習紛繁複雜的各種資料技術之前,或許你應該首先了解一下這個已經存在了 50 年之久的名字:SQL。

 為什麼說 TypeScript 不適合大型專案?

  儘管起了這樣一個題目,但通讀全文後你會發現,作者本人其實是很喜歡 TypeScript 的,並且在生產環境中大規模應用了 TypeScript。作者對專案結果進行了評估,最終得出結論:

我對 TypeScript 的好處、成本和不足都有了更深入的瞭解。我想說的是,它並不像我所希望的那麼成功。除非它有很大改進,否則我不會在另一個大型專案中使用 TypeScript。

  換句話說,TypeScript 並非沒有價值,只是沒有之前預期那麼高的價值,加上引入 TypeScript 所帶來的成本,使得作者認為在 TypeScript 上面的投資不太值得。

  我的觀點:個人比較感興趣的是作者對專案進行評估的方法。從文中來看,作者通過開發工具、API 文件、重構、培訓、招聘等方面對引入 TypeScript 的效果進行了評分。這個方法應該說是有一定參考意義的,同時,對於各個指標的分析作者也進行了詳細的說明,值得一看。作者還提到了一個很有價值的觀點(也可能是有爭議的):TypeScript 所推重的型別安全對減少 bug 實際上沒有想象的那麼大,而比較傳統的技術,包括單元測試和 Code View,能更全面地覆蓋問題。型別安全似乎也沒有多大差別。再次引用原文:

TypeScript 的支持者經常談論型別安全的好處,但很少有證據表明型別安全會對 bug 密度產生重大影響。這個很重要,因為程式碼評審和 TDD 會帶來很大的差異(僅在 TDD 方面就有 40% 到 80% 的差異)。將 TDD 與設計評審、規範評審和程式碼評審結合起來,可以看到 bug 密度降低了 90% 以上。其中的一些流程(尤其是 TDD)除了能夠捕獲到 TypeScript 可以捕獲的 bug 之外,還能捕獲到很多 TypeScript 無法捕獲的 bug。

  我猜測作者的結論可能會讓很多 TypeScript 的擁護者有點受傷。不過我個人明確地對作者的這一觀點表示贊同,即:比起各種新技術帶來的改進,單元測試和程式碼複審理應在開發工程中發揮更大的作用。

 Docker:一場令人追悔莫及的豪賭

  本文的主要觀點是,把所有賭注壓在 Docker 上面是危險而不合理的。作者所推崇的是另一條道路:將程式部署為所謂的大型二進位制檔案或 uberjar(最適合這種模式的語言包括 Java、Golang 和 Clojure 等),從而在最大程度上避免依賴造成的問題。在這種場景下,不用 Docker 而使用傳統的運維技術,包括 Chef、Puppet 和 Ansible, 同樣能有序地管理伺服器,而且避免了 Docker 帶來的問題。同時,作者認為 K8S 帶來的編排仍然是有積極意義的,但作者也提出了這樣的疑問,即編排一定要基於容器嗎?換句話說,一定要基於 Docker 嗎?

  原文很長,涉及的內容也相當多,可能需要反覆閱讀才能理解(我自己是讀到第三遍才比較有把握說讀懂了原文)。另外,該文是對作者前一篇文章《Why would anyone choose Docker over fat binaries?》的集中回應,因此先閱讀上一篇文章有助於更好的理解文章的背景。

  說實話,在讀到本文之前,雖然我也知道 Docker 存在一些缺陷,但並未從系統角度去理解這些缺陷意味著什麼。而本文很好的開闊了我的視角,在這個意義上,即便我並不同意作者的一些最終觀點,但我仍然認為作者看待問題的角度是值得了解的。

  作者提出的以下意見可以視為忠告:

最好將Docker視為一種高階優化方案。沒錯,它很酷且功能相當強大,但其同時也會增加系統複雜性,且只有專業的系統管理員才能夠理解如何在生產中安全使用Docker並將其部署在關鍵性任務系統之內。

就目前來看,您需要掌握更多系統專業知識才能使用Docker。事實上,幾乎所有Docker相關文章都只展示過分簡單的用例,而忽略了在多主機生產系統上使用Docker所帶來的複雜性挑戰。這無疑給人們留下了Docker的實際生產應用非常簡單易行這一極為錯誤的印象。

在計算機程式設計領域,流傳著這樣一句至理名言:“不成熟的優化是萬惡之源”。然而,今年以來我們的大部分客戶都堅持“我們必須從起步階段就全部實現Docker化。”因此不同於傳統最初最佳實踐要求的建立一套工作系統、將其投入生產、最後考量Docker能否帶來比較優勢的作法,客戶們開始盲目推動Docker的標準化開發與部署。

  此外,本文還引用了另一位開發者的文章,該開發者由於在生產環境中引用 Docker 遇到了許多重大問題, 因而對 Docker 的批評更加激烈,以至於建議不要在任何嚴肅的場合部署 Docker。雖然觀點可能有過激的嫌疑,但畢竟也是來源於一線的生產實踐,並且提到了 Docker 檔案系統和介面演變的一些內幕,還是頗為值得一看的。

  Docker in Production: A History of Failure

 寫在後面

  新技術肯定有新的價值,這一點毫無疑問,我也無意否定開發者求新求變的理想和追求。但在追逐新技術的同時,請不要忘了我們的“老”技術,不管你用或不用,它們就在那裡。

  最後,我還是想引用 《Docker:一場令人追悔莫及的豪賭》一文對舊技術的評價,因為這段文字深得我心:

無聊的好處(限制水平較高)在於,這些東西的功能相對更容易理解。而更重要的是,我們能夠更輕鬆地瞭解其故障模式。……但對於閃閃發光的新技術而言,其中的未知因素要多得多,這一點非常重要。

換句話來說,已經存在了十年的軟體更易於理解,而且未知因素更少。未知因素越少,運營開銷越低,這絕不是壞事。

相關文章