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

banq發表於2021-08-31
程式設計

這篇文章的靈感來自於 HackerNews 上的一條評論，我再也找不到了。它的要點是“雖然架構經常被過度設計，但程式碼本身卻經常被設計不足”。如果有人認出作者，我會很樂意歸於他們。作為免責宣告，本文描述了我在過去 10 年擔任顧問的經歷。可能有一些框架和方法可以解決我將要描述的問題，但它們要麼沒有得到應用，要麼沒有得到很好的應用。
 

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

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

在與其他開發人員交談時，企業應用程式的工作經常被貶低。當然，這些專案不會開發令人興奮的新技術，不會編寫新的流編解碼器或使用區塊鏈（這仍然是一回事嗎？）。但是，雖然表面上看起來微不足道，但企業軟體開發正試圖解決有關資料的非常困難的問題。開發人員必須處理來自不同來源的大量資料。這些源中的每一個都可能定義相同的實體，只是在它們自己的域中略有不同，這使得這些域之間的轉換非常複雜。此外，他們需要在不斷增長的系統中考慮大量複雜的業務規則。
 

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

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

專案經理的任務是確保在時間和預算內完成專案目標。如果這些目標在某種程度上得到滿足，則該專案被認為是成功的。預算通常是固定的，要完成的目標也是固定的。
對我來說，第一個基本缺陷是固定結局，這意味著軟體在某個時候“完成”了。通常透過將開發工作分為“專案階段”和“維護階段”來“解決”。專案完成後，開發團隊通常會解散，軟體被移交給“維護團隊”（通常有大量初級開發人員）。
這種方法的一個好處是，專案團隊需要在軟體移交之前對其進行徹底的記錄,這將我們引向了專案設定中的第二個缺陷：將軟體從一個團隊移交給另一個團隊時，在此過程中會丟失很多知識。為了減少專案工作的界限，許多公司嘗試在這些專案中應用敏捷框架，主要是 SCRUM。
就個人而言，我有從未見過 SCRUM 或任何敏捷方法在專案設定中起作用。不過，我有偏見，因為真正踐行敏捷價值觀的公司不會在專案設定中進行軟體開發，更不用說外部顧問了。他們會意識到他們的應用實際上是不斷改進的產品。
 

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

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

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

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


 

相關文章