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

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

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

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

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

它對于不同的職業角色和學科來說都是有價值的；

一旦學會了就不需要重新再學；

它讓你看起來像個超級英雄。一旦你掌握了它，而其他人不懂，你就顯得特別強大。

我的意見：部分同意作者的說法。在這些年中，我觀察到的一個有趣的趨勢是：各種 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：一場令人追悔莫及的豪賭》一文對舊技術的評價，因為這段文字深得我心：

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

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

總結

以上是生活随笔為你收集整理的反思~我们是否应当克制对新技术的追求？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。