중간 회고

최희라

Keep

• 익숙하지 않았던 Tailwind CSS를 꽤 깊게 사용해 본 점

• UI 라이브러리를 사용하지 않고 직접 컴포넌트를 개발해 본 경험

• 브랜치 전략, 디렉토리 구조, PR & ISSUE template 등 다양한 컨벤션을 정하며 진행한 협업 경험

Problem

• 스프린트에 맞춰 개발 일정을 지키지 못한 점

• 빠르게 코드 리뷰를 하지 못한 점

• 컨디션 관리

Try

• 구현하기 전 좀 더 촘촘한 설계 시간을 갖고 문서화 하기

• 기능 구현에 급급하기 보다는 적절한 방식인지에 대해 고민하고 찾아 보기

• 매일 코드 리뷰 시간을 정해두고 실행하기

• 스프린트 회고 진행하기

신준혁

Keep

• 처음 사용해보는 TailwindCSS와 twmerge에 대한 이해

• 협업에서 중요한 코드컨벤션, 브랜치 전략 등과 같은 규칙을 실제로 경험

• SNS 커뮤니티 프로젝트를 기획, 개발 하면서 만날수 있었던 문제나 상황을 경험

Problem

• 급한 커밋으로 인해 오타나 개행과 같은 사소한 문제 노출

• 빠른 코드리뷰 부족

• 기획단계에서 더 정확한 예측을 해서 이후 나올 문제를 방지했어야했지만 경험 부족으로 개발도중 문제 해결

Try

• 기획과 계획을 정확하게 하고, 예상되는 문제 도출을 최대한 노력하기

• 계속해서 팀원들과 얘기하면서 이후 발생하는 문제를 줄이기

• PR을 매일 확인하고 리뷰하기

안범

Keep

• 담당한 기능이나 페이지에서 발생할 수 있는 오류나 버그 예상하기, 예상되는 문제에 대해 팀원과 상의하기 (한 번 더 확인하고 예상 가능한 오류 발생 줄이기)

• 비대면 소통을 도와주는 github review, slack, discord를 활용하여 팀원에게 직접 물어보고 답변하기

Problem

• 기획과 디자인 단계에서 확인하지 못한 문제를 발견

• 일정에 맞추기 위한 라이브 형식의 코드 리뷰, 구두 형식의 코드 리뷰 사용 (자세한 기록이 남지 않음)

• cva를 활용하여 디자인 시스템을 제작하면서 tailwind css 응용, 사용 능력 부족함을 발견

Try

• 자주 PR 알람을 확인하고 슬랙을 통해서 동료에게 코드 리뷰 확인 부탁하기

• 이전에 코드 리뷰에서 나온 문제는 다시 나오지 않도록 코드 작성하기

• 팀끼리 정한 컨벤션, 템플릿, 규칙 등을 깃허브 위키에 문서화하기

• 이전에 사용해본 기술(react query, axios, react-router-dom 등)에 대해서 잊지 않도록 문서화 습관 기르기

최성민

Keep

컴포넌트 분리

• 팀원들과 프로젝트에서 사용될 컴포넌트를 미리 분할하고, 이를 각자가 맡아서 구현했다. 이전까지는 작업하다가 컴포넌트로 빼면 좋겠다 싶은 것들을 분리했는데, 처음부터 미리 구조를 잡고 시작하니 컴포넌트를 어떻게 분할해야 하는지, 어떤 기능을 추가해야 하는지에 대해서 좀 더 깊이 고민할 수 있었다.

• 물론 여전히 고민되는 지점이나, 확실하게 정하지 못한 부분들도 있지만(variants), 이는 팀원들이 학습해온 과정의 차이나 부족한 시간의 영향도 어느정도 있다고 생각한다. 결국 여유롭지 못한 상황 속에서 최선의 선택을 하려 노력한 것이고, 그로부터 발생하는 문제라면 나의 결정을 탓하기보다 개선하기 위한 방향에 대해 고민해야 한다고 생각한다.

• 모든 선택에는 이유가 필요하다. 지금은 부적절해 보이는 방법을 과거의 내가 선택했더라도, 그 당시의 내가 나름대로 합당한, 혹은 합당하다고 믿는 근거를 통해 선택을 이끌어냈다면 결과가 어떻든 의미가 있다. 나는 성능의 이점, 부족한 개발 시간, 비교적 높지 않은 러닝 커브 등을 이유로 tailwindcss를 선택했다. 그리고 학습의 목적으로 디자인 시스템 구축을 희망하는 팀원들의 열정에 발맞추기 위해 class-variance-authority 도입을 제안했다. 그런 점에서, 지금까지의 프로젝트 진행 과정이 썩 괜찮은 것 같다.

