달력 기반 일정관리 SPA 웹 서비스 chanlendar를 만들고 있다.

0.1.0 이 저번주 목요일날 개발완료 됐고 늘 그랬듯이 회고를 해본다.

회고

현재 회고의 목적

개발기간동안 잘 된 점, 아쉬운 점 , 후기를 작성해 서비스를 바로 잡고, 발전시키기 위함

회고 방법

1. 프로젝트 시작부터 0.1.0 개발 완료까지, 날마다 작성된 개발 일지를 기반으로 좋았던 점과 아쉬운 점을 나눔
2. 이 아이템들을 KPT를 통해 다음 개발때 적용할 것들을 정함.

좋았던 점

1. 현재 버전에 만들 기능 전부 적은 것
2. 데드라인 정의한 것
3. 개발할 때마다 일지를 작성한 것

가져갈 것

1. 버전에 만들 기능 명시 (눈에 보이는 목표 수립)
2. 일정 수립
3. 하루치 개발이 끝나면 개발 일지 작성

아쉬운 점

1. 백엔드로 cloudflare workers 사용하기로 했는데 일정때문에 못한 것
   1. 더 정확한 원인은 번들링 스크립트를 작성해줘야됨
   2. 만약에 파이어베이스를 쓰지 않고 백엔드를 개발할 것이라면 아예 스프링이나 익스프레스같은 걸 쓰고 서버환경도 차라리 내가 세팅하는게 낫다. 공부한다는 마인드로.
2. 파이어베이스 보안 Rule 적용 못 시킨 것
3. API ↔ 데이터 트랜스폼 ↔ 데이터 스토어 ↔ 데이터 사용자를 레이어별로 못 나눠 놓은 것
   1. 현재는 API ↔ 데이터 스토어(& 트랜스폼) ↔ 데이터 사용자(훅스 & 컴포넌트)이다.
4. 모달, 컨텍스트 메뉴, 인풋을 추상화했지만, 편안하게 사용할 수 있도록, 한번 더 추상화시키지 못한 것
   1. 지금은 적당히 편하긴 하지만 뇌를 빼고 쓸 수 있을 정도로 편하지 않음
   2. (a의 이유와 같은 맥락으로) 여전히 중복이 있음
5. CSS와 스타일링 컴포넌트 추상화 못한 것
   1. flex, width, height 관련 css 및 컴포넌트 추상화 필요
6. 테스트코드 부재

시도할 것

1. 파이어베이스 보안 적용
2. 컴포넌트와 스타일 추상화
   1. 모달, 컨텍스트 메뉴, 인풋
   2. 자주 사용하는 Flex, Grid
3. 테스트 코드
   1. 적어도 E2E는 짜야한다.

작성해보니 아쉬운 점은 내가 잘 몰랐고, 일정때문에 잘 못했던 점이었다.

그리고 내가 잘 알았더라면 해결될 문제들이었다. 그렇기 때문에 지금 당장 문제를 해결한다면 다음부터는 이 문제들이 안 나오리라 본다.

깨달은 점

코드를 짜다가 이상한 방향으로 구현을 해야되면 구조를 바꿔야 되는 신호이다.

나 같은 경우, 달력의 한 타입을 여러파일에서 각자 정의,

그에 따른 재미난 프롭스 드릴링,

애매한 컴포넌트 분리,

이랬다가 저랬다가 하는 스타일링 로직

개인적으로 생각하는 안 좋은 코드는 한 파일의 코드를 읽기 위해 다른 파일의 코드를 읽어야 되는 코드다.

도메인에 맞는 네이밍, 스펙을 가져야 되고, 다른 파일의 내부 구현을 궁금하게 만들면 안된다.

단순하고, 직관적으로 라는 원칙을 명심하자

다음 스텝

다음 개발의 테마는 안전성 이다.

다다음 개발을 위한 안전, 내가 이 서비스를 사용할 수 있는 안전성을 확보하기 위함이 다음 개발의 목적이다.

1. 파이어베이스 보안 적용
2. 컴포넌트와 스타일 추상화
   1. 모달, 컨텍스트 메뉴, 인풋
   2. 자주 사용하는 Flex, Grid
3. 테스트 코드
   1. 적어도 E2E는 짜야한다.
   2. 지금 기능명세서는 예전에 작성해놔서, 시나리오에 대한 고민은 안해도 된다.

후기

이 외에도 하고 싶은 얘기가 많지만 따로 포스팅할 것이다.

다음 회고는 좋았던 점이 더 많을 것이다.

끊임없이 발전해갈 나와 내 서비스에게 건배를.

왜냐면 공부하는 사람은 포기하지 않으니까.