我們是否應當剋制對新技術的追求？
版權宣告: 本部落格所有內容除特殊說明外,均系原創，允許轉載，但需註明來源。
毋庸諱言，程式開發是一個快速發展的行業，尤其是最近幾年，從Web/移動到雲、容器、DevOps、大資料、大前端、VR、區塊鏈、人工智慧，我們似乎有永遠學不完的新技術；同樣明顯的是，程式設計師這個開發群體也極其熱衷於追求各種更新、更酷、更強大、更優雅的技術。很難全面地評價這究竟是好事還是壞事，似乎我們已經把這當成一種不言自明的事實。
但最近，我聽到了一些特別的聲音，雖然它們來自不同技術背景的開發者，立場和觀點也不盡相同；但這些內容似乎指向同一個結論，即：一些被認為是“老舊”的技術實際上是被低估了；而另外一些為眾多開發者所追捧的新技術，它們未必真正達到如預期的那種生產力提升，並且，使用“老舊”的技術實際上可以達到同樣的效果。無論如何，這些確實來自真正的一線開發者的實際經驗總結。我希望你能夠聽一聽他們的聲音。
在我的職業生涯中，沒有一種技能比 SQL 更有用！
作者是一個以 Postgresql 為主要產品的雲服務提供商負責人。他的核心觀點如下：
在我的職業生涯中，我學到了很多技能，但沒有一種技能比 SQL 更有用。SQL 在我看來是最有價值的技能，
- 它對於不同的職業角色和學科來說都是有價值的；
- 一旦學會了就不需要重新再學；
- 它讓你看起來像個超級英雄。一旦你掌握了它，而其他人不懂，你就顯得特別強大。
我的意見：部分同意作者的說法。在這些年中，我觀察到的一個有趣的趨勢是：各種 NoSQL 技術開始時都標榜自己和傳統 RDBMS 的不同，但隨著產品的發展，他們最終還是發現自己需要 SQL （或類似的東西）。不過，我認為 SQL 也有自己的問題，那就是作為數十年前釋出的技術，它沒有包含關於如何分散式執行的內容，而這是從 Google 的早期論文到現在的各種資料平臺一直在致力解決的。此外，目前似乎有一種令人討厭的趨勢，即隨便哪個公司都聲稱自己在應用大資料。我相信很多小公司的資料問題是可以在 SQL 的層面得到解決的。
關於作者的觀點，有一個有趣的佐證，那就是 TIOBE 的程式語言趨勢報告。
從圖中我們可以看到，在排名前 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：一場令人追悔莫及的豪賭》一文對舊技術的評價，因為這段文字深得我心：
無聊的好處（限制水平較高）在於，這些東西的功能相對更容易理解。而更重要的是，我們能夠更輕鬆地瞭解其故障模式。……但對於閃閃發光的新技術而言，其中的未知因素要多得多，這一點非常重要。
換句話來說，已經存在了十年的軟體更易於理解，而且未知因素更少。未知因素越少，運營開銷越低，這絕不是壞事。