코드를 구현하기 전에 해야 할 일

by


패스트캠퍼스 레드강의 중

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

개발 전 고려해야 할 사항을 수업 시간에 배웠고 잊지 않고 구현하기 위해 다음과 같이 정리했습니다.

'추천 관련글,

개발 설계 문서 작성 후 구현

  • 개발을 시작하기 전에 개발 설계 문서동료와 공유 생성 및 추천
  • 서비스 구현의 목표, 디자인, 제약 등을 미리 생각한 후 개발 시작
    • 많은 실험 없이 원하는 구현을 진행할 수 있습니다.
  • 개발 설계 문서작성한 후 동료와 함께 검토하면 더 나은 디자인과 정렬을 얻을 수 있습니다.
  • 코드와 함께 서비스를 수락할 때 개발 설계 문서인계받는 동료가 해당 서비스의 구조를 비교적 빠르게 처리할 수 있습니다.

개발 설계 문서 작성 양식(29cm)

  1. 문제 정의
    • 배경: 현재 문제는 무엇이며 개발을 통해 어떻게 해결합니까?
    • 전제 조건: 개발된 시스템의 성공 조건은 무엇입니까?
    • 목표
    • 목표가 아니라
    • 평가: 이 시스템의 성공과 실패를 어떻게 평가하십니까?
  2. 솔루션
    • 디자인: 다이어그램은 필수입니다
    • 구현: 기술 스택
    • 시험
    • 코드 검토
    • 모니터링
    • 보안
  3. 분배 계획
    • 계획: 어떤 사용자, 어떤 기능을 단계별로
    • 배포: 배포 방법
  4. 타임라인
    • 로드맵: 단계별 이정표

테이블을 먼저 설계하지 말고 핵심 도메인을 먼저 파생시키십시오.

  • 요구사항과 경계조건을 확인한 후 적합한 코어 도메인을 도출하고 최종적으로 테이블을 설계
  • 핵심은 객체 자체, 객체 간의 메시지, 메시지에 의해 구현되는 기능을 모델링하는 데 중점을 두어야 합니다.

변수 이름과 메서드 이름에 특히 주의하십시오.

  • 보통 코드 구현 : 코드 리딩 = 2 : 8의 비율이므로 네이밍에 더욱 주의를 기울여야 합니다.
  • 일반적으로 사용되는 이름을 사용하십시오.
    • 개발자가 아닌 사람이 보더라도 변수나 메서드 이름이 어떤 역할을 하는지 알 수 있습니다.

API 사양에서 요청 및 응답 속성은 필수 값으로만 ​​유지됩니다.

  • 또한 단일 책임 원칙을 지지하는 방법이기도 합니다.

세터는 사용하지 않거나 최소한만 사용해야 합니다.

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

Transaction의 사용과 범위 설정은 많은 고민 끝에 결정됩니다.

  • 트랜잭션은 도메인 데이터의 일관성을 위한 필수 기능입니다.
  • 다만 서비스의 종류에 따라 거래의 범위를 적절히 정하는 것이 중요하다.
  • 트랜잭션의 크기는 가능한 한 작게 유지하는 것이 좋습니다.
  • 외부 타사 서비스를 호출하는 논리가 있는 경우 적절한 제한 시간을 설정해야 합니다.
    • 필요한 경우 트랜잭션에 포함하지 않는 것이 좋습니다.

도메인 객체가 반드시 DB에 저장되는 것은 아닙니다.

불필요한 try~catch 피하기

  • 간이 포장 try ~ catch의 경우 코드의 줄만 늘어날 뿐 의미는 없다.
  • 의미 있는(보상 거래 등) 오류를 잡을 때만 사용하는 것을 권장합니다.

필요한 상태만 선언

  • 실생활에서 정의할 수 있는 상태를 모두 선언할 필요는 없으며 필요한 상태만 정의하면 됩니다.
  • 너무 상세한 상태 값의 분류는 도메인을 이해하기 어렵고 코드 구현에서 고려해야 할 사항이 많습니다. 메인 로직 테스트 코드는 자신을 저장하는 방법입니다
  • 개발 과정에서 요구 사항이 자주 변경되고 추가되기 때문에 테스트 코드가 실행되는 동안 피드백을 받으면 신속하게 문제를 해결하고 기능을 구현할 수 있습니다.

먼저 목적 함수를 구현하여 작동하게 한 다음 작은 함수로 변환합니다.

  • 더럽지만 작동하는 코드는 깨끗하지만 작동하지 않는 코드보다 백배 낫습니다.
  • 작동하는 구현을 먼저 완료한 다음 리팩토링하는 것이 좋습니다.
    • 속도는 코드 구현과 비즈니스 모두에 중요합니다.

무조건 시행할 필요는 없습니다.

  • 적시에 기능을 출시하는 것이 정말 중요합니다.
  • 균형을 유지하는 것이 중요합니다(trade-off).
    • 비즈니스 가치를 추가하려면 하드코딩도 필요합니다.
    • 비즈니스 가치를 계속 창출하려면 코드와 프로젝트 구조를 깨끗하게 유지하는 것도 중요합니다.

강의를 들으면서 느낀점 어? 이거 회사에서 하는 내용이랑 같네?느낀 점이 많았습니다.

첫 번째는 세터를 피하는 것입니다. 회사 코드 관례상 setter를 사용하면 에러 발생 부위를 찾기 어렵고 유지보수가 더 어려워집니다. 또한 setter를 과도하게 사용하면 객체 간의 종속성이 증가하고 결합도가 낮아 객체 지향을 위반하기 쉽기 때문에 이를 피해야 하는 이유가 있습니다.

두 번째는 API 요청 및 응답을 최적화하는 것입니다. 웹 개발을 배우기 전에 이전 회사에서 OpenAPI를 사용하면서 느꼈습니다. 이 API에 이런 Response가 있어도 무방한가?나는 생각했다. 그래서 본격적으로 웹 개발을 배우며 프로젝트를 진행하는 동안 Request와 Response는 최대한 제한적으로 쓰려고 노력했습니다.

그런데 미처 생각하지 못한 것은 boolean을 요청으로 던지고, Service Logic에서 해당 boolean으로 분기하는 과정을 제한하고, 의미가 명확한 두 개의 메소드로 분리하는 것이 낫다는 것입니다. 이 문장을 듣고 내 생각 그러면 각 상태에 대한 API를 각각 나누어 총 2개의 API를 만들게 되는 것이니 더 비효율적이지 않은가?나는 그것에 대해 생각하기 위해 왔습니다.

단일 책임의 원칙을 지키기 위해 각각의 메소드를 분리하는 방법은 알고 있지만 강의에서 API 분리의 이점에 대해 더 많이 배울 필요가 있을 것 같습니다.

셋째, 네이밍과 관련된다. 내 솔로 프로젝트에서 변수 이름을 무작위로 지정했습니다. 그러다가 입사 후 네이밍은 앞으로 코드를 받아들이는 것이 나뿐만 아니라 직원 등 코드를 접하는 사람들에게도 얼마나 중요한 일인지 깨닫게 해주었다. B. 코드를 검토하는 동료, 앞으로 협업할 공동 작업자, 앞으로 나 없이 코드를 볼 공동 작업자.

그 외의 내용은 대부분 새로운 인사이트를 얻을 수 있는 내용이었고 다음 강의를 통해 좀 더 알아보고자 합니다.

위는 Fastcampus의 Red Lecture에서 가져온 것입니다.
The RED: 비즈니스 성공을 위한 Java/Spring 기반 서비스 개발 및 MSA 구현 by 이희창
참고 자료입니다.