이번 주부터 Spring 입문을 마치고 팀 별로 뉴스피드라는 공통 기능에 주제를 다르게 해서 개발하게 됐다. 우리 조는 기획부터 너무 많은 시간을 뺏기기보다는 뉴스피드라는 기능 자체는 같으니 세부적인 디테일과 이유만 조금 고려하고 빨리 진행하기로 했다.
이벤트 스토밍
DDD 기반 설계를 할 때 화이트보드에 진행한다는 포스트잇 붙이기부터 Miro 서비스를 통해 진행했다.
그런데 진짜 DDD처럼 한 건 아니고 아주 기본적인 커맨드, 이벤트, 정책만 고려했고 색깔도 맞춘 건 아니다. 프로젝트 기간이 그렇게 긴 게 아니고 구체적으로 PM처럼 스토밍부터 갈피를 잡아주기엔 다 같이 미숙한지라 최대한 의견을 공유해가며 붙인 것이다.
그래도 이후에 API 명세, ERD 클라우드에 많이 참고가 돼서 포스트잇 이벤트 스토밍은 꽤 도움이 됐다고 생각한다.
컨벤션 정하기
본격적인 이벤트 스토밍을 끝나고 API, ERD 설계부터는 convention이 필요하다고 생각해서 컨벤션을 먼저 정하기로 했다.
우선 네이밍 컨벤션으로 일반적으로 사용한다고 알려진 것 위주로 설정했는데 다들 의견을 조금 내주긴 하셨지만 내가 주로 말을 해서 그런지 대부분은 내가 적던대로 스타일이 된 것 같다. 물론 기존에도 나름 이유나 레퍼런스를 참고해서 만들긴 했다.
네이밍, 깃 컨벤션을 처음부터 정하려고 하니 생각보다 생각해야할 점이 많아서 놀랬고 시간도 꽤 많이 쓰게 됐다. 실무에서도 혼자서만 규칙을 정했던게 여기서는 조금 도움이 된 것 같다.
API 명세서 작성하기
이전에 해오던 대로 Notion 페이지로 API 명세서를 다 같이 작성했다. 도메인별로 나눠서 작성하니 생각보다 금방이었고 URI에 대한 convention만 잘 체크하고 실제로 필요한지 아닌지를 정책도 따져보며 비교했더니 꽤 금방 끝나는 작업이 됐다. 앞서 처리한 일들이 도움이 되는 일이었다.
다만 이후 ERD Cloud를 짜면서 실제로 이러면 안될 것 같은 부분들은 조정이 들어갔다. 가능하면 변경 없는 명세서였으면 좋았겠지만 가장 쉽게 변경이 들어가는 건 어쩔 수 없나보다.
ERD Cloud 작성하기
ERD는 생각보다 고민할 부분이나 실제 테이블 구조가 어떻게 짜여야 할지 고민이었다. 예를 들면 코멘트에 좋아요, 싫어요를 저장하는 방법등이 문제였다.
이걸 불러오는 방식, 저장하는 방식은 구현 방식에 따라 다양해질 수 있으니 우리는 그 중에서 하나 골라와서 적용해보기로 했고 필수 구현도 제대로 못챙기느라 진행도 못할 수도 있지만 최대한 미래까지 지켜보게 됐다.
Entity를 작성하다가도 조금 애매한 부분등에서 명세 변경이 일어나고 있고 이 역시 쉽지만은 않은 느낌이다.
PR/이슈로 프로젝트 진척도 체크하기
내일배움캠프의 노션에서 사용자 정보를 확실히 체크할 수가 없어서 Github Organization을 만들어서 Repository를 만들고 이슈/PR로 흐름을 따라 진척도를 체크하고 완성해나가기로 했다.
여기서도 나도 그렇고 미숙함이 돋보이는 지라 코드의 작성 문제보다 더 골치아프기도 했지만 핵심인 리뷰와 진척도를 중점적으로 진행해나가기로 했다.
특히 소통이 중요해진만큼 PR의 리뷰 / Dev branch에서 땡겨가기등 작지만 귀한 규칙을 만들어 나가기로 했다.
챌린지반 - 클린 코드
정말 다행히도 기초 설계부분은 좀 디자인같은 건 날림이긴 하지만 팀원과의 협의와 이해를 충분히 거치고 이슈를 작성하기 시작해서 챌린지반 강의도 무사히 집중할 수 있었다.
특히 오늘 진행하는 클린 코드는 누군가 내 앱 코드를 봐준다면... 이라고 생각하며 작성하던 시절부터 아키텍쳐는 잘 못해도 클린 코드를 어떻게든 준수하게 지켜보고자 고생했던 시절의 기억이 녹아있어 더 재밌게 들을 수 있었다.
- 사람의 기억을 믿지 말자. 맥락의 크기가 커질 수록 휴먼 에러의 위험은 커진다.
- 도메인 지식에 의존하는 코드는 다른 사람, 미래의 내가 읽어도 어렵게 느껴진다.
- 나중에 사용할 변수를 미리 뭉쳐서 선언하지 말고 가변이면 더욱 주의해야 한다.
- Scope function 으로 Scope를 줄여서 IDE의 도움을 받고 변수의 선언을 줄이자
- 단일 메소드의 크기가 커지면 의심부터 시작하자
- 위에서 아래로 설명하듯, 예상대로 흘러가는 코드가 잘 읽힌다
- 그렇다고 scope function을 과하게 사용하면 scope가 중첩되며 깊은 코드가 된다.
- 적절한 추상화와 위임은 코드를 설명하기 쉬워진다.
- 적잘한 추상화는 주석을 달지 않아도 메소드명 그 자체가 설명이 될 수 있다.
- 로직의 흐름을 한글로 작성했을 때 코드와 매칭이 되는 부분을 늘리고 흐름과 상관 없는 코드가 많을 수록 별로다.
- 비즈니스 로직을 담고 있는 Application service에서 더욱 흐름을 읽어야 해서 중요하고 세부적인 내용은 도메인 로직을 처리하는 Domain service가 배정받는다.
- 관심사의 분리는 기억하기 힘든 큰 서비스가 작은 단위로 분리되며 잘 생각할 수 있게 도와준다.
- 관심사는 사람이 기억해야 하는 Context의 범위임을 명심하자. 크면 커질 수록 어려워진다.
- Client 객체를 먼저 작성하면 관심사의 분리를 적용하기 쉬워진다. 인터페이스를 의존하게 하고 구현체를 나중으로 미루면 자연스럽게 그렇게 된다.
- 문맥을 혼란스럽게 만드는 nullable은 지양하는게 제일 좋고, 쓴다면 문맥을 최대한 제공하는게 좋다.
- 10 을 더한다 같은 매직넘버는 상수로 지정해서 의미를 추가해주자.
- 생성자 오버로딩은 같은 이름에 다른 맥락을 제공하니 정적 팩토리 메소드로 static하게 만들어 표현하자. (.of, .ok 처럼 의미를 가짐이 좋다)
코드카타는 오전부터 뉴스피드에 대한 기초 조사때문에 시간을 쓰느라 진행하지 못했다. 그런데 프로젝트 기간동안 내내 이럴 까봐 좀 걱정되는데 템포를 잘 조절해야겠다. 절대적인 공부 시간이 항상 그만한 퍼포먼스를 보장해주는 건 아니라고 생각한다.
