코드 구현을 하기 전에 해야할 것

Fastcampus의 The Red 강의 중

The RED : 비즈니스 성공을 위한 Java/Spring 기반 서비스 개발과 MSA 구축 by 이희창

수업을 들으며 개발을 하기 전에 고려해야 할 사항들에 대해 배웠고 이를 잊어버리지 않고 체화하기 위해 다음과 같이 정리하였다.

---

개발 디자인 문서르 작성한 후 구현

• 개발을 시작하기 전에 개발 디자인 문서를 작성하고 동료와 공유를 권장
• 서비스 구현에 대한 목표와 설계, 제약 사항 등을 미리 생각해 본 후에 개발을 시작
  • 큰 시행착오 없이 원하는 구현을 진행할 수 있음
• 개발 디자인 문서를 작성한 후에 이를 동료와 리뷰하는 과정을 거치면, 좀 더 좋은 디자인과 방향성을 잡을 수 있다.
• 서비스의 인수인계 과정에서도 코드와 함께 개발 디자인 문서를 전달한다면, 넘겨받는 동료가 해당 서비스에 대한 구조 파악을 비교적 빠르게 진행할 수 있다.

개발 디자인 문서 작성 양식(29cm)

1. 문제 정의
   • 배경 : 현재 어떠한 사오항이고 개발로써 어떻게 해결할 것인가?
   • 필수 조건 : 개발한 시스템의 성공 조건이 무엇인가?
   • 목표
   • 목표가 아닌 것
   • 평가 : 이 시스템의 성공과 실패를 어떻게 평가할 것인가?
2. 해결 방안
   • 설계 : 다이어그램은 필수
   • 구현 : Tech Stack
   • 테스트
   • 코드리뷰
   • 모니터링
   • 보안
3. 배포계획
   • 계획 : 어떤 유저에게, 어떤 feature를, 단계적으로
   • 배포 : 어떻게 배포할 것인가
4. 타임라인
   • 로드맵 : 단계별 마일스톤

테이블 먼저 설계하지 말고, 핵심 도메인을 먼저 도출

• 요구사항과 제약사항 확인 후, 그에 맞는 핵심 도메인 도출, 최종적으로 테이블 설계
• 객체 자체에 대한 모델링과, 객체간의 메시지, 메시지를 통해 구현되는 기능에 핵심을 두어야 한다.

변수명, 메서드명에 많은 신경을 써야한다.

• 통상적으로 코드 구현 : 코드 리딩 = 2 : 8의 비율이기 때문에 네이밍에 더 많은 신경을 써야 한다.
• 보편적으로 사용되는 네이밍을 사용한다.
  • 비개발자가 본다 하여도 어떠한 역할을 하는 변수 또는 메서드명인지 알 수 있도록

API 명세에서 Request와 Response의 프로퍼티는 필수값만 유지되도록

• 단일책임원칙을 유지하기 위한 방법이기도 함

Setter는 쓰지 않거나, 최소화 사용해야 한다.

• setter는 캡슐화된 도메인과 객체를 깨뜨리는 주범

Transaction의 사용과 범위 설정은 여러 번 고민 후 결정

• Transaction은 도메인의 데이터 정합성을 위한 필수 기능
• 다만, 서비스 성격에 따라 Transaction의 범위를 적절히 잡는 것이 중요
• Transaction의 범위는 최대한 작게 잡는것이 좋다.
• 외부 3rd party 서비스를 호출하는 로직이 있다면 적절한 타임아웃 설정은 필수
  • 필요에 따라서는 Transaction내에 포함시키지 않는 것도 고려

도메인 객체가 무조건 DB에 저장되는 것은 아님

불필요한 try ~ catch는 지양

• 단순 Wrapping을 하는 try ~ catch의 경우 코드라인을 증가시킬 뿐 의미 없는 구문
• 의미 있는(보상 트랜젝션 등) error catch를 사용할 경우만 사용하도록 권장

꼭 필요한 상태(Status)만 선언

