최종 회고

맘에 들었던 점

• 팀원간 서로 양보할 부분은 양보하고, 의견을 표출할 때 모두 해당 의견에 대하여 경청한 점
• 반대 의견이 있다면 합리적인 이유를 제시하고 토론을 진행
• 아이디어를 제시하기에 너무나도 자유로운 분위기였다. 코어타임 진행 중에 궁금한 사항이나 막히는 부분이 있다면 바로 마이크를 키고 말하거나, 그게 어려우면 디스코드 팀 채팅방에서 자유롭게 채팅을 날리는 문화를 확립했다. 다른 팀원분들도 어려움이 있을 때 다 같이 모여서 해당 이슈에 대하여 의견을 자유롭게 제시하고, 여러 방법들을 시도해 보면서 이슈들을 해결할 수 있었다.
• 어떠한 의견도 의미 없는 의견이거나 무시할 만한 의견이라고 생각하지 않고 모두 경청해 주어서 너무 감사하다.

• 칭찬을 아끼지 않음
• 우리 팀원 분들 모두가 성격이 좋으시다. 그래서 잘했다고 하는 부분 에대하여 항상 감사함을 표출하고, 박수를 쳤다. ㅋㅋㅋ 칭찬은 고래도 춤추게 한다는 말이 있는 만큼, 칭찬을 받으면 더 열심히 하게 되는 부분이 있어 개인적으로 동기 부여가 많이 되었다.

• 팀 화이트보드 도입
• 2주간의 짧은 개발 기간 때문에 시작과 마무리 스크럼을 모두 진행하는데, 여러가지 이슈들을 생각하다 보면 의미없이 보내는 시간이 정말 많았다. 그런데 팀 화이트보드를 도입하고 나서, 끝나거나 생각나는 이슈들, 다루고 싶은 주제들을 자유롭게 팀 화이트보드에 적어두면, 마무리 스크럼 또는 다음날 오픈 스크럼에서 팀 화이트보드에 써있는 주제들을 가지고 이슈들을 다루니, 스크럼 시간도 줄어들면서 중요한 부분만 빠르게 논의가 가능했다.

• PR의 단위를 짧게 가져갔음
• 처음에 페이지 단위로 개발을 하다 보니 PR의 길이가 너무 길어졌다. 그래서 읽는 사람도 부담이 되고, PR 리뷰 기간이 길어지면서 반영이 늦어지는 악순환이 발생했다.
• 해당 부분을 해결하고자 이슈 자체를 작은 단위로 가져가고, PR 코드 양도 200자 정도로 매우 적게 가져가기로 정했다. 그리고 basic 기능들을 개발하기 때문에 코드의 반영이 빠르게 이루어져야 하므로, PR을 올리면 30분 이내로 리뷰가 끝나게끔 룰을 정했다. 사실 해당 부분은 나의 경우는 코드를 작성하다가 흐름이 끊기는 것을 별로 좋아하지 않아서 반대 했던 부분이다(마무리 스크럼 1시간 전에 PR을 리뷰하는 시간을 갖는 것이 어떠냐고 제안했었다) 그러나 돌아보니 해당 부분은 나의 잘못된 생각임을 깨달았다. PR리뷰를 빠르게 하고 빠르게 반영함으로써 개발 시간을 크게 줄여 지금의 위치에 올 수 있었다고 생각한다.

