DRY 원칙 마스터하기: C#에서 디자인 패턴을 적용하여 코드 깨끗하게 작성하기

단계 및 예시:

1. 초기 코드: 직원 ID 생성 로직은 버튼의 클릭 이벤트 핸들러에 직접 구현되어 있었습니다.

   

2. 리팩토링된 코드: Tim은 해당 메서드를 더욱 유연하게 만들어 개선했습니다. 특정 UI 요소에 의존하는 대신, 이제 이 메서드는 firstName 및 lastName를 매개변수로 받아 생성된 ID를 반환합니다. 이러한 변경으로 해당 메서드를 다양한 컨텍스트와 UI 요소에서 사용할 수 있게 되었습니다.

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   Tim은 클릭 이벤트에서 이 메서드가 어떻게 호출되는지 보여줍니다.

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   그는 또한 이 방법을 사용하면 코드를 반복 작성하지 않고도 여러 직원 기록이 포함된 CSV 파일을 처리하는 등 애플리케이션의 다른 부분에서도 사용할 수 있다고 언급했습니다.

단계 및 예시:

1. 클래스 라이브러리 생성:

   • Tim은 (9:47)에 .NET Framework 에서 DRYDemoLibrary라는 이름으로 새 클래스 라이브러리 프로젝트를 생성합니다.

   • 그는 이 라이브러리 안에 공용 클래스 EmployeeProcessor를 정의하고 메서드 GenerateEmployeeID를 이 클래스 안으로 이동합니다:

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

2. 프로젝트에서 클래스 라이브러리 사용하기:

   • Tim은 WinForms(13:18) 및 WPF 프로젝트(14:00)에서 DRYDemoLibrary 클래스 라이브러리에 대한 참조를 추가합니다.

   • 그런 다음 그는 클래스 라이브러리에서 GenerateEmployeeID 메서드를 호출하여 이전 코드를 대체합니다:

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   • 이 접근 방식은 메서드가 한 곳에 유지 관리되므로 중복을 제거합니다. Tim은 동일한 클래스 라이브러리를 코드 중복 없이 서로 다른 UI 프레임워크(WinForms 및 WPF)에서 사용할 수 있음을 보여줍니다.

3. 장점:

   • 일관성: Tim은 로직을 클래스 라이브러리에 집중시킴으로써 로직 변경 사항(예: 버그 수정)이 모든 프로젝트에 일관되게 적용되도록 보장합니다.

   • 유지보수 부담 감소: 메서드 변경은 클래스 라이브러리에서만 하면 되므로, 코드 불일치를 방지하고 유지보수 오버헤드를 줄일 수 있습니다.

단계 및 예시:

1. 새로운 솔루션 및 프로젝트 생성:

   • Tim은 (17:29)에서 콘솔 애플리케이션용 새 솔루션을 만들어 Windows 서비스나 콘솔 앱과 같은 다른 유형의 프로젝트에서 DRYDemoLibrary를 사용해야 할 수도 있는 시나리오를 시뮬레이션합니다.

   그는 새 프로젝트의 이름을 ConsoleUI로 정하고 기본적인 콘솔 애플리케이션을 설정하는 방법을 보여줍니다.

     class Program
     {
        static void Main(string[] args)
        {
           Console.ReadLine();
        }
     }

     class Program
     {
        static void Main(string[] args)
        {
           Console.ReadLine();
        }
     }

2. 클래스 라이브러리에 참조 추가하기:

   • Tim은 새 프로젝트에 DRYDemoLibrary DLL에 대한 참조를 추가하는 방법을 설명합니다. 이 과정은 클래스 라이브러리 프로젝트의 bin 폴더에 있는 DLL 파일을 찾아 콘솔 애플리케이션에 추가하는 것을 포함합니다.

     using DRYDemoLibrary;

     using DRYDemoLibrary;

   • 참조가 추가되면 Tim(19:24)은 라이브러리의 EmployeeProcessor 클래스를 사용하여 사용자 입력에 따라 직원 ID를 생성합니다.

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

3. 콘솔 애플리케이션 실행:

   • Tim은 콘솔 애플리케이션을 실행하여 라이브러리를 사용하여 직원 ID가 성공적으로 생성됨을 보여줍니다. 이는 클래스 라이브러리의 동일한 코드를 여러 프로젝트에서 재사용할 수 있음을 확인시켜 줍니다.

     

4. DLL 업데이트:

   • Tim은 DLL이 변경될 경우 해당 DLL을 참조하는 프로젝트에서 업데이트할 수 있다고 간략하게 언급합니다. 그는 이 영상에서 자세히 다루지는 않지만, NuGet 패키지를 사용하는 것이 여러 프로젝트에 걸쳐 DLL을 관리하고 업데이트하는 데 권장되는 접근 방식이라고 언급합니다.

핵심 요점:

1. NuGet 패키지 생성:

   • Tim은 DLL 파일을 수동으로 관리하는 대신 클래스 라이브러리용 NuGet 패키지를 만들 것을 제안합니다. 이 과정에는 DLL을 NuGet 패키지로 패키징하고 NuGet 서버(개인 또는 공용)에 업로드하는 작업이 포함됩니다.

2. 패키지 업데이트:

   • NuGet 패키지를 사용하면 패키지 버전을 업데이트하는 것만으로 해당 라이브러리를 참조하는 모든 프로젝트에서 라이브러리를 업데이트할 수 있습니다. 이렇게 하면 일관성이 보장되고 버전 불일치 또는 업데이트 누락 위험이 줄어듭니다.

