2022년 8월 프로젝트 되돌아 보기

💡 프로젝트를 진행하면서 아쉽거나 개선해야 될 부분을 뭉뚱그려 덮어 놓는 것보다 다 각도에서 재조명하고 다음엔 더 나은 방향으로 프로젝트를 진행하고 싶기에 작성해 봅니다. 또 다른 관점과 자신이 느낀 것을 공유해 주신다면 의미 있는 자료가 생기지 않을까!!라는 기대감이 있네요😅

 

소통채널

1. 이번 계기로 분리된 소통채널은 프로젝트 진행의 절대 악이라 생각하게 됨.
   • 초기 기획, 디자이너, 클라이언트 매니저, 내부 PM의 히스토리를 알 기 힘들었고 가끔 전달사항이 카더라 통신으로 들릴때가 있음
   • 카카오톡 채팅방 보다 슬랙을 이용(카카오톡은 채팅방 참여 시점 이후로 메세지 확인이 가능해서 과거 내용 확인 불가, 업무와 일상을 분리할 수 있음)

시작 전

1. 프로젝트 시작 전 기획, 운영, 개발을 아울러서 생각할 수 있는 시간이 부족했음
   • 기획서나 요구사항 체크도 없이 무작정 디자인만 보고 코드를 작성함
   • 기존 운영중인 서비스 앱이 있었음에도 불구하고 참고하지 않음 ⇒ 프로젝트 이해도 낮은 상태로 작업
2. 공통 요구 사항 및 공통 디자인 분석이 미미했음
   • api 요청 완료&실패 시 alert 또는 toast 형태, 가이드 문구 정립이 안된 상태에서 프로젝트를 시작해서 결과적으로 같은 코드를 2번 이상 보게 됨
   • 공통적으로 쓰는 레이아웃들을 정립하고 관련 코드를 자동화했다면 레이아웃을 수정하는데 시간을 덜 쓰지 않았을까? ex) input 클릭 시 keyboardSpace의 위치, 전체 확인 버튼의 위치, keyBoard 활성화 시 터치 작동 방식

⇒ 기획과 디자인이 어느 정도 완성됐다는 판단이 섰을 때 함께 모여 3시간 정도만 회의하기 또는 가볍게? 티타임을 가지면서 프로젝트를 분석했으면 좋았을텐데.. 

⇒ 기획과 디자인이 개발 중에도 계속 변경 되었었는데 빠르게 버전관리와 스냅샷 찍고 변경된 부분은 추후 적용 했더라면 확실히 선을 그을 수 있었는데 이런 경험이 처음이라 초반에 많이 휘둘렸던거 같음

진행 중

1. 애매모호한 코드 리뷰?
   • 리팩터링이 자동적으로 이뤄지지 않음
   • 코드에 대한 조언이 없음, 규칙성이 생기지 않고 컨벤션이 무너지기 쉬움
   ⇒ 주기적으로 실무자들끼리 코드 볼 시간이 필요, 브랜치 pr 도입 고려해 보기, 올바른 리뷰 문화
2. 업무향상 팁 또는 해결방안 공유가 휘발성으로 전달됨
   • 휘발성으로 공유된 것들
     • 나만 알고 쓰는 IDE 단축키, IDE 커스텀 방법
     • git ssh 관리 및 소스트리 환경 설정 방법
     • saga takeLatest 단점 및 장점
     • flatList 최적화 방법
     • bootSplash 적용 방법 및 마이그레이션 현황
     • 플랫폼마다 간편 로그인 적용 방법
     • 타입스크립트 적용 팁
   ⇒전용 슬랙 채널이나 노션 페이지가 있다면 팀에 귀중한 자산이 되지 않을까?