• 조금이나마 단일 책임 원칙을 준수하고, 컴포넌트의 의존도를 낮추고 응집도를 높이기 위하여 이를 의식적으로 생각한 것
• 이전부터 코드를 작성하면서 가장 고민했던 부분 중 하나이다. 특히 오브젝트라는 책을 읽으면서(아직 시간이 없어서 챕터 1밖에 읽어보지 않았지만) 가장 첫 챕터에 나오는 부분이 바로 이 단일 책임 원칙 준수와 의존성을 줄이고 응집도가 높은 클래스를 만드는 것이 중요하다는 내용이었다.
• 해당 부분은 Java로 쓰여졌기 때문에 컴포넌트인 리액트와 Java와는 다른 패러다임을 갖기 때문에 완벽히 이론을 적용할 수는 없었지만, 원칙 자체는 동일하므로, 최대한 하나의 컴포넌트가 하나의 역할을 하는가? 를 우선적으로 생각하여, 해당 컴포넌트 내부에 다른 역할을 하는 함수, 분리 가능한 함수가 있다면 이를 우선적으로 분리하려는 시도를 하였다. 완벽하진 않았지만, 그래도 어느정도 가독성 향상과 유지보수하기 쉬운 코드를 만드는데 기여할 수 있던 것 같다.
• 다만 시간이 부족하여 팀 내부에서 일단 구현에 집중하고 재사용성은 추후에 고려하자고 했으므로, 응집도나 의존성을 낮추는데 크게 힘쓰지 못한 것이 다소 아쉽지만, 이 프로젝트는 접지 않고 계속 리팩토링 및 서비스를 개발하자고 팀원들과 확정했으므로 앞으로 해결될 것이라 기대한다 🙂

• 큰 → 중 → 작 방향으로 개발을 진행한 것
• 나의 평소 개발 진행 방향은 보통 핵심이라고 생각되는 부분의 로직을 생각해 둔 뒤, 각이 나온다 싶으면 세부 사항을 개발하는 방식으로 진행해왔다. 이런 방식은 먼저 큰 것부터 정리해두고 나머지 부분을 정리할 수 있어 심적 여유가 생긴다는 점에서는 좋지만, 전체적으로 봤을 때 처음에 잘 풀리지 않으면 개발 진행 속도가 점점 늦어진다는 단점이 있고, 이를 인지하고 있었다. 이번에는 큰 틀로 먼저 로직들을 짜고(이를 함수명으로 반영하는 것이 정말 가독성이 좋았다), 그 큰 틀 안에서 가져야 할 책임들을 나누고 다시 해당 책임 내에서 다음 책임을 나누는 방식으로 진행했다. 이렇게 트리구조로 접근하는 것이 생각의 흐름과 일치하기 때문에 개발 속도도 증가되었고, 가독성도 향상되었다고 생각한다.

아쉬웠던 점

• 개인적으로 소통 부분에 대해 크게 아쉬웠던 점은 없었다. 가끔 의견 차이가 있긴 했지만, 그것이 감정적으로 발전하진 않았다. 우리 팀 자체가 일단 타인의 말을 경청해주는 문화가 있었고, 이유가 합당하면 수용하는 오픈 마인드를 가지고 있기 때문이었다.

• 통일된 디자인 시스템의 부재
• 공통적인 부분이 많았음에도 불구하고, css 는 일단 동작만 하면 돼!라는 생각에 emotion 기반의 컴포넌트를 사용하였음에도 불구하고 잘 사용은 못했던 것 같다. 이번 프로젝트에서 QuizSolvePage와 QuizResultPage를 담당했는데, QuizResultPage 는 지금 컴포넌트를 봐도 그냥 닫고 싶을 정도로 너무 막 짰다.(사실 가장 처음에 만들어진 부분이라 더 그런것도 있다)
• 오히려 리팩토링할 수 있는 여지가 많아서 좋다(?). 우리팀은 이번 2주가 지나간 뒤 조금 여유를 두고 리팩토링을 우선 진행한 뒤, 우리가 생각한 advanced를 구성하기로 했다.
• 아마도 우선 공통적으로 사용하는 부분 button, input 등등의 스타일을 디자인 시스템으로 만든 뒤에 사용하지 않을까 싶다!!

• rule 적인 부분이 완벽하지 않았던 것
• 시간적인 이슈 때문에 완벽하게 팀 룰을 정하지 않아 파일명의 prefix가 다 제각각이었고, 폴더 구조도 애매한 부분이 많았다. 좀 더 짚고 넘어가야 할 부분이 꽤 있었음에도 불구하고 일단은 구현이 목표이다보니 잘 짚고 넘어가지 않았던 점이 조금 아쉽다. 해당 부분 다음주에 있을 팀 회의 때 정해나가려고 한다.

