毋庸諱言，程式開發是乙個快速發展的行業，尤其是最近幾年，從web/移動到雲、容器、devops、大資料、大前端、vr、區塊鏈、人工智慧，我們似乎有永遠學不完的新技術；同樣明顯的是，程式設計師這個開發群體也極其熱衷於追求各種更新、更酷、更強大、更優雅的技術。很難全面地評價這究竟是好事還是壞事，似乎我們已經把這當成一種不言自明的事實。
但最近，我聽到了一些特別的聲音，雖然它們來自不同技術背景的開發者，立場和觀點也不盡相同；但這些內容似乎指向同乙個結論，即：一些被認為是「老舊」的技術實際上是被低估了；而另外一些為眾多開發者所追捧的新技術，它們未必真正達到如預期的那種生產力提公升，並且，使用「老舊」的技術實際上可以達到同樣的效果。無論如何，這些確實來自真正的一線開發者的實際經驗總結。我希望你能夠聽一聽他們的聲音。
作者是乙個以 postgresql 為主要產品的雲服務提供商負責人。他的核心觀點如下：
在我的職業生涯中，我學到了很多技能，但沒有一種技能比 sql 更有用。sql 在我看來是最有價值的技能，我的意見：部分同意作者的說法。在這些年中，我觀察到的乙個有趣的趨勢是：各種 nosql 技術開始時都標榜自己和傳統 rdbms 的不同，但隨著產品的發展，他們最終還是發現自己需要 sql （或類似的東西）。不過，我認為 sql 也有自己的問題，那就是作為數十年前發布的技術，它沒有包含關於如何分布式執行的內容，而這是從 google 的早期**到現在的各種資料平台一直在致力解決的。此外，目前似乎有一種令人討厭的趨勢，即隨便哪個公司都聲稱自己在應用大資料。我相信很多小公司的資料問題是可以在 sql 的層面得到解決的。它對於不同的職業角色和學科來說都是有價值的；
一旦學會了就不需要重新再學；
它讓你看起來像個超級英雄。一旦你掌握了它，而其他人不懂，你就顯得特別強大。
關於作者的觀點，有乙個有趣的佐證，那就是 tiobe 的程式語言趨勢報告。
從圖中我們可以看到，在排名前 20 的語言各自都有不同程度的起起落落，唯有 sql 從 2023年以後就保持了驚人的穩定，幾乎沒有任何浮動。為什麼 sql 能保持如此穩定的分數，tiobe 並沒有太多公開的細節可供參考，但這確實在一定程度上證明了作者的結論。從長期來看，sql 或許應當被看作乙個回報率不算突出、但非常穩定和值得信賴的投資。在投身學習紛繁複雜的各種資料技術之前，或許你應該首先了解一下這個已經存在了 50 年之久的名字：sql。
儘管起了這樣乙個題目，但通讀全文後你會發現，作者本人其實是很喜歡 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並將其部署在關鍵性任務系統之內。docker in production: a history of failure在計算機程式設計領域，流傳著這樣一句至理名言：「不成熟的優化是萬惡之源」。然而，今年以來我們的大部分客戶都堅持「我們必須從起步階段就全部實現docker化。」因此不同於傳統最初最佳實踐要求的建立一套工作系統、將其投入生產、最後考量docker能否帶來比較優勢的作法，客戶們開始盲目推動docker的標準化開發與部署。
新技術肯定有新的價值，這一點毫無疑問，我也無意否定開發者求新求變的理想和追求。但在追逐新技術的同時，請不要忘了我們的「老」技術，不管你用或不用，它們就在那裡。
最後，我還是想引用 《docker：一場令人追悔莫及的豪賭》一文對舊技術的評價，因為這段文字深得我心：
無聊的好處（限制水平較高）在於，這些東西的功能相對更容易理解。而更重要的是，我們能夠更輕鬆地了解其故障模式。……但對於閃閃發光的新技術而言，其中的未知因素要多得多，這一點非常重要。換句話來說，已經存在了十年的軟體更易於理解，而且未知因素更少。未知因素越少，運營開銷越低，這絕不是壞事。
談一談對新技術的態度
在it行業我們經常遇到各種各樣層出不窮的框架以及工具庫，但是人總是習慣於待在乙個舒適區的，對於一些事物的改變，即使心裡抱著一種支援的態度，但是也很難落實到行動中來。而且公司的專案基於已有的框架和技術已經能夠很好的完成各項任務，並且應用新技術可能導致一系列的問題。由於這兩個原因，對於很多新技術我都只是...
探求技術是否能改變我們現在的處境
大學畢業已經一年了，飄忽著在一家公司裡工作了一年，最近又換了份工作，待遇和原來的差不多，感覺自己又迷茫了，不知道往 走，往哪個方向走，今天看看這個，明天看看那個，感覺自己總是在表面上浮動，做什麼都沒有深入進去，這種煎熬讓我感到非常的痛苦，在新的工作環境裡，一直想著如何把工作做好，想想做軟體的不光要會...
注意新技術的風險是否會超過獲得成功的機率
突然之間有了這樣乙個感觸 新技術的運用也許會有很多好處，比如可以提高自己的團隊成員的技術水平，可以大大的提高團隊的生產力等等 運用新技術也並不見得就一定會帶來更大的實惠，比如學習和交流需要成本。可以說，新技術的運用，很可能帶來的風險會超過獲得成功的機率。我目前所在的專案組在做gis相關的開發，本來已...