능동적이고 활발한 PR / 리뷰

• 협업의 꽃은 활발한 리뷰가 아닐까.

• 동시에 협업을 무너뜨릴 수 있는 양날의 검이기도 하다.

• 어떤 태도로 임하느냐, 그것이 팀의 분위기를 결정하고 팀의 분위기는 곧 프로젝트, 나아가서 서비스의 완성도를 결정한다.

• 그럼 나는 어떤 태도로 리뷰를 진행해왔나?
• 팀원들이 작성한 코드에는 나름대로의 의도와 근거가 있을 터. 그 의도를, 그리고 그에 대한 결과물을 절대 폄하하거나 무시하지 말자.
• 만약 개선해야 할 부분이 보인다면 상대방의 기분을 해치지 않도록 유연한 말투로 조심스럽게 제안하자.

• 물론 나는 이렇게 하려 노력했지만, 또 팀원들 입장에서는 다르게 받아들였을 수도 있겠지?

• 지금까지의 마음가짐을 유지하되, 나의 취향을 강요하지 않고 더 나은 프로젝트/서비스를 목표로 개발하고 있음을 잊지 말자.

Problem

에라 모르겠다 개발 시작

• 충분히 회의를 했다고 생각했다.

• 아토믹 디자인 패턴을 차용해보자며 팀 내에서 결정을 내렸고, 그러기 위해선 최소한의 디자인 시스템이 필요했다.

• 하지만 개발 시간이 부족하다는 핑계로 무작정 시작해버렸다.

• 결국 개발 진행하면서 각자 적당하다고 생각하는 수치를 사용했고, 이는 더 이상 일관된 스타일이라고 보기 어려웠다.

• 결국 뒤늦게 회의를 하며 어느 정도 기준을 잡았지만 이 마저도 응급 처치에 불과한 것 같다. 이 문제를 해결하려면 구체적인 디자인 시스템이 필요할 것 같고, 현 상황에서는 그저 최선을 다해 일관된 스타일을 작성하려 노력할 뿐..

CVA

• 끝나지 않는 variants 문제.. 앞선 에라 모르겠다 개발 시작과 어느 정도 비슷한 문제이다.

• tailwindcss는 설정 파일을 통해 테마 및 사용자 정의 클래스를 지정할 수 있다. 이는 일종의 디자인 시스템 역할을 한다고 생각한다.

• 그치만 좀 더 제한적인 스타일을 제공하기 위해 cva를 도입하고자 했고, 다음과 같은 기준을 세웠다.
• 사이즈(gap, width, height, margin, padding 등), 색상(primary, secondary, success, error, grayscale 등)의 경우에는 범위가 너무나도 다양하기 때문에 className으로 받을 것
• 정렬과 관련한 속성이나 하나의 variant로 여러 값을 변경해야 하는 경우에는 variants로 지정할 것

• 하지만 결국에는 이도 저도 아닌 애매한 결과만이 남았다..

• 상황에 맞는 추가적인 스타일을 받기 위해 자꾸만 className을 넘겨 받게 되는 것..
• 그래서 cva 사용의 의미가 퇴색되지 않는가? 하는 생각이 자꾸만 들었다.

• 현재는 팀원들과 정한 기준을 따라 나름의 일관성을 유지하고 있다. 만약 기회가 된다면 완전히 cva를 덜어내거나, 더 구체적인 디자인 시스템을 구축해보면 좋을 것 같다.

Try

사용자 경험 개선

• 이제 컴포넌트 구현은 어느정도 마무리가 됐다.

• 남은 건 API 연결 및 페이지 개발. 사실 이 부분은 이제 크게 어려운 건 없어 보인다.

• 다만 욕심이 나는 건 Suspense, Error Boundary 등을 이용한 사용자 경험 개선.. 물론 서버 개발자와 원활한 협업이 어렵기 때문에 에러를 얼마나 세분화하고 촘촘하게 다룰 수 있을지는 모르겠다. 하지만 가능한 만큼만이라도 해보면 좋지 않을까!

정혜연

Keep

협업 방식 및 툴

• 팀원들과 활발한 소통으로 이슈를 공유하여 필요한 개발 규칙들을 계속해서 개선하여 혼선을 줄이고 유사한 코드 스타일을 맞춰나가는데 만족하고 있습니다.

