기동팀 최종 결과

소통

• 스몰 토크

• 저희는 날선 사람이 없어서, 항상 스무스한 분위기
• 특별히 누군가의 감정이나 예민한 부분이 있는지 걱정하지 않고 이야기 할 수 있다는 점 좋다

• 화이트보드로 스크럼 시간 절약 (10분)

• 가벼운 문제라도 생기면 바로 채팅을 통해 1차 알림 후 소통을 이어나간 점

• 화이트 보드 많이 활성화시킨 점
• 변경사항 등 있으면 이야기 한 것도 반드시 적어두었다

• 린트 rule을 바꾸고자 할 때 슬랙에 바꿔야 하는 이유를 남긴 점

• 소통을 좀 더 확실하게 한 점
• 텍스트로 전달하는게 어려움을 느껴서, 노션 칸반 보드를 활용하여 소통의 좋은 도구로 사용

• 문서로 해결되는 소통이 구두로 변환되는 문제
• 이중 시간의 소요 (문서작성시간 + 구두설명 시간)

• 싫은 소리 하는 사람이 없당.. 개선을 위해 조금 더 이야기 해볼 것.

• 문서 확인을 우선으로 하자

개발 진행 관련

• 첫 페이지를 구현한 다음에는 PR단위를 줄인 점

• PR 등록 시 30분 이내 같이 리뷰하는 시스템 도입

• 필요한 기능 위주로 우선 순위 선정을 잘했음

• issue + PR 연결, epic등록까지 이슈 분할을 잘했음

• git(장)의사님이 있어서 매끄러운 git 그래프가 그려진 것

• CSS/styledcomponent 의견

• 코드의 통일성이 없음

• 폴더명, 파일명들의 prefix, postfix가 제각기 다른 문제

• 통일된 디자인 시스템이 없는 문제

• (마감)시간에 쫓김
• 리뷰가 제대로 짚고 넘어가야 하는 것들도 그냥 넘어가게 되는 문제
• 코드와 PR의 가독성이 부족했음
• 이슈와 커밋 단위가 일치하지 않았음

• 스타일 재사용을 못했음

기타 (어려운점, … )

• 큰 갈등없이 원활히 2주를 마쳤다.

• 스스로 할 수 있는 일을 미루지 않고 잡아서 해내는 문화?

• Form 쪽을 hooks등을 통해서, 로직 코드량을 줄이고 싶었는데, 쉽지 않았다.

• 라이브러리 사용에 있어서 원리를(어떻게 동작하는지 정도라도) 모르고 사용하면 의미가 없다는 것을 느낌
• 처음에 Formik 공식 문서의 예제 코드만 활용하다보니 제대로 된 라이브러리 사용을 하지 못함
• 이후에 원리를 파악하고 사용하면서 원하는 방향으로 코드를 짤 수 있었음
• react-router도 마찬가지
• React-Slick 사용할 때 documentation을 제대로 읽어보지 않아 먼 길을 돌아갔다
• 대신에 git code를 분석하는 좋은 경험은 했다

• 뱃지 구현 시 커스텀 값을 순조롭게 추가할 수 있도록 재사용성을 높이고 싶었는데, 가독성이 특히 부족한 것 같다.

• 가독성의 문제
• 함수 당 라인 수 50줄만 넘어가도 안 읽힘
• 실력의 문제일 수도 있지만 현재 코드 상에서는 리팩토링이 필요함
• 개발 시간의 문제도 포함됨

• 함수형 컴포넌트
• 세부 구현 함수(순수 함수)화 + 좋은 함수명

• 리팩토링시, 항상 의존도를 낮추고, 응집도를 높이는 방향으로 설계를 고려하자.

• 하나의 함수(컴포넌트)가 단일 책임의 원칙을 위반하지 않는지 늘 주의하자.

• 가독성을 늘릴 수 있는 여러 방법이 존재한다. 생각하고 공유하고 시도하자!
• 복잡한 로직을 변수명등으로 표현