Loopers - 2 주차 : 설계

🧠 이번 주에 새로 배운 것

 

  이번주는 코드를 작성하기 앞서

 

  요구사항 명세서, 시퀀스 다이어그램, 클래스 다이어그램, ERD 를 어떤 관점과 고민을 가지고 해야하는지 배운거 같습니다.
  요구사항 명세서는 낙관적 케이스, 제약 케이스, 실패 케이스 로 나누어 작성했고 다이어그램과 ERD는 .md 파일의
  mermaid를 사용하여 작성했습니다.

---

💭 이런 고민이 있었어요

• 시퀀스 다이어그램을 그릴 때 가장 큰 고민은 "어디까지 표현해야 하는가" 였습니다.
  Repository 같은 DB 접근 계층까지 모두 그리자니 다이어그램이 너무 복잡해져서 핵심 흐름을 파악하기 어려웠습니다.
  반대로 너무 많이 생략하면, 중요한 정보를 누락한 부실한 설계처럼 보일까 봐 걱정이 되어
  '소통을 위한 명확성'과 '설계의 상세함' 사이에서 계속 고민했습니다.
  
• 클래스 다이어그램과 ERD 작성 시 비슷하면서 다른면에서 혼동이 자주 왔습니다.

 

---

💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트

 

• 코드를 짜기 전에 시퀀스 다이어그램으로 객체들의 책임을 먼저 할당해보는 습관을 들여야겠습니다.
  다이어그램이 복잡하게 그려진다면, 그건 코드 구조에 문제가 있다는 신호일 수 있다는 걸 명심하겠습니다.
• 새로운 기능을 설계할 때, 이 설계 문서를 누가 볼 것이고, 어떤 정보를 전달하고 싶은지 '목적'을 먼저 생각하면
  설계의 방향을 잡는 데 큰 도움이 될 것 같습니다.
• 여러 도메인이 얽힌 복잡한 로직은 Facade 객체를 두어 조율하는 방식을 설계로 통해서 보니 적극적으로 활용해봐야겠습니다.
  트랜잭션 관리도 훨씬 쉬워질 것 같습니다.

 

---

🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것

 

• 처음에는 '정답'을 찾으려고 하다 보니, 다이어그램의 상세 수준을 결정하는 데 생각보다 많은 시간을 썼습니다.
  조금 더 과감하게 목적에 맞춰 판단해도 좋았을 것 같습니다.
• 다음 주에는 실제 개발을 시작할 텐데, 이번에 설계한 대로 각 객체가 정말 책임을 잘 수행하는지,
  1주차때 해봤던 테스트 코드를 사용해 검증해보고 싶습니다.
  설계가 실제 코드와 얼마나 잘 들어맞는지, 혹은 다른 점은 무엇인지 비교하며 회고해볼 예정입니다.