3. 테스트에 대한 압박감
   • 테스트폭이 좁다 보니 코드에 대한 관찰이 부족하거나. 예상되는 문제가 있어도 낙관론적으로 지나치는 경향이 있음 ⇒ 경험이 쌓이다 보면 자연스럽게 될 거다라는 말은 무책임함. ⇒ 의도적으로 훈련되어야 할 부분이라 생각함.
   • 구현한 로직의 테스트 히스토리를 볼 수 없고 결과만 남겨진 코드
   • 버그 발생 시 역추적만이 답. 뎁스가 깊어질수록 소모시간이 늘어남
   • 테스트 툴을 도입하고 싶어도 실제 프로젝트에 엉켜있는 redux, api, auth, 외부 모듈들의 의존성 크기에 압도되어 시작도 하기 전에 포기함
   • 테스트가 중요한 것은 알지만 테스트하는 방법을 모름
   ⇒ 모든 곳을 테스트화 하는 것보다 인증, 회원가입, 결제 등 핵심 로직부터 시작해 본다면?

프로젝트 구조 또는 코드 구조

1. 리스트에서 상세페이지로 이동할 때의 코드 구조가 다양함
   • 리스트에 담긴 데이터를 그대로 파람값으로 넘겨주는 상세페이지
   • 파람값으로 idx만 보낸 후 상세페이지에서 디테일 api를 호출해 정보를 가져오는 상세페이지
   • 사가에서 api를 먼저 받은 후 상세페이지로 이동

⇒ 개인적으로 2번째 방법이 좋다 생각함. 딥링크를 적용하기 쉽고, api호출이 사가에 의존되지 않아 페이지를 독립적으로 다룰 수 있음

1. 타입스크립트 관리
   • 중복된 타입 제거 (TypeYN 등)
   • initialState.ts에 init과 type이 공존하고 있음 분리필요!
   • 사용 목적에 맞는 타입스크립트 위치 및 네이밍 컨벤션을 팀원들과 조율해야 됨 (props을 다루는 Type, api에서 반환되는 타입)
   • api 데이터 반환 구조에 맞춰 자동으로 타입이 생성되는 모듈이 있는지 조사 generator-openapi
2. reudx에 비동기 통신 분리 검토 해보기 (React Query, RTKQ 등)

배포 전

1. 업무 종료 1시간 이내에 하루 동안 작업한 코드병합은 시간적 압박감이 커져서 실수가 많이 나옴

자신에게 아쉬운 점

1. 프로젝트 품질에 대해 신경을 덜 씀
   • 테스트를 프로그래머 관점에서만 진행함
   • U I/UX가 불명확할 때 순수한 상태로 두고 테스터들에게 책임을 전가함 ⇒ 시작 전 공통 요구 사항 및 공통 디자인 분석하기, 반복적으로 기획 및 디자인 체크
2. 문제가 발생하면 기획, 디자인, 개발 중 어떤 것으로 풀어야 하는지 모르거나 잘못된 방식으로 풀려는 경향이 있었음
   • ex) 텍스트 입력 할 때 글자 수 초과 시 깜빡거린다는 현상을 제기했을 때 기획적으로 푸는 것이 옳다 생각했고 의미 없이 많은 스레드를 남김. 생각해 보면 maxLength 속성을 넣으면 간단하게 해결되는 거였는데..
   • ⇒ 경험이 쌓이면 나아지지 않을까 기대 중
3. 급해지면 팀과 합의해서 세운 규칙을 무시함
   • 주말에 작업할 때 브랜치 커밋 시 컨벤션을 무시함
   • url을 Config에 전역화 처리 않고 템플릿 리터럴로 할당함..
   • 문제 발견 시 미루기.. 나중에 해야지..
4. 말하지 않아도 이해해줄 것이라 생각함
   • 토요일 밤 8시 🤿
   • 불명확한 필터 UX 작업 후 이렇게 작업한 이유를 공유하지 않음

⇒ 신뢰에 대해 다시 한번 생각해 보기. 업무 의사소통 스킬 다듬기. 관련 서적 읽어보기