[WIL] 설계 - Software Design

🤦 기존의 지식 & 생각 & 습관

• 요구사항 문서로부터 도메인 개념을 뽑아낸다.
• 설계에 대한 중요성을 직접 경험해보지 못했다.
• 시퀀스 다이어그램, 클래스 다이어그램은 따로 작성하지 않고 개발을 진행했다.
• 멱등성에 대해서 잘못된 개념을 가지고 있었다.

---

🛠️ 이번 주 경험

• 요구사항 문서 작성 (유저 시나리오 도출 -> 자연어 설명)
  • 행위 중심의 기능 목록을 정리
  • 유스케이스 흐름 작성
• 요구사항 문서를 기반으로 시퀀스 다이어그램 작성
  
  • 하나의 기능에서 객체 간 메시지 흐름을 시각화
• 클래스 다이어그램 작성
  • 도메인 개념 간 책임과 관계를 시각화
  • 엔티티/VO 분리
• ERD 작성

---

🐥 경험으로부터 배운 것들

• 문서를 작성하는 목적을 정확히 하자.
  • 내가 문서를 작성하는 목적을 정확히 해야, 문서가 전달하고자 하는 메시지가 명확해진다.
  • 요구사항과 시퀀스 다이어그램을 개발자 외 사람에게 설명한다고 생각하고 작성해보자.

• 깊은 요구사항 분석이 좋은 시퀀스 다이어그램, 클래스 다이어그램, ERD로 이어진다.
  • 스스로 요구사항을 정확히 이해하고 정리하자.
  • 잘 정리되지 않은 요구사항 문서로 인해, 계속하여 수정 반복되었다.
  • 요구사항 문서 수정이 시퀀스 다이어그램, 클래스 다이어그램, ERD 수정으로 이어지면서 스스로 헷갈리게 되었다.
• 요구사항이 시퀀스 다이어그램과 일치하는지 확인하자.
  • 설계하면서 수정되는 요구사항과 시퀀스 다이어그램에 차이가 없는지 지속적으로 확인!
  • 시퀀스 다이어그램의 흐름과 명세 사이의 이격이 발생하는 걸 주의하자.
• 요구사항을 더 뾰족하게 만들려고 노력하자.
  • 지금까지 내가 작성해봤던 요구사항 문서의 부족한 점을 느낄 수 있었다.
  • 좀 더 구체적이고 다양한 엣지케이스를 고려해보자.
• 잘 읽힐 수 있는 시퀀스 다이어그램을 작성하자.
  • 시퀀스 다이어그램을 봤을 때, 전체적인 흐름이 보일 수 있도록 작성해야 함을 느꼈다.
  • 다른 사람이 봤을 때에도 쉽게 이해할 수 있도록 표현하자.
• 멱등성이 무엇인지 다시 생각해보자.
  • 멱등성 = 첫 번째 수행한 뒤, 여러 차례 적용해도 결과를 변경시키지 않는 작업 또는 기능
  • 멱등한 API = 두 번 이상 요청해도 결과는 처음 요청과 같음
    • 좋아요가 중복됐을 때, 오류를 반환하는 건 멱등하지 않다.
• 처음과 끝을 먼저 맞춰야 한다.
  • 즉, 마감 기한에 맞추는 걸 최우선으로 하자.
    • 일단 요구되는 동작을 수행하는 상태로 기한에 맞추는 것이 중요하다.
  • 그리고 중간에 리팩토링한다.
• 패키지와 모듈의 차이
  • 패키지 = 묶으려는 행위
  • 모듈 = 독립적으로 쪼개서 재활용에 초점