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

19-01-20 banq
         

在这篇文章中,我将重点解释一种设计模式(控制反转)和一种实践(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