[Coding Standard] 일머리: 정확도와 빠름을 어떤 비율로 섞는가
지금까지 표준은 전부 무엇을 만드는가에 대한 것이었다. 패키지를 어떻게 나누고, DTO를 어떻게 만들고, 계약을 어떻게 적는지. 그런데 그 표준들을 어떤 태도로 실행하는가는 어디에도 없었다.
최근 포스트
[Coding Standard] 테스트 냄새 어휘: 아픈 곳을 뭐라고 부를 것인가
테스트가 왜 힘든지를 진단하면서 통증을 넷으로 적었다.
[Coding Standard] 접미사 패키지 분할: 어느 계층을 나누고 어느 계층은 두는가
패키지 구조 표준은 도메인 안을 api·application·domain·infra 네 겹으로 나눴다. 컨트롤러 패키지 분리 표준이 거기에 web을 형제로 붙였다. 그 겹 안을 더 나눌지는 어느 쪽도 정하지 않았다.
[Coding Standard] 테스트 층위 선택: 스텁이 통과시킨 것들
계약 커버리지 게이트 표준을 만들면서 유예 여덟 건을 남겼다. 계약은 적어뒀는데 테스트를 못 짜는 칸들이었고, 이유는 이랬다.
[Coding Standard] 라우트-계약 정합성: 계약표가 실제 API와 맞다고 누가 보장하는가
API 테스트 계약표 표준이 계약을 저장소의 enum이 소유하게 만들었다. @Contract 애노테이션 덕에 없는 계약을 가리키는 테스트는 컴파일이 막고, TestExecutionListener가 계약과 테스트 실행 결과를 맞춰 색을 칠한다.