01. 프로젝트 구조 및 설계

02. 권장하는 구현 방식

29CM에서 사용하고 있는 개발 디자인 문서 양식

1. 문제정의
   1. 배경 ( 현재 어떠한 상황이고 개발로써 어떻게 해결할 것인가? )
   2. 필수 조건 ( 개발한 시스템의 성공 조건이 무엇인가? )
   3. 목표
   4. 목표가 아닌 것
   5. 평가 ( 이 시스템의 성공과 실패를 어떻게 평가할 것인가? )
2. 해결 방안
   1. 설계 ( 다이어그램은 필수로 그려야 함 , Class Diagram, Sequence Diagram 등, 어떤 플로우로 어떻게 개발 할 건지 )
   2. 구현 ( Tech Stack )
   3. 테스트
   4. 코드리뷰
   5. 모니터링
   6. 보안 ( ISMS, DB Column 암호화, SSL, 등 )
3. 배포 계획
   1. 계획 ( 어떤 유저에게, 어떤 Feature를, 신규 기능일 시 점진적으로 )
   2. 배포 ( 어떻게 배포할 것인가? )
4. 타임 라인
   1. 로드맵 ( 단계별 마일스톤 )

전체적으로 개발을 시작하기 전에 개발 문서를 작성해 보고 동료들과 의견을 나누면 놓친 부분들을 잡을 수도 있다.

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

• 테이블은 도메인 객체를 영속화하기 위한 그릇 정도로 생각하는게 좋다.
  • ORM이 생기면서 테이블 중시믕로 코드를 구현하던 패러다임이 진정한 객체 중심의 개발로 전환될 수 있었다.
• 코딩을 하기 전에 먼저 해야할 것은
  • 우리가 개발해야 하는 주요 요구사항과 제약들을 감안하고
  • 핵심 도메인 객체를 도출하고
  • 특정 기능을 수행하기 위해 도메인 간에 주고 받아야 하는 메시지를 먼저 정의하는 것

변수명, 메서드명에 많은 신경을 쓰자

• 변수 명이나 메서드명을 읽었을 때, 그것이 뭇엇을 의미하는지 빠르게 이해할 수 있도로 네이밍을 하자!
• DDD에서 말하는 유비쿼터스 언어(Ubiquitous) 개념처럼 - 현업에서 사용하는 보편적인 언어를 최대한 반영하자
• 전사 표준, 또는 프로젝트 내에서의 네이밍 규칙을 세우고 운영하는 것도 좋다.
  • 슬랙에서 별도의 채널을 만들어 코드 네이밍을 위한 의견을 주고 받는 장치를 마련하는 것도 좋다
  • 29CM에서는 별도의 채널을 만들고 코드 네이밍에 대한 다양한 리뷰를 주고 받고 있다.

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

• API를 설계할 때에넌 없어도 되는 request는 제거하고, 외부에 리턴하는 response도 최소한을 유지하도록 노력하자.
• 요구하는 request가 많다는 것은 해당 메서드나 객체에서 처리해야 하는 로직이 많다는 것을 의미한다.
  • 이는 해당 객체가 생각보다 많은 역할을 하고 있다는 신호일 수 있다.
• response의 경우도 API 목적에 맞지 않는 불필요한 응답을 포함하여 제공하고 있고, 이를 가져다 쓰는 외부 로직이 있다면 추후 해당 response 에서 특정 프로퍼티는 제거하기 어렵게 될 수 있다.