在編程中，為何說數據仍佔主導地位？

互聯網時代，究其根本，也是一個數據不斷疊加的時代，而這對於開發者而言，又意味著什麼？

作者 | Simon Arneaud

譯者 | 彎月，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

以下引用的是2006年Linus Torvalds說過的一句話：

我非常贊成圍繞數據設計代碼，我認為這是Git取得成功的原因之一......事實上，我認為一位糟糕的程序員與一位優秀的程序員之間的區別就在於，在他心目中代碼與數據結構哪個更重要。糟糕的程序員關心的是代碼，而優秀的程序員關心的則是數據結構及其關係。

這句話與2003年Eric Raymond提出的「表示原則」非常相像：

把知識疊入數據以求邏輯質樸而健壯。

與1989年Rob Pike總結的想法也很類似：

數據佔主導地位。如果你選擇了正確的數據結構，而且進行了良好的組織，那麼演算法幾乎不言自明。數據結構才是編程的核心，而非演算法。

還有1975年Fred Brooks在《人月神話》中說道：

數據的表現形式是編程的根本

創造出自精湛的技藝，精鍊、充分和快速的程序也是如此。技藝改進的結果往往是戰略上的突破，而不僅僅是技巧上的提高。這種戰略上突破有時是一種新的演算法，如快速傅立葉變換，或者是將比較演算法的複雜度從n2 降低到n log n。

更普遍的是，戰略上的突破常來自數據或表的重新表達——這是程序的核心所在。如果提供了程序流程圖，而沒有表數據，我仍然會很迷惑。而給我看錶數據，往往就不再需要流程圖，程序結構是非常清晰的。

如上所示，近半個世紀以來，很多偉人反覆強調：關注數據。然而，有時我感覺人們忘記了偉人給我們的編程忠告。

讓我舉幾個例子。

無法擴展的高度可擴展系統

這種系統的設計初衷就是為了處理CPU密集型負載，本來應該具有極佳的可擴展性。系統內沒有同步操作。一切都是通過回調、任務隊列和工作池來完成。

但是，這種系統存在兩個問題：第一，畢竟「CPU密集型負載」其實並不是那麼CPU密集，在最壞的情況下，一個任務就有可能耗費幾毫秒。所以大部分架構上的決定弊大於利。第二，雖然這種系統聽起來像一個高度可擴展的分散式系統，但事實並非如此，因為它只能在一台機器上運行。為什麼？因為非同步組件之間的所有通信都是使用本地文件系統上的文件完成的，這是目前所有擴展的瓶頸。原始設計並沒有提及數據，採用本地文件的方式只是因為「簡單」。大部分文檔講述的都是關於處理負載「CPU密集度」所需的所有額外架構。

面向服務的體系結構仍然是面向數據

這種系統遵循微服務設計，由單一用途的RESTful API組成。組件是存儲文檔的資料庫（基本上是標準表單的響應以及其他電子文書）。這種系統自然會公開用於基本存儲和檢索的API，但很快就需要更複雜的搜索功能。設計人員認為將這類搜索功能添加到現有文檔API將違背微服務設計的原則。他們認為「search」與「get/put」是不同類型的服務，因此他們的架構不應該將它們結合在一起。此外，他們計劃使用的搜索索引工具與資料庫本身是分開的，因此在實現時也需要此創建新服務。

最終只能創建一個包含搜索索引的搜索API，而該索引基本上是主資料庫數據的副本。該數據會動態更新，因此任何通過主資料庫API修改文檔數據的組件都必須更新這個搜索API。在不導致競態條件的情況下，REST API不可能做到這一點，所以無論如何，這兩組數據都無法時刻保持同步。

不論架構圖做出怎樣的承諾，這兩個API還是通過數據依賴性緊密耦合。後來人們認識到，搜索索引應該是統一的文檔服務的實現細節，這樣才能大大降低系統的維護難度。「僅做一件事」是數據層面的要求，而不是動作層面的要求。

荒謬的模塊化與配置的混亂

這種系統是一種自動化部署流水線。最初的設計人員希望製作一個足夠靈活的工具來解決整個公司的部署問題。系統可以編寫為一組插件，配置文件系統不僅配置了組件，還充當了DSL，通過編程讓組件嵌入流水線。

幾年之後，這種系統變成了人們口中的「那個程序」——bug累累，卻沒人管。沒人敢碰這些代碼，因為都害怕破壞別的代碼。沒人使用DSL的靈活性。每個人在使用該程序時，都只是複製和粘貼其他人使用過的配置。

為什麼會這樣？儘管最初的設計文檔使用了諸如「模塊化」、「解耦」、「可擴展」和「可配置」之類的詞語，但卻從未說過任何關於數據的內容。因此，組件之間的數據依賴性最終通過全局共享的JSON blob的特殊方式處理。隨著時間的推移，組件中就會出現越來越多沒有文檔記載的JSON blob或以前沒有的內容。當然，DSL允許按照任意順序重新排列組件，但大多數配置都不起作用。

經驗教訓

我選擇第三個例子的原因是因為這個例子很容易說明。有一次我在做一個網站，但是我建立了一些很尷尬的XML資料庫，所以最後也未能解決數據問題。然後，這個項目成了make的拙劣模仿，而且僅實現了make的一半功能，原因也是我並沒有考慮我真正需要的東西。

原文：https://theartofmachinery.com/2019/06/30/data_still_dominates.html

本文為 CSDN 翻譯，轉載請註明來源出處。

【End】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！