• 이슈와 커밋 단위의 불일치
• 이슈단위로 개발하는 것이 아직 익숙하지 않다 보니 해당 이슈 범위를 벗어나게 되는 경우가 종종 발생했다. 처음에는 페이지 기반을 닦다보니 PR 단위가 커져버려 더욱 이런 문제가 심각했다. 중반 부분에는 그래도 신경 써서 개발을 해서 해당 문제가 좀 덜 했지만, 후반에 시간에 쫒기면서 다시 해당 문제가 드러나게 되었다.
• 해당 문제를 해결하기 위한 방법…으로는 더 실수(?)를 많이 하여 익숙해지는 방법 말고는 없지 않을까 싶다. PR도 단일 책임으로!

• 로직과 컴포넌트의 분리를 시도하고자 하였으나, 잘 되지 않았음
• 페이지에 많은 기능들이 들어가게 되고 api 요청 함수들과 util로 뺄 수 있는 순수함수들을 제외하고 나머지들에 대하여 로직 분리를 해보고 싶었으나, 리액트 상태에 묶여있는 부분들이 많아 리팩토링이 쉽지 않았다. 상태를 custom hook으로 묶기에는 재사용성도 떨어지는 부분이라고 생각해서 custom hook 방식으로는 리팩토링 하지 않았다. 실력의 문제이기도 하고, 시간의 문제이기도 한 것 같다. 리팩토링 기간에 좀 더 로직을 분리하여 순수함수로 내보낼 수 있는 부분이 있는지 확인하고, 코드 다이어트를 시도해 보고자 한다. (잘 안될 수도 있지만, 일단 해보는 거지 뭐…) → 해당 과정에 대해 기록으로 남기기

• 초반에 엄청난 git 실수
• git 사용법이 아직 익숙하지 않아서 초반에 중대한 git 실수를 저질렀다. develop 브랜치를 기본 브랜치로 사용하고 있는데, merge 하면서 conflict를 처리하다가 rebase를 잘못하여 develop 브랜치가 현재 작업하고 있는 브랜치에 머지되었다… 덕분에 그래프가 많이 꼬여버렸다 ㅜㅜ. 덕분에 git 작업하면서 명령어도 조금 더 잘 숙지하게 되었고, 실수를 다시 하지 않으려고 두 번 세 번 확인한 결과, 그 이후로 중대한 실수는 발생하지 않았다.

내가 배운 것

• 팀 단위 소통 방식(문서화 및 리뷰)
• 팀 단위의 소통은 개인 프로젝트를 진행할 때보다 훨씬 어렵고 중요함을 깨달았다. 우리 팀원과 함께 하면서 문서화의 중요성을 배웠다. 기록을 중시하는 팀원분들 덕분에 늘 스크럼 하기 전에 회의록부터 만드는 습관을 가지게 되었다. 의사 소통 비용을 줄이는데 가장 큰 기여를 했다고 생각했다. 그때 그때 기억나는 좋은 아이디어들도 기록하지 않으면 소멸되거나, 스크럼하면서 이런 저런 좋은 아이디어나 의사 결정을 하더라도 뒤돌아서면 까먹기 일상이었다. 근데 회의록을 기록하면서 이러한 부분이 많이 개선되었다고 생각한다.
• PR은 내 코드를 남에게 보여주는 것이다. 나 역시 리뷰를 통해 더 좋은 코드를 작성하고자 리뷰를 받는 것인데, 상대방에게 이 코드가 무엇인지 설명을 제대로 하지 않으면 무엇을 하고자 하는지 잘 모를 것이다. 나 역시 이러한 피드백을 받았으므로 더 성심 성의껏 PR을 작성하는 연습을 했다. (물론 코드 가독성이 일순위이다)
• 그리고 팀에 기록되지 않는, 프로젝트를 진행하면서 무엇을 했는지 간단히 기록하는 TID를 개인 노션에 작성했다. 작성에 공들일 시간이 별로 없어 간단히 무엇을 했는지, 어떤 이슈가 있었는지, 해당 이슈를 해결했다면 어떤 방식으로 해결했는지, 해결하지 못했다면 앞으로 어떤 방식으로 접근해볼 수 있을지 간단하게 적어놓았다. 그러면 다음번에 같은 실수나 오류가 발생했을 때 훨씬 찾아보기 쉬울것이다.