• 실제 생활에 정의될 수 있는 모든 상태를 선언할 필요 없이, 꼭 필요한 상태만 정의해도 충분하다.
• 너무 세분화된 상태값 구분은 해당 도메인을 이해하기 어렵게 만들고 코드 구현에서도 고려할 것이 많아진다. 주요 로직 테스트 코드는 본인을 살리는 길
• 개발 과정 중 요구사항은 수시로 변경되고 추가되기 때문에 테스트 코드를 실행하며 피드백을 받는다면, 버그픽스도 쉽고 기능의 구현도 빠르게 진행할 수 있다.

우선 목표한 기능이 동작하게끔 구현한 후 작게 리팩토링

• 깔끔한데 동작 안 하는 코드보다 더럽지만 동작하는 코드가 백번 낫다.
• 우선적으로 동작할 수 있는 구현을 완성한 후 리팩토링 하는 것이 더 좋다.
  • 코드 구현과 비즈니스는 둘 다 속도가 중요하다.

무조건 정석대로 구현할 필요는 없다.

• 약속한 시점에 기능을 런칭하는 것은 정말 중요하다.
• 균현의 유지가 중요하다.(Trade-off)
  • 비즈니스의 가치를 만들어 내기 위한 하드코딩도 필요
  • 비즈니스 가치를 지속적으로 제공하기 위해 코드와 프로젝트 구조를 깔끔하게 유지하는 것도 중요

---

    강의를 들으면서 문득 든 느낌은 어? 이거 회사에서 하는 내용이랑 같네?라고 느낀 점이 많았다.

첫 번째로 Setter의 지양이다. 회사 코드 컨벤션으로 setter를 사용할 경우 에러 발생 지역을 찾아가기 어렵고 유지보수를 어렵게 한다고 지양하고 있다. 또한 setter를 남발할 경우 객체 간의 의존성이 높아지고 결합도는 떨어지는 객체지향을 위반하기 쉽기 때문에 지양하는 이유도 있다.

    두 번째로 API의 Request와 Response의 최적화다. 이는 웹 개발을 배우기 전, 전 회사에서 OpenAPI를 사용하는 과정에서도 느꼈는데 이 API에 이런 Response가 있어도 무방한가?라는 생각을 가진 적이 있다. 그래서 본격적으로 웹 개발을 배우고 프로젝트를 진행하면서도 가능한 제한적으로 Request와 Response를 작성하도록 노력하였다.

 

    그러나 내가 생각하지 못했던 부분으로는 Boolean타입을 Request로 던지고, Service Logic에서 해당 Boolean 값으로 분기처리하는 과정도 제한하고 명확한 의미를 가지는 2개의 메서드로 분리하는 것이 좋다고 한다. 이 구문을 듣고 나서 든 생각은 그러면 각 상태에 대한 API를 각각 나누어 총 2개의 API를 만들게 되는 것이니 더 비효율적이지 않은가?라는 생각을 하게 되었다.

 

    단일책임원칙을 지키기 위함으로 각 메서드를 분리하는 것은 알겠으나 API를 분리하여 만드는 것에 어떤 이점이 있을지는 강의를 통해 더 배워보아야 할 것 같다.

    세 번째로 네이밍 관련이다. 혼자 하는 프로젝트에서는 변수명을 정말 아무렇게나 지었다. 그러다가 회사 입사 후 네이밍을 하는 것은 미래의 나뿐만이 아닌 코드리뷰를 해주는 동료, 미래에 함께 일하게 될 동료, 내가 없는 미래에 코드를 보게 될 동료 등 그 코드를 접하는 사람들이 받아들이는 것에 있어 중요성을 깨닫게 되었다.

 

    그 외의 대부분의 내용은 새로운 인사이트를 받을 수 있는 내용들이었고 어서 다음 강의를 통해 더 많은 것을 알고 싶다.

 

위 내용은 Fastcampus의 The Red 강의 중
The RED : 비즈니스 성공을 위한 Java/Spring 기반 서비스 개발과 MSA 구축 by 이희창
을 참고하여 작성한 자료입니다.