2个软件开发原则如何保存您的项目 -Jordy Baylac

在这篇文章中，我将重点解释一种设计模式（控制反转）和一种实践（YAGNI）如何降低软件项目失败的可能性。您可以立即开始应用这些技术。

如果您是工程经理，如果您想降低功能边际成本的波动性，那么这是一个很好的解读

控制反转（IoC）

我的意思是依赖注入吗？真的不是，但我们可以使用依赖注入作为实现依赖关系之间的控制反转的工具。

IoC可以帮助改变依赖方向。它可以在组件A依赖于组件B的情况下提供帮助，现在您希望A不知道B的实现细节

一个未知的应用程序，有三个众所周知的层。

UI - > REST API - >数据库

放大REST API我们找到了UsersController类。我们注意到它是从/向SQLServer数据库读取和写入的。以下是C＃的可能实现：

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

如果您认为上述解决方案不是一个好的设计，那么你是对的

在该示例中，UsersController被紧密耦合与SQLServer的执行情况。该postUser方法使得很难写测试（记住，单元测试不应该打数据库或外部服务）。随着应用程序的扩展，将对所使用的特定SQLServer库产生高度依赖性。如果有人决定按域区域拆分应用程序，可能会很麻烦

前面提到的A B组件，在这种情况下：

• A = UsersController
• B = .NET上的System.Data.SqlClient

如果我们应用Inversion of Control以使UsersController不依赖于特定的SQLServer实现，该怎么办？如果我们让REST API不知道我们正在使用什么持久层呢？

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

优点

• 我们的架构可以扩展。此外，我们减少了在现有课程中修改的必要性。开/关原则
• 测试很容易写。我们可以在测试UsersController时注入模拟UserService
• 业务逻辑没有耦合或依赖于任何持久性策略

YAGNI

意思是：你不需要它！

我认为每个开发人员都应该采用YAGNI作为他们的核心实践之一。这个原则可以帮助您避免过度工程和使用未使用的代码（不可触及）。它还可以节省您的工作。

一个有趣的小故事：

我在一个项目中工作，其中Software Architects决定用char数据类型代表数据库中的几乎所有布尔列。至少他们使用英语，true存储为“Y”，false存储为“N”。这有道理吗？当我问到如何构思神奇的解决方案时，他们回答说：

“通过这种方式，我们对第三种状态存在可能性持开放态度”。

我从来不知道真/假的东西如何能有第三种状态（也许他们想过量子比特）。正如您可能注意到的，这最终是一个非常糟糕的决定，并且后果遍布整个代码。我找到了类似的东西：

<b>if</b>（supportVisa ===“Y”|| supportVisa ===“y”）{...

代码可读性受到影响，SQL查询也受到影响。

但这并不止于此。随着时间的推移，该软件将国际化添加到其用户界面中。一些配置和目录由客户端自己使用GUI应用程序提供。我们得到了一些布尔列的“S”和“N”（西班牙语中的S i和N o）。

代码真的不可维护。我不想谈论他们提出的解决方案

结论

根据Bob叔叔的说法，优秀的开发人员会尽量减少未做出的决策。不要在六个月内写下你认为有用的东西，而是等待六个月，看看你的架构，看看它有多少进化，然后做好工作。应用YAGNI。

您应该正确管理您的依赖项，控制反转将指导您。

我希望这些进入你的意识，并帮助你成为一个更好的开发人员。

“任何傻瓜都可以编写计算机可以理解的代码。优秀的 程序员 编写人类可以理解的代码。“  - Martin Fowler