1. <em id="2qvri"><tr id="2qvri"></tr></em>
      1. 首頁»程序人生»我們是否應當克制對新技術的追求?

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

        來源:流光飛舞 發布時間: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:一場令人追悔莫及的豪賭》一文對舊技術的評價,因為這段文字深得我心:

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

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

        QQ群:WEB開發者官方群(515171538),驗證消息:10000
        微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
        提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
        網友評論(共0條評論) 正在載入評論......
        理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
        登錄會員中心
        江苏快3投注技巧