• 가독성의 중요성 (코드 길이 및 변수명, 상식적인 흐름, 단일 책임) [ 엄청난 난제, 사실 지금도 잘 모르긴 함 ]
• 팀 프로젝트다보니, 내 코드만 담당하는 것이 아닌, 타인의 코드를 편집해야 하는 경우가 필연적으로 생길 수 있다. 그런데 코드가 제대로 책임이 분리되어 있지 않고, 가독성이 너무 떨어져 어디서부터 고쳐야할 지 몰라 방치된다면?? 정말 최악의 경우 해당 코드를 전부 드러내거나 같은 작업을 여러 번 반복하게 될 수 있다.
• 나 역시 팀원분의 코드를 보면서, 내 코드를 볼 때도 사람들이 쉽게 편집할 수 있는가? 에 대하여 의문을 갖게 되었고, 해당 부분에 좀 더 신경쓰면서 코드를 작성했다.
• ex) 사용자가 의도한 동작을 통해 해당 페이지로 접근했는지 → isAppropriateAccess
• 함수의 길이는 50줄 이내로 작성하기
• 잘 이해가 안될 때에는 코멘트 작성하기
• 상식적인 흐름 같은 경우는 다음과 같은 경우이다
• 일반적으로 물건을 사기위하여 손님이 점원에게 돈을 지불하지, 점원이 손님의 가방으로부터 돈을 빼가지 않는다.
• 상식적인 흐름을 위해서는 구현 부분과 api 영역의 분리가 필요하다.

• 분명 더 있던거 같은데 까먹었다….ㅎㅎㅎ휴ㅠ

소감

• 개발자로 나아가는 첫 번째 프로젝트였다. 그래서 데브코스에 처음 지원했을 때에도 나는 팀 활동을 하고싶다고 강력하게 어필했던 기억이 있다. 막상 팀 프로젝트를 시작하려니 기대도 되긴 했는데 그보다 불안감이 더 컸다. 팀장이라는 역할을 달고 있었기 때문에 약간의 부담감도 있었다.

• 그러나 기획부터 마감까지 같이하면서, 불안감은 사라지고 데브코스에 참여하길 정말 잘했다는 생각밖에 안든다. 내가 혼자 프로젝트를 진행했다면, 데드라인이 명확하고, 기획이 명확한 서비스를 만들 수 있을까? 아마 못했지 싶다. 역시 사람은 데드라인이 정해져있어야 일을 한다(?)

• 내가 기여한 부분보다는 팀원분들로부터 배운 점이 훨씬 많았다고 생각한다. 이 역시 첫 팀프로젝트였기 때문에 많은 기대는 하지 않았다. 그래도 앞으로 리팩토링을 진행하면서 내가 팀에 기여할 수 있는 기여도가 좀 더 높아졌으면 한다.

• 우리팀 밸런스는 정말 좋았다. 각각 다른 부분에 강점을 가진 분들이 모이니, 이것이 모여 -가 아닌 +가 되는 효과를 보았다. 우리 팀은 정말 오랫동안 기억에 남을 팀이다.

• 하도 기록을 많이 하니까, 이제는 기록을 하지 않으면 뭔가 찝찝한 마음이 있다. 덕분에 이번달 데브코스 기록왕에 선정되었다. 정말 기쁘다 😀