• 기획부터 대략적인 디자인, 협업 시 사용할 도구들, 컴포넌트를 어떻게 분리할 지, 폴더 구조는 어떻게 할지 등 여러가지에 대해 다 같이 의견을 나누고 종합하여 규칙을 정해 이후 협업에 충돌이 크게 발생하지 않았습니다.

• 코드 리뷰를 통해, 좀 더 좋은 코드를 작성하기 위한 의견을 나누어 코드의 가독성을 높이고 개선할 수 있었습니다.

• 팀원 모두 상대방의 이야기를 경청하여 듣고, 받아들이고 의견을 제시해 줍니다.

• 궁금한 것이 있거나 문제가 있을 경우에 실시간으로 공유를 하면 모두 시간을 들여 봐주시고 끝까지 잘 설명해주십니다.

• 의견과 궁금한 점을 조심스럽지만 지속적으로 여쭤보고 해결하면서 코드에 대한 지식과 협업하는 방식에 대해서 배워가고 있습니다.

• 팀원들이 딱딱하지 않고 질문을 자유롭게 하는 분위기를 형성하여 주어, 모르는 것이 있거나 물어보고 싶은 것이 있을 때 어렵지 않게 물어볼 수 있었습니다.

기술

• tailwind를 사용할 때 항상 className만 작성해주어 가독성이 좋지 않다 생각했는데, cva, twmerge를 사용하여 이런 문제를 해결하여 작성하는 방식을 학습했습니다.

• tailwind config에 일부 제한을 두는 방식으로 진행하고 있는데, 말씀으로만 들었을 때는 정확히 그려지지 않았는데, 직접 사용해 보니 어떠한 방식인지 알 수 있었고 이러한 방식도 있다는 것을 알 수 있었습니다.

• Feed 컴포넌트를 개발하면서 어느 경우에 데이터를 props로 받아와야 하는지 학습할 수 있었습니다.

Problem

시간적인 문제

• 코드에 대한 의견을 공유하고 다른 팀원이 작성한 코드를 이해하기 위해서 코드 리뷰를 하는 것은 반드시 필요하다고 생각을 하는데, 코드 리뷰를 작성하려면 코드 파악과 의견을 글로 작성하는데 시간이 많이 걸려서 내가 개발하고 있는 것이 늦어지는 문제가 있고, 개발에 집중을 하면 코드를 못 살펴보거나 머지가 완료될 때까지 리뷰를 달지 못하고 나중에 살펴보게 되는 문제가 생겨서 중간 지점을 잘 잡아야 할 것 같습니다.

• 컴포넌트 하나를 만들고 나면 간단한데, 이슈 하나에 해당하는 작업을 완료할 때까지 시간이 예상 시간보다 배로 걸리는 것 같습니다. 추후 개발 일정에 영향이 미칠 것 같아 걱정이 됩니다.

문서 정리

• 그때 그때 이야기가 나오는 것에 대해 얘기 된 주제만 간단하게 메모하고 있는데 정리가 안되어서 같이 정리를 하고 공유를 할 수 있다면 좋을 것 같습니다.

일정

• 프로젝트 마감 기한이 다가 올 수록 시간이 촉박해질 것 같아, 개발 일정을 한 번 점검하고 역할을 나눠봐도 좋을 것 같습니다.

의견 전달

• 무언가 여쭤볼 때, 의견을 마음 상하게 전달하고 있진 않은지, 혹은 너무 조심스럽게 전달하고 있는지 조금 걱정이되는 부분입니다.

기술

• 컴포넌트를 상속받는 경우에는 상위 컴포넌트에서 정의한 css 속성만을 사용하는 것이 일관되고 재사용성 측면에도 좋다고 생각을 했는데, cva에 대해 의견을 나눌 때는 이렇게 전달하지 못한 것 같습니다.

Try

• 코드 리뷰를 작성하는 시간을 정해두는 것 좋은 것 같습니다.

• 이슈로 작성한 모든 내용이 완료되지 않더라도, 지속적으로 원격에 올려 리뷰받고 진행상황 공유하기

• 개발 일정을 한 번 점검하여, 각 이슈마다 마감기한을 어느정도 정하고 역할을 나눠봐도 좋을 것 같습니다.

• 정답은 없기 때문에, 여쭤볼 내용은 정리해서 확실하게 전달하기

• cva에 대해서는 마감기한이 촉박한 만큼 이야기 나눈대로 작성을 하고, 추후에 이야기를 다시 나눠서 애매한 경우가 생기지 않도록 확실히 정할 수 있도록하여 리팩토링을 진행할 수 있어도 좋을 것 같습니다.