【CSDN 編者按】本文作者從工程師、技術領導者和開發人員角度，在發現自己身陷應用程序“管道”復雜性的困境之中，如何巧妙解決困境！
原文鏈接：https://yrashk.medium.com/repeating-yourself-thrice-doesnt-turn-you-into-a-3x-developer-a778495229c0
作者 | Yurii Rashkovskii譯者| 彎月
責編 | 夏萌
出品 | CSDN（ID：CSDNnews）
3是一個神奇的數字。我們可在腦海中集中精力思考的事情不能超過3個。因此，從邏輯上講，三層軟件架構（數據庫、后端和前端）是一個很好的模型。
既然如此，為什么構建一個功能需要花費這么多時間呢？
作為工程師、技術領導者和開發人員，我們經常發現自己身陷應用程序“管道”復雜性的困境之中。
三層模型給開發人員帶來了一系列耗時的瑣事。三層之間無數字節被打亂、重復定義三遍數據結構，我們苦苦掙扎于解決不同代碼庫之間的同步，同時還要努力優化性能、管理數據庫模式變化，并保持數據的一致性。
因此，我們十分渴望能擁有更多的時間來創新，并為用戶構建酷炫的新功能。
我們忘記了即使在清晰的三層架構中，需要考慮的事情也不止三個。作為一個單獨的開發者小團隊，我們必須留出一部分空間思考非技術問題，例如用戶、他們的需求和溝通。即使在技術領域，三層架構中每一層之間的完全分離也迫使我們必須考慮另外兩件事：相鄰層之間的通信和同步。
三層架構以及每一層的集成讓我們疲于忙碌。假設你有一個小型博客應用程序，你想為每篇博客文章添加一個“類別”。聽起來是一件很簡單的事情。但是，如果遵循現代 Web 開發的所有良好實踐，則需要完成下列所有操作：
- 編寫一個數據庫架構遷移，在數據庫中創建“類別”的結構。另外，還需要編寫一個“向下”遷移來刪除新建的“類別”，以便能夠在必要時快速回滾。
- 修改 Go 結構定義、JAVA 類或者你選用的特定于后端語言的結構定義，而且還需要保持與新舊數據庫架構的兼容性。最后，再為處理這個新數據結構的函數編寫后端單元測試。
- 編寫新的數據庫查詢，并編寫文檔記錄 API 響應的變化。
- 更新前端的 Type 類型，添加新字段，同時確保無論是否有這個新字段都可以解析后端響應。最后，再針對這段邏輯編寫單元測試。
- 更新 React 組件，顯示帖子的“類別”。
- 確保所有層中“類別”的數據驗證保持一致。
- 編寫集成測試，確保每一層的新代碼都能與系統的其余部分正常工作。
- 同步數據庫架構、后端和前端之間的更新推出。如果項目是多個團隊協同工作，則需要通知他們何時以及如何推出此次更新。
最終，在用戶看來，不過是博客文章頂部多了一小行文本。但對于開發人員來說，這是一項艱巨的任務，需要數十小時的工作才能實現。
這種低效也會影響到最終用戶。在各層之間移動字節是有代價的：網絡延遲、數據的序列化以及反序列化等。我們很難讓用戶相信加載一篇有用信息不超過幾個字節的帖子實際上需要通過 3G 網絡傳輸幾十秒的時間。我們很難向用戶解釋為什么看似一件很簡單的功能，我們卻無法實現，因為會占用太多資源。
我們如何走到了這一步？
三層架構是一個巧妙的構造，凝結了尋求優化勞動分工的數字工匠的聰明才智。
三層結構的出現不是為了成為 Web 開發人員的桎梏，而是為了應對 Web 應用程序日益加劇的復雜性。人類擺脫原始社會的狩獵與采集，文明高度發展正是依托于勞動的專業化。三層模型能夠讓各個專業職能追求卓越。雖然這種模型可以很好地服務于擁有專業團隊的大型組織，但嚴格應用到小企業則會適得其反。另外，同步和通信的開銷，專業化與分工會導致交付周期加長，這個問題也不容忽視。你見過多少這樣的團隊能夠快速交付成果？
如果你的工作是流水線式的，也就是說，你只需提供穩定的、可預測的輸入和輸出，而且時間安排是固定的，那么專業化能夠大放異彩。然而，小型組織和個人開發者沒有這樣奢侈的環境。相反，更快地反應和適應更適合他們。也就是說，交付周期越短越好。
前進之路
值得慶幸的是，除了我們之外，還有很多人都意識到了這些挑戰。新一代工具正在出現，以彌合差距，并實現快速開發應用程序的目標。
如何解決這個問題
開發人員采用了多種解決方法來緩解三層模型的問題，其中包括：
- 無代碼工具：Budibase之類的工具可以大幅縮短開發時間，幫助半技術人員快速構建完整的應用程序。但這類工具缺乏靈活性，而且很難維護，因此往往會限制應用程序長期發展。如果你希望應用程序能夠不斷成長和發展而不必重寫，那么就不可以使用無代碼工具編寫應用程序。也無法借助現代版本管理軟件，向同事發送電子郵件警告他們不要碰這段代碼，感覺像回到了中世紀。此外，無代碼工具大多無法脫離平臺。
- 后端即服務（BaaS）：Firebase 等服務提供了預制的、通用后端，消除了大量后端和數據庫的重復工作，并大大加快了應用程序的開發速度。然而，這些服務會束縛用戶，很難在本地開發，而且還會導致應用程序的獨立性降低，托管、部署和維護的成本升高。許多 BaaS 最終都被放棄或者被收購，導致每個人不得不緊急重寫代碼。最后，即便提供商不出問題，你仍然需要處理前端和 BaaS 之間的同步。
- Database-over-HTTP Web 服務器：PostgREST 和 Hasura GraphQL 等工具通過 HTTP 公開數據庫。這類數據庫極大地減少了開發人員需要完成的后端工作，同時仍然保持輕量級、易于部署且成本低廉。但它們只解決了一部分問題。它們的目標并不是成為構建應用程序的標準方法，而且你還要花時間同步前端代碼和數據庫結構。此外，除了以 JSON 的形式原樣表示未處理的數據庫內容之外，你無法執行更多操作來響應 Web 請求。
上述所有解決方案都是朝著正確方向邁出的一步，但我們仍然不滿意快速開發應用程序工具的現狀。我們相信，在不久的將來，構建一個可投入生產的應用程序所需工作量將比現在少十倍。我們不只是默默等待新工具的到來，而是正在編寫這些工具，努力將這一愿景變為現實。雖然我們還沒有找到方法來消除三重工作，但如今我們的項目從一個想法到可運行的 Web 應用程序所需的時間已大幅削減，而且無需犧牲協作開發的便利性和部署的速度。
- 例如，Ophir 正在開發 SQLPage，這是一個基于 SQL 的快速應用程序開發框架，能夠讓構建圖形 Web 應用程序像編寫數據庫查詢一樣簡單。SQLPage 提供了一個不依賴于數據庫的解決方案，沒有任何依賴性。以 SQL 為基礎，只需一天即可構建完整的 Web 應用程序。
- 與之類似，Yurii 正在開發 Omnigres：這是一款大型應用程序設計的工具，可簡化直接在 Postgres 數據庫內運行復雜后端邏輯的開發。它將 Postgres 轉變為一個完整的后端應用程序平臺。
避免下一個項目承擔三重工作
三層模型有其缺點，特別是對于獨立開發人員和小型團隊來說，它會導致開發人員在重復性的任務上花費過多時間，影響應用程序的性能和開發速度。
