제작기에 들어갈 내용들 - 3jins/blog-renewal GitHub Wiki

삽질기

• 내 실수로 인한 쓸데없는 삽질을 제외하고는 들어갈 듯.
• 다만 블로그 제작기 시리즈가 아니라 별개의 내용으로 들어가는 게 깔끔하지 않을까 함.

retry

• app/index.ts & config & test
• TransactionUtils.ts & config & test
• 회사에서의 CDB 운영경험이랑 엮어서 쓰면 좋을 듯?

규식이

• 테스트 커버리지 100%랑 엮어서 가면 좋을 것 같음. 필드 다 테스트하는 노가다를 어떻게 처리할 것인가에 대해서.
• 제작기에는 테스트 커버리지 100% 내용을 넣고, 거기서 링크로 규식이 글을 참조시키자. 그러려면 규식이 글을 미리 써놔야겠지..

테스트 커버리지 100%

• 좋은 점
  • 기능 수정시 사이드이펙이 없다는 확신을 가질 수 있음. 특히 라이브러리 버전 올릴 때 개꿀.
  • 기능 수정시 실험을 하기가 편함. 이미 테스트코드가 다 있으니 살짝 수정해서 확인해보고 진행 가능.
  • 오타나 누락과 같은 사소한 실수를 봉쇄할 수 있음.
• 한계
  • 컨트롤러 쪽은 아무리 테스트를 잘 짜봤자 한계가 있음. HTTP 스펙과 자신이 쓰는 서버 어플리케이션의 HTTP 모듈을 완벽히 아는 게 아니라면 통합테스트 필수. ex) FormData에 배열 넣는 방법, Koa의 비동기 API 응답 방식, jackson이 지 멋대로 수정해버리는 필드들, ...
  • 절대 커버할 수 없는 부분이 있는데(배포환경별로 분기되는 부분, 외부 라이브러리의 동작을 예측할 수 없을 때, stackTrace 등), 이 부분을 커버리지에서 제외해두면 맹점이 될 수 있음.

추상화

• 추상화의 목적: 확장에 유연한 구조를 가져가기 위함(OCP).
• 그렇다면 확장될 일이 없는 경우에는 추상화가 꼭 필요한가
  • ex1) 레이어 아키텍쳐에서 굳이 Service 인터페이스 만들고 ServiceImpl 하나씩 만들어 쓰는 경우. 절대 2개가 될 일이 없는데 굳이...?
  • ex2) 확장될 수도 있기는 하지만 현재 확장할 계획이 전혀 없는 경우. 예를 들어 로깅 라이브러리 하나를 쓰고 있는데 2개 이상 섞어 쓸 계획이 없을 때 선제적으로 대응해야 하나?
    • PSA 같은 구조로 래핑해서 쓰는 방법이 있기는 함: https://www.youtube.com/watch?v=bJfbPWEMj_c
• 어디까지 추상화를 해야 하는가 - 상황에 맞게 적절한 수준까지만 추상화하는 것이 과연 정답인가