2個軟體開發原則如何挽救您的專案 -Jordy Baylac

banq發表於2019-01-20

在這篇文章中，我將重點解釋一種設計模式（控制反轉）和一種實踐（YAGNI）如何降低軟體專案失敗的可能性。您可以立即開始應用這些技術。
如果您是工程經理，如果您想降低功能邊際成本的波動性，那麼這是一個很好的解讀

控制反轉（IoC）
我的意思是依賴注入嗎？真的不是，但我們可以使用依賴注入作為實現依賴關係之間的控制反轉的工具。
IoC可以幫助改變依賴方向。它可以在元件A依賴於元件B的情況下提供幫助，現在您希望A不知道B的實現細節
一個未知的應用程式，有三個眾所周知的層。

UI - > REST API - >資料庫

放大REST API我們找到了UsersController類。我們注意到它是從/向SQLServer資料庫讀取和寫入的。以下是C＃的可能實現：

//...
public class UsersController {
  
  public void postUser(User userInfo) {
      //...
      SqlCommand cmd = new SqlCommand("CreateUser", conn);
      cmd.Parameters.AddWithValue("@username", userInfo.name);
      bool isOk = cmd.ExecuteNonQuery() > 0;
      //...
  }
}

如果您認為上述解決方案不是一個好的設計，那麼你是對的
在該示例中，UsersController被緊密耦合與SQLServer的執行情況。該postUser方法使得很難寫測試（記住，單元測試不應該打資料庫或外部服務）。隨著應用程式的擴充套件，將對所使用的特定SQLServer庫產生高度依賴性。如果有人決定按域區域拆分應用程式，可能會很麻煩

前面提到的A B元件，在這種情況下：
  • A = UsersController
  • B = .NET上的System.Data.SqlClient

如果我們應用Inversion of Control以使UsersController不依賴於特定的SQLServer實現，該怎麼辦？如果我們讓REST API不知道我們正在使用什麼持久層呢？

interface  IUserService {
  void  createUser（User  userInfo）;
}
public class UsersController {
  
  UsersController(IUserService userService){
    this.userService = userService;
  }
  
  public void postUser(User userInfo) {
      //...
      var ok = this.userService.createUser(userInfo);
      //...
  }
}
//...
public class SQLUserService : IUserService {
  
  public void createUser(User userInfo) {
      //...
      SqlCommand cmd = new SqlCommand("CreateUser", conn);
      cmd.Parameters.AddWithValue("@username", userInfo.name);
      bool isOk = cmd.ExecuteNonQuery() > 0;
      //...
  }
}

優點
  • 我們的架構可以擴充套件。此外，我們減少了在現有課程中修改的必要性。開/關原則
  • 測試很容易寫。我們可以在測試UsersController時注入模擬UserService
  • 業務邏輯沒有耦合或依賴於任何永續性策略


YAGNI
意思是：你不需要它！

我認為每個開發人員都應該採用YAGNI作為他們的核心實踐之一。這個原則可以幫助您避免過度工程和使用未使用的程式碼（不可觸及）。它還可以節省您的工作。

一個有趣的小故事：
我在一個專案中工作，其中Software Architects決定用char資料型別代表資料庫中的幾乎所有布林列。至少他們使用英語，true儲存為“Y”，false儲存為“N”。這有道理嗎？當我問到如何構思神奇的解決方案時，他們回答說：

“透過這種方式，我們對第三種狀態存在可能性持開放態度”。

我從來不知道真/假的東西如何能有第三種狀態（也許他們想過量子位元）。正如您可能注意到的，這最終是一個非常糟糕的決定，並且後果遍佈整個程式碼。我找到了類似的東西：

if（supportVisa ===“Y”|| supportVisa ===“y”）{...


程式碼可讀性受到影響，SQL查詢也受到影響。
但這並不止於此。隨著時間的推移，該軟體將國際化新增到其使用者介面中。一些配置和目錄由客戶端自己使用GUI應用程式提供。我們得到了一些布林列的“S”和“N”（西班牙語中的S i和N o）。
程式碼真的不可維護。我不想談論他們提出的解決方案

結論
根據Bob叔叔的說法，優秀的開發人員會盡量減少未做出的決策。不要在六個月內寫下你認為有用的東西，而是等待六個月，看看你的架構，看看它有多少進化，然後做好工作。應用YAGNI。
您應該正確管理您的依賴項，控制反轉將指導您。
我希望這些進入你的意識，並幫助你成為一個更好的開發人員。
“任何傻瓜都可以編寫計算機可以理解的程式碼。優秀的程式設計師編寫人類可以理解的程式碼。“  - Martin Fowler

相關文章