3. 장점:

   • 중앙 집중식 관리: NuGet 패키지는 라이브러리 버전 및 종속성을 중앙 집중식으로 관리할 수 있는 방법을 제공합니다.

   • 업데이트 용이성: 여러 프로젝트에 걸쳐 라이브러리를 업데이트하는 것이 더 쉽고 안정적입니다.

   • 통합: NuGet 다양한 개발 도구 및 환경과 통합되어 라이브러리 종속성 관리 프로세스를 간소화합니다.

초기 테스트 설정

팀은 먼저 DLL의 버그로 인해 현재 실패하는 단위 테스트를 실행합니다. 그는 코드가 메인 솔루션 외부에 있더라도 문제를 식별하는 데 있어 단위 테스트의 중요성을 강조합니다. 해당 코드는 4글자 입력을 예상했지만 Tim이 3글자 이름을 전달했고, 이로 인해 DLL 파일이 솔루션에 직접 포함되지 않더라도 오류가 발생합니다.

버그를 해결하기 위한 코드 리팩토링

팀(Tim)은 이름 처리 문제를 해결하기 위해 코드를 리팩토링했습니다. 그는 새로운 클래스 라이브러리 프로젝트를 생성하여 DRY 원칙을 개발에 적용하는 방법을 설명합니다(23:50). 이러한 접근 방식을 통해 여러 객체에 대한 변경 사항을 한 번만 적용하고 수정 작업을 반복하지 않고도 효과적으로 테스트할 수 있습니다.

단위 테스트 추가하기

Tim은 클래스 라이브러리 프로젝트에 EmployeeProcessorTest라는 새로운 테스트 클래스를 추가하고 XUnit을 사용하여 단위 테스트를 설정합니다. 그는 직원 ID를 생성하는 테스트 메서드를 만드는 방법을 보여주고 실제 값에 의존하는 대신 종속성을 모킹하는 것의 중요성에 대해 논의합니다.

테스트 메서드 작성하기

Tim은 GenerateEmployeeID_ShouldCalculate라는 단위 테스트 메서드를 작성합니다. 그는 다양한 시나리오를 테스트하기 위해 인라인 데이터를 사용하여 이론을 설정하고, 해당 방법이 예상대로 결과를 반환하는지 확인합니다. 그는 또한 Assert.Equal을 사용하여 출력을 검증하는 방법을 설명합니다.

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

유닛 테스트 실행

팀은 테스트 조건과 결과를 제어하기 위해 날짜 및 시간 값과 같은 동적 데이터를 모킹하는 것이 중요하다고 강조합니다. 그는 동적 문자열을 다룰 때의 어려움과 제어된 값을 사용하여 다양한 시나리오를 테스트하는 방법에 대해 논의합니다. 그 후에 유닛 테스트를 실행하는데, 그 전에 테스트 실행을 위해 필요한 두 개의 NuGet 패키지 xunit.runner.console와 xunit.runner.visualstudio를 추가합니다.

하나의 인라인 데이터에 대한 모든 테스트를 성공적으로 실행한 후 출력은 다음과 같습니다.

이제 (31:30)에 Tim은 또 다른 인라인 데이터를 추가하고 서브스트링 두 번째 매개변수를 expectedStart.Length로 변경했습니다:

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

(32:05)에서 두 번째 가설을 적용하여 단위 테스트를 다시 실행한 후 테스트가 실패했습니다.

private 메서드를 사용하여 코드 개선하기

DRY 원칙을 따르기 위해 Tim은 실제 EmployeeProcessor 클래스 아래 DRYDemoLibrary에서 개인 메서드 GetPartOfName을 생성하여 코드를 더 리팩토링합니다. 이 메서드는 이름의 일부를 추출하여 코드 재사용성과 가독성을 향상시킵니다. 팀은 다음과 같이 변경했습니다.

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

단위 테스트 업데이트

팀은 부분 문자열의 예상 길이를 수정하는 등 코드 변경 사항을 반영하여 단위 테스트를 업데이트합니다. 그는 이러한 테스트를 실행하면 문제를 신속하게 파악하고 코드가 새로운 요구 사항을 충족하는지 검증하는 데 도움이 된다고 설명합니다. 팀은 새로운 이론을 추가한 다음 단위 테스트를 실행하여 출력 결과가 예상대로 나오는지 확인합니다.

.NET Standard 라이브러리 생성

개발 과정에서 반복을 줄이기

팀 코리는 .NET Standard 라이브러리를 채택함으로써 코드베이스뿐만 아니라 개발 프로세스에서도 코드 반복을 최소화할 수 있다고 강조합니다. 서로 다른 플랫폼별 프로젝트에서 코드를 중복 작성하는 대신, 여러 환경에서 작동하는 단일 라이브러리에 코드를 중앙 집중화할 수 있습니다.

이익:

• 통합 코드베이스 : 다양한 플랫폼에서 하나의 코드베이스를 사용하면 코드 유지 관리 및 업데이트에 필요한 노력을 줄일 수 있습니다.
• 간소화된 테스트 : .NET Standard 라이브러리를 사용하면 단위 테스트를 한 번만 작성하여 지원되는 모든 플랫폼에 적용되는지 확인할 수 있습니다.

테스팅 및 디버깅: 팀은 노력과 반복 작업을 더욱 줄이는 방법으로 유닛 테스팅을 소개합니다. 자동화된 테스트는 애플리케이션의 각 반복 버전을 수동으로 테스트할 필요 없이 코드의 정확성을 검증합니다.