[Chapter 18,19] 급여 관리 사례 연구

급여 관리 사례 연구의 🔑 Key Point

책에서는 간단한 일괄 임금 지급 시스템 개발을 예로 들어 설명하고 있다. 책에서 나오는 "반복의 시작", "구현" 부분에서 내가 느낀 포인트 위주로 정리하려 한다.

1. 첫 반복에 선택된 스토리에 대해 간단히 나열한다.
2. 요구사항을 듣고 데이터베이스 스키마를 생성하려 하지 말자!
   • 이런 접근 방식은 자연스럽게 DB의존적인, 데이터베이스가 중심적 괌심사가 되는 어플리케이션을 만들도록 유도한다.
   • 데이터베이스는 구체적인 구현이다. → 가능한 DB에 대한 고려는 뒤로 미뤄야한다.
   • 본질의 확충과 지엽적(부수적)인 것의 제거라는 추상화의 정의를 상기하자.
   • 데이터베이스는 이 단계의 프로젝트에서는 지엽적인 것. → 그저 데이터를 저장하고 접근하는 용도, 그 이상 이하도 아님.(물론 예외적인 프로젝트도 존재할 수 있다.)
3. 시스템의 데이터보다는 시스템의 행위를 먼저 생각하자!
   • 우리가 만드는 것은 시스템의 행위(동작)
   • 이러기 위한 기법 중 하나 → 유스케이스 만들기
   • 유스케이스
     • 좀 더 구체적인 내용이 추가되어 상세해진 사용자 스토리 (책에서 예시와 함께 잘 나와있음)
     • 순서
       • 현재 반복에서 구현할 사용자 스토리 선택 → 상세화 → 유스케이스
     • 시스템의 사용자들이 시스템에 줄 수 있는 여러 종류의 자극을 알아내기 위해 사용자 스토리와 인수 테스트 등을 살펴본다
     • 목적
       • 이 시스템에 어떤 자극을 주면 어떤 식으로 반응 하는지 알아내는 것
     • 상세화는 각 스토리를 충족시키는 코드 설계를 생각하는데 도움이 될 정도만 진행한다.
4. 각각 유저 스토리들을 상세화시켜 유스케이스를 뽑아내고, 그 과정에서 적절한 패턴을 사용해서 클래스 구조를 뽑아낼 수 있다!
5. 여러 유스케이스를 만들어내면서 기존의 생각했던 설계, 적용하려했던 패턴이 변경될 수 있다. -> (구현 단계에서도 더 적절한 형태와 패턴을 찾아가며 설계가 변화할 수 있다고 생각한다. 사실 이 부분은 개인적으로 대략적인 틀만 잡고 TDD방식으로 진행하여 테스트에게 피드백 받으며 구현하고, 리팩토링하며 특정 패턴을 발견하며 설계를 진행하는 것이 더 좋은 설계에 다가가기 좋다고 생각한다.)
6. 설계를 할 때도, 패턴을 적용하는 이유(패턴을 적용하기로 결정했다면), 그리고 패턴을 적용할 때 또는 그냥 클래스 구조를 설계할 때 SOLID 원칙은 잘 지켜지고 있는지, 정말로 요구사항을 잘 만족하고 있는지 등을 확인하며 설계를 해야한다!
7. 책의 예시를 쭉 보면서 유스케이스의 분석이 시스템 설계에 풍부한 정보를 준다는 것을 알 수 있었다. 또한 설계가 진행되는 것들을 보며 이 모든 것이 유스케이스 즉, 행위에 대한 고찰로 인한 결과물이라는 것도 알 수 있었다.
8. 잠재적인 추상화를 찾아내자!
   • OCP를 효과적으로 사용하기 위해서는 애플리케이션 내에 잠재하는 추상화를 찾아내야 한다!
   • 요구 사항과 유스케이스는 잠재적인 추상화의 일반적인 내용들을 표현하기에는 지나치게 구체적
   • 여러 요구사항과 유스케이스들을 분석하며 일반화에 대한 힌트를 얻을 수 있다. 그리고 거기서 추상화할 것을 찾아낼 수 있다!
   • 요구사항이 내포하는 것을 잘 catch해야한다! (책 내의 지급 주기와 지급 정책의 분리 → 그로 인해 지급 주기 변경에 대해 지급 정책이 닫혀있게 되고, OCP, SRP를 모두 지킬 수 있게 된다!)
   • 변경하려했던 A를 변경하였더니 B도 영향이 가는, 변경의 영향이 예측되지 않는 상황은 두려움을 야기하고 사용자와 관리자의 개발자에 대한 신뢰성을 떨어뜨린다.
9. 빠른 설계 회의
   • 한 반복이 시작될 때, 화이트보드 앞에 팀이 모여 그 반복에 선택된 사용자 스토리의 설계를 놓고 논의하는 회의
   • 보통 1시간 전에 종료
   • 목적
     • 사고 과정을 시작
     • 공통적인 사고 모델을 가짐
   • 확실한 설계가 목적이 아니다!
   • 이번 챕터에서 한 활동이 빠른 설계 회의와 동등한 텍스트 형태

결론

사실 공통의 그림을 가질 수 있다는 점에서 이런 설계를 다이어그램으로 뽑아내는 것이 중요하다. 하지만 개인적으로 이러한 설계가 단점이 될 수도 있다고 생각한다. 구현 전의 설계와 구현 후의 설계는 다를 수 있기 때문이다. 실제로 구현하며 발견할 수 있는 부분이 있고, 직접 테스트를 진행하며 발견할 수 있는 부분도 많다. 그렇기에 처음부터 여긴 이 패턴을 적용하고, 이 클래스가 필요할 거고, 이 인터페이스가 필요할 것이고 하는 것보다는 큰 틀만 잡고 간단한 TDD를 사용하여 먼저 구현하여 테스트에게 피드백 받고, 잠재적 추상화를 발견하고 패턴을 발견하는 방향으로 진행하는 것이 더 좋은 설계에 다가가기 좋다고 생각한다.