企業軟體專案扼殺了程式設計 - Tim

什麼是企業軟體開發？
我對企業軟體的理解深受 Martin Fowlers 在“企業應用程式架構模式”（2002，Addison Wesley）中定義的影響。

• 為組織內部使用而開發
• 處理來自多個來源的複雜、持久的資料
• 適用於複雜的業務規則
• 通常是多使用者系統（意思是併發）
• 通常整合到更大的系統環境中

軟體開發專案的問題
我作為外部開發人員和顧問參與了許多企業軟體專案，經常會看到專案方法論干擾了軟體的目標。在我看來，專案不是開發優秀軟體的合適環境。一個專案的核心屬性是：

• 專案時間和預算有限
• 專案團隊只在有限的時間內組成

標準化
考慮到上面列出的缺陷，整個開發生命週期中的主要關注點之一是避免程式碼中的“意外”。如果程式碼被新的專案團隊或維護團隊採用，它應該很容易理解，以便可以以儘可能少的努力新增新功能或錯誤修復。
這方面的主要工具是標準化。
在較大的企業中，通常有一個“企業架構”團隊，它位於所有軟體專案之上並標準化開發過程。在哪個版本中使用哪種語言？允許使用哪些框架、庫？需要哪些技術棧，哪些測試方法？可以考慮哪些架構指南？這種宏觀架構通常以驚人的細節規定。
在某種程度上，這很有意義：如果您的軟體開發人員必須在專案設定中工作，他們將不得不隨著時間的推移處理大量程式碼庫。維護團隊可能同時負責許多不同的應用程式。如果開發人員在所有這些應用程式中“感到賓至如歸”，因為他們立即識別結構和技術，他們可以更快地開始工作。
難的部分是避免設定太多規則。我曾為確定要使用的確切 Spring Boot 版本的客戶工作。如果版本是企業架構師升級的，那麼整個公司就得整體升級。我曾為客戶工作過，他們規定只使用 Hibernate 和 Hibernate 查詢語言 (HQL)，禁止在 POJO 上使用原生 SQL、其他框架或投影。
在專業方面，開發人員不必熟悉 SQL，並且訪問資料庫的方式是標準化的，當然，這導致大多數應用程式的效能低於標準。此外，無法利用非常昂貴的 Oracle 企業資料庫的專有特性。
但即使這些標準化在軟體專案中導致了巨大的問題，企業架構師也不會爭論。
 

分層架構
標準化的黃金標準是分層架構。再次引用 Fowler 的《企業應用架構模式》的定義，分層是一種分解複雜軟體系統的技術。從理論上講，將永續性、領域邏輯和表示分離在不同的層中可以使應用程式的推理更容易。每一層只需要知道下面的層，例如領域層知道持久層，但不知道它是被REST服務、Web應用程式、富客戶端還是終端介面呼叫。這不僅以易於發現的方式構建應用程式，而且還使得將應該分離的不同關注點交織在一起變得更加困難。但它也會將應用程式域邏輯切割成單獨的子域，並且會對效能產生影響。
 

為什麼這一切會導致程式碼設計不足？
軟體開發人員的環境越標準化，他們的程式碼就越不完善。對我來說，設計不足的程式碼是可以實現其目標的程式碼，效能更高、冗長或重複更少。堅持上面的例子：如果開發人員被禁止編寫原生 SQL，他們將受到 HQL 的限制，編寫較慢的查詢或需要從他們的應用程式中獲取多個查詢來完成一項任務。如果在每個細節中都規定了確切的語言、框架、庫，開發人員有時需要使用這些工具來解決他們的需求，而不是使用正確的工具來解決他們的問題。如果要積極遵循分層架構，那麼 50% 的程式碼將是層之間的對映器。如果你總是不得不考慮專案完成後可怕的程式碼移交，
 

如何改善現狀？
將您的軟體視為產品，而不是專案。然後，您可以從宏觀架構中消除過多的細節。如果開發軟體的團隊在更長的時間內保持一致，他們就可以“冒險”更多地專注於他們的技術，為他們必須解決的問題選擇合適的工具和架構風格。他們可以“冒險”編寫更復雜的演算法，利用他們語言中鮮為人知的部分。知識將留在團隊中，就像團隊本身一樣。儘管微服務現在遠遠落後於炒作週期的高峰期，但它們可以成為實現這一目標的非常有用的工具。