3차 프로젝트 회고

 

• 기획의 깊이에 대한 고민 (팀원들이 원하는 방향성, 기획 구성의 단단함. 가설을 세우고 검증하는건 어떨까)
• 와이어프레임을 Figma로 표현할지, 퍼블리싱까지 할 것인지 (Figma를 선택했던 근거)
• 와이어프레임을 일관된 디자인으로 정리하는 역할 담당 (제가 할게요)
• 팀원의 pain point를 눈치채고 도움주기 (마우스 클릭 소리를 듣고 해결, 드래그가 안된 부분 해결)
• PR 템플릿 양식을 전환하게 된 이유 (일관된 형식 유지. 불필요한 내용은 주석으로 전환)
• 테스트 코드의 필요성을 인식하게 된 계기 (글로는 아무리 정확하게 전달하려고 해도 조건에 따라 부정확할 수 있다)
• PR 리뷰의 장점. 리뷰를 작성하지 않아도 계속 PR을 followup 해야하는 이유 (좋은 코드, 진행 상황 파악, 고민 공유)

 

기획에 대한 개인적인 고민

1. (현재) 기획 기간이 짧다
2. 기획 의도를 충분히 고민해보자
 - '문제'를 해결하기 위해 프로젝트를 진행하는지
 - 해당 주제를 꺼낸 이유가 고객의 페인 포인트를 인지하고, 해결하기 위함인지
 - (어떤) 기술을 적용해보기 위해 프로젝트를 진행하는지
 
그리고, 기획을 리드할 수 있는 역량을 갖고 있는 사람이 필요하다.
 - 단순히 기획 단계대로 진행하기 위해, 혹은 갈무리 하는 이야기 뿐만 아니라.
 - 적절한 시점에 문제가 될 수 있는 부분을 제시하거나, 더 들어가는 질문을 하거나, 생각의 전환을 할 수 있는 의견 제시
 - 우리가 풀어야 할 문제에 집중할 수 있게 만들어야 하는 것 같다. (흐름대로 흘러가며 진행되는게 맞나?라는 의문 대신)

 

다수결이 과연 맞을까? 필요할까?
  => 각자의 프로젝트에 임하는 마인드가 다르다. 어떤 문제를 해결해야 한다는 생각을 갖고있는 것과 꼭 그걸 해야하느냐는 의문을 표하는 사람이 있을 때 어떻게 할 것인가?
 
시간이 정말 부족할까?
- 아이디어를 제시하는 단계에서, 아이디어 만으로 추측해서 폐기되지 않아야 한다.
- 충분히 재밌는 이야기가 진행될 수 있다. 미리 프로젝트 규모를 예상해서, 겁먹지 않았으면 좋겠다.
 
사용자 유치
 기획서를 제출해야 하는 시기가 '단기간'이라는 조건이 있기 때문에 두려울수도 있다. 이해한다.
 
실제 사용자를 유치하지 못한 채로, 만들기 쉬운 서비스를 릴리즈 하고 싶지는 않다

 - 첫번째로, 어떤 기능을 덧붙일지 논의하지 않고 "만들기 쉽다"는 결론을 내리는 것에 주의해야 하는 것 같다.
 - 두번째로, MVP(minimum value product)를 만들고 사용자의 피드백을 받아서 해당 핵심 기능을 발전시킬지, 버릴지 등 의논해서 버전업을 해야 한다.(그렇지만 지금은 MVP대신 초 거대 프로젝트 기획 중...)

이 내용들이 현재 교육 기관에서는 이루어지기 힘들지 않을까 싶다.

 
3. 이력서: 작성할 때 고민하지 말고, 미리 고민해보면 좋을 것 같다.

 - 어떤 내용을 자유 양식 이력서에 담을 것인가?
 - JD를 살펴보면 어떤 라이브러리를 사용해본 경험이 있는지를 묻는 경우가 있다.
 - 프로젝트를 진행하면서 가장 가치있는 경험이 무엇일까? 
 - 하드스킬도 물론 중요하고 소프트스킬도 중요하지만..
 - 가장 얻기 힘든 경험은 실제로 서비스를 운영하는 일이 아닐까 싶다. 돈을 번다는 의미가 아니다. 작은 프로젝트에서 수익을 기대하기 보다, 사용자들의 피드백을 받아 개선하고, UX를 고민하고.. 거기에서 더 많은 이야기를 풀어낼 수 있을 것 같은데 이건 팀원들의 수요가 있어야 진행이 가능한 것 같다.
 
4. '기존의 어떤 것, 어떤 기능'을 생각하고 그대로 말하기보다, 이 아이디어에 접목할 수 있는 다른 가능성을 생각해보기
 - 특정 서비스와 같은 문제를 해결하려고 하더라도, 다른 방식으로 해결해봤으면 좋겠다.
 - 데이터를 보여주고, 커뮤니티를 만드는 것도 좋지만 사용할만한 계기가 있는 웹사이트였으면 좋겠다
 - 유틸 기능도 좋지 않을까?
 - 우리는 어떤 문제를 풀기 위해, 어떤 가설을 제시할 것인가?

5. 프로젝트. '서비스'를 한다면 사용성을 개선하기 위해 고민을 하는가?
- 아직 일정이 촉박하지 않은 상태라면, 무엇을 하고싶은지 팀으로 더 고민해보면 좋을 것 같다.

팀 회의에서, 메인 페이지의 정체성에 대해 고민이 있었는데, 팀 회의 때 잘 받아들여지지 않았다.
[메인 페이지]와 [검색 페이지]에서 보여주는 내용이 비슷한 것 같다는 생각에, 메인 페이지를 어떻게 활용하면 좋을지에 대한 의견을 제시하려고 했다. (gif로 만들어서 미리 제시한 내용으로는 랜딩페이지 역할과 사용자로부터 받는 문의사항 전송 기능)
돌아온 대답은 "지금은 이미 늦었다" 였는데
페이지 구성 단계였고 유저 스토리에서 어떤 기능을 화면에 담을지 의견을 나누고 정했던 때였다.
 
앞으로 사용자에게 어떤 가치를 제시하기 위한 새로운 가설을 제시한다면 그때는 더 늦었다고 생각할수도 있을까?
물론 프로젝트의 종료 기간은 정해져있기 때문에... 그러면 일정 기간 이후에는 이제 수정은 어렵고, 무언가 추가하기도 곤란하고, 그렇다면 기획 초반 단계에서 최대한 많은 고민을 해야 할 것 같은 부담이 생겼다. 결국 이 말의 의미는 현재 프로젝트에서 애자일하게 진행하기는 어렵다는 것이 아닐까
 
그런데 고민 "전부"를 초반에 할 수 있을까?
 
워터폴로 진행을 한다는 건
많은것이 바뀔것 같은 상황이 예상되지만 결국에는 처음 것으로 밀고 간다는건데..
 
회의를 할 때마다 고민했다.
정해진 아이디어 안에서, 사용자에게 [커뮤니티]라는 환경을 조성해 주는 것 만으로, 사용자가 실제로 사용할 것을 기대하는가?
'이렇게 만들었으니 이렇게 사용하겠지'는 안일한 것 같다고 생각한다. 전혀 사용하지 않을수도 있지 않을까

수요가 있을 수는 있다. 
하지만 우리 프로젝트가 커뮤니티보다 어렵다고 느껴지는 부분은,
커뮤니티로 사람들이 자유롭게 이야기 하는 것에서 그치지 않고
1. 사람을 모집하고,

2. 모집이 되었는지 확인을 하고,

3. 모집 완료를 하고,

4. 후기까지 남기는 것으로

여정이 마무리가 된다.
 
후기를 남기는 단계까지 가지 않더라도,

일단 모집이 되었는지 확인하려면 다시 사이트에 들어와야 하는데.
- 모집이 되기까지 시간이 얼마나 걸릴지도 모르고,
- "콘서트, 페스티벌"이라는 특수한 상황에 실제로 [동행]하기 위해 성사되기까지의 시간동안 사용자가 과연 기다려줄까?

그렇다면.. 다시 유입하기 위해 어떤 방법이 있는지를 다시 고민해봐야 한다고 생각했다.
 
초반 팀원 의견 중 "실제로 사용자를 모으는 것은 어렵기 때문에 위험을 부담하는 것보다 포트폴리오로 제출할 프로젝트를 만들자"가 있었다.
 
사용자에게 가치를 주기 위한 프로젝트 vs 포트폴리오로 쓸만한 프로젝트
이로 인해 계속 내적 갈등이 생기게 되는데, 내가 기획에서 방향성을 고민하는게 맞을까하는 부담감이 있다.
 
하지만 그래도 팀원들에게 상황을 인지하게 하고, 문제가 될 수 있는 부분, 생각지 못했던 부분을 짚어보는 건 계속 해보려고 한다.
 
일단,
우리가 사용자에게 제공할 수 있는 것은 무엇일까?
사용자의 페인포인트가 뭘까? 지금의 모집 방법도 어쩌면 충분히 괜찮은 것이 아닐까? 단지 현재 트위터로 모집하는 방법은 조금 불편한 점이 있을 수는 있다. 하지만 우리가 더 잘 할 수 있는 것은 무엇이지? 
우리의 사이트를 이용하게 되는 이유?
 
이런 생각을 하게 되면서, 자연스럽게 여러 솔루션들이 떠올랐다.
이런걸 제공하면?
이 방법은 어떨까?
이런 느낌은?
...
 
그런데 이렇게 솔루션을 팀원들과 논의한다고 했을 때, 나는 현재 과정에서 잘 하고 있는게 맞을까
현재 프로젝트는 교육 중심이다.
스타트업도 아니고, 실제 서비스로 진행되기 힘들 것이라는 생각을 하는 팀원들이 있다.
이 상황에서, 빠르게 기능을 바꾸거나 추가하고 UI, UX를 고민하고, 그것을 코드에 적용하고 실제 결과를 확인하기까지 팀원들이 지치지 않고 같이 챌린지를 할 수 있을까.

팀에서 align이 되지 않았을 때 내가 의견을 내는게 고집 부리는 형태로 가고 싶지는 않지만 생각해보면 좋을 것 같다..
 
오늘 새로 떠올린 내용
- 동행을 구할 때 form 형식으로 만들어서, 놓칠 수 있는 부분이 최소화 되도록 도와주면 완성된 글 형식을 어딘가에 복사붙여넣기 해서라도 사용할 수 있지 않을까?
 
나는 아직도 드라마틱한 무언가를 찾는건가

 

기술 vs 가치
시간이 부족하기 때문에 양립하기 힘들까?
가치를 제공하면서도
따로 기술적으로 챙길 수 있는 부분을 같이 챙겨야 한다고 생각해서
팀원들에게 현재 아이디어에서 우리가 할 수 있는 기술적 시도를 제시해보려고 했다.
 
우리 프로젝트에는 이미지가 있다. 포스터가 많고, 많은 정보들이 포스터에도 포함되어 있다. 
1. 이미지 최적화
2. 캐싱
3. 웹접근성을 높이는 것
(실제 사용자가 많아진다면 트레픽 관련한 내용도 포함될 수는 있겠지만)
 
각자 생각하는 바가 다를 수 있다.
실명제로 투명하게 운영하는 방법이 신뢰도를 높여 사용자 유입에 도움이 될까?
X에서 익명 또는 닉네임으로 활동하는 사용자들도 네임드라면 그만큼 파급력이 있다고 생각하기 때문에 사용자 입장에서 실명이 신뢰도와 연결되는 건 아닐 수도 있을 것 같다.
실명제로 운영하기 위해 회원가입 단계에서 이름, 전화번호등 개인 정보를 수집한다고 했을 때 초기 단계의 웹페이지에 주저하지 않고 기입하려고 할까?
 
이런 생각들이 떠오르는데,
누구라도 확신할 수 없이 의문만 있는 경우, 회의를 지속하는 것 보다
위의 가설들을 직접 확인해보면 된다고 생각했다.
 
GA를 통해 사용자들이 소셜 회원가입 페이지까지 갔지만,
개인정보를 요구하는 페이지에서 사람들이 입력 후 회원가입 버튼까지 클릭하는지 확인하면 될 것 같다.
지표로 직접 확인하는 것도 재밌을 것 같다.
 
https://www.youtube.com/watch?v=Xk3JKCIFWwo

와이어프레임 그리는 방식

와이어 프레임에 대한 의견을 물어보셨다.
Figma를 통해 그릴 것인지, shadcn을 연습하는 겸 직접 퍼블리싱 및 클릭 이벤트로 페이지 이동까지 할 것인지
 
의견을 내는게 늘 조심스럽다.
내가 잘못된 판단이었다면?
기술적인 문제는 아니다.
 
다만 '내' 의견의 근거가,
정말 팀의 일정 안에 마무리하지 못 할 것이라는 생각에서 비롯된 것일까?
 
사건의 발단은 와이어 프레임을 구성해야 하는 상황이었다.
 
의견이 두가지가 제시되었는데
1. Figma로 와이어프레임을 만든다.
2. shadcn으로 UI 퍼블리싱을 하고, click이벤트 등이 발생하는 것까지 만든다. (그리고 해당 ui는 프로젝트에 적용되지 않고 폐기된다고 하셨다. 왜냐하면 shadcn의 연습용으로 쓰이면서 동시에 와이어프레임을 구성하는 목적이기 때문에)
 
내가 생각했던 와이어프레임은 정말 말 그대로 와이어프레임 이었고(도형으로 배치 + 플러그인)
Figma를 떠올렸던 건 맞다.
(Figma에서도 prototype 기능을 활용하면 클릭으로 페이지 전환 또는 스크롤 효과를 줄 수 있는 걸 알고있고 사용해본 경험이 있다.)
 
다른 팀원은 2번으로 진행하면서 배우면서 해보는 것도 좋을 것 같다는 의견을 주셨다.
 
그런데 나는
(아무리 퍼블리싱만 이라고 하더라도)
실제로 코드를 작성하는 것과
이미지로 배치하는 건 작업의 강도가 다르다는 생각이 들었고, 합의된 UI를 바탕으로 퍼블리싱을 하는게 더 쉬울 것 같다는 생각이 들었다.
 
곰곰히 생각해봤다.
1. 일정을 생각해보면 8시간 정도 제작할 수 있고
2. 8페이지 정도(로그인 회원가입 등을 제외)
3. pc 웹페이지 규격으로 구성해야 하며 (이후 모바일, 태블릿 화면 추가. 즉 8 * 3 = 24페이지)
4. 와이어프레임 제작에 참여 가능한 팀원은 4명이다.
5. 그리고 페이지의 기능은 대략 정의했지만, 세부적인 배치나 UI는 이야기 해보지 않았다. (때문에 의논이 필요했다)
대략 이런 내용들을 떠올렸던 것 같다.
 
Figma로 작업하면 10시간을 넉넉하게 사용할 것 같았지만, 퍼블리싱을 하게 되면 작업 시간이 모자라지 않을까 하는 생각도 들었다.
 
그리고 문제가 된다고 생각했던 부분은
1. 10시간 안에 퍼블리싱 환경 구축부터 ui 라이브러리를 사용해서(다른 ui 라이브러리와 사용방법이 비슷하다면 크게 어렵지는 않을 것 같긴 했다), 클릭이벤트까지 가능할까?
2. 8페이지가 나올 것이고 UI가 합의되지 않은 상태인데, 하나의 화면을 보면서 4명이 코드작업을 한다. 가능한가?
    만약 2명 2명으로 나뉘어서 코드작업을 한다면 이렇게 구성한다는 통보식으로 작업하지 않기 위해 계속 소통이 필요할텐데 컨텍스트 스위칭이 작업 속도에 문제되지 않을까?
3. 퍼블리싱을 위한 작업을 하고(이벤트까지 적용하고) 버려진다는게 아쉬웠다.
 
그리고 일요일 오전에 회의를 했지만, 각자가 갖고있는 UI에 대한 생각이 모두 달랐기 때문에 다같이 모여서 작업을 하기를 팀원이 원했다.
 

이 뿐만 아니라, 모든 선택에는 trade-off가 있다.

1. PC, 태블릿, 모바일 모두 하는 것

2. 모바일 또는 PC에 집중해서 적합한 UX에 대한 상세한 페이지를 구성하는 것(PC와 모바일은 디테일한 부분에서 차이가 있다)

 

Figma, 누가 할 것인가?

팀원들은 지쳐있었다. 개발을 빨리 시작하고 싶은 분위기였고, 의견을 제시하고 결정하는 것에 시간을 많이 들여서 그런지 힘들어 했다.

의견이 모아졌던 페이지는 각 페이지마다 느낌이 달라서 UI 정리가 필요했지만, 모두 힘들어서 그런지 피그마를 정리할 여유가 없었다.

 

그래서 shadcn으로 정리해보겠다고 나섰다. 피그마를 조금 할 줄 알았기 때문에 shadcn ui로 느낌을 정리해나갔다.

9시간 쯤 걸려서야 24페이지가 다 만들어졌지만,

지금 생각해보면 그 다음날, 그 다음날도 UI 고민을 하고, 모바일 환경에 대해 더 고민을 하면 어땠을지 싶다.

 

팀 분위기가 쳐진다는 생각이 들면, 다같이 힘냈으면 좋겠다. 장난도 치고 같이 웃고

 

누군가를 탓하는 말은 조심해야 하는 것 같다.

의욕을 꺾기도 하고, 그 사람의 말로 다시 그 사람을 보게 되는 것 같아서.

작업 속도

페이지 갯수로 작업 속도가 늦다고 물어오셨는데,
open API의 데이터를 확인하고 기존의 웹페이지 배치도를 비교하며 작업했다고 말씀드렸다.
그리고 하나의 페이지에 레이아웃(정렬, 갭, 실제 컴포넌트라고 가정하고 텍스트 컴포넌트 간격도 조절 등)을 고려하며 작업했다고 말씀드렸다.
이유가 있는 배치를 하고싶었다.
 

Figma 잘 사용하는 방법 알려드리기

고객의 pain point 캐치캐치

 

디스코드에서의 클릭 소리

디스코드에서 마이크를 켜고 피그마 작업을 하는데, 클릭 소리가 클릭 클릭 클릭 클릭 클릭 계속 들렸다.
무슨 작업을 하고 있으신 중이신걸까? 궁금해서, 화면을 follow 했는데,
 
하나의 요소 위에서 마우스를 고정하신 채로 클릭 소리가 여러번 들렸다.
 
아하. 요소 안에 요소 안에 요소를 클릭하기 위해서 여러번 클릭하시는 것 같아서
[ctrl + 마우스 좌클릭]을 하면 안쪽 요소를 바로 클릭할 수 있다고 알려드렸더니 좋아하셨다ㅎㅎ
 
그리고 다른 분은,
 컬럼으로 정렬되어 있는 컴포넌트에 하나의 요소를 계속 요렇게 저렇게 배치하시는 모습을 봐서, 어떻게 하고싶으신지 여쭤봤다.
그랬더니 요소에 패딩을 넣고싶다고 말씀해주셔서 
요소 우클릭으로 프레임을 씌우고(Frame selection), 우측 사이드바에서 auto layout을 적용한 뒤, |ㅁ| 모양을 클릭하면 좌우패딩, -ㅁ- (?? 세로 정렬된 모습으로 상상....) 을 클릭하면 상하 패딩을 적용할 수 있다고 말씀드렸다.
잘 된다고 기뻐하셔서 뿌듯
 
내가 처음에 Figma를 했을 때 겪었던 내용이어서 더 빨리 알아차렸던 것 같다.
 

반복적으로 발생 가능한 문제 해결

1. main push
2. 일관되지 않은 PR 작성
3. ../../ 상대 경로 사용
 
main push
 local에서 작업했는데 main에 push하는 경우가 초반에 발생해서, 이를 방지하기 위해 husky pre commit에 main branch이면 push할 수 없도록 만드는게 어떨지 의견을 제시했다. 
 GitHub에서 gui로 직접 branch를 제한하는 방법이 있는지도 찾아보다가, local의 main에서 commit을 하지 못하게 하는 방법이 있었다. 해당 코드에 대해 짧게 의논했고 팀원분이 코드를 작성해주셨다.
 
일관되지 않은 PR 작성(+ issue template도 수정)
우리팀은 PR 템플릿을 사용하고 있었다. 하지만 템플릿이 있음에도 불구하고 일관되게 작성하지 못했던 부분이 있었는데 제목과 내용 부분이었다.
1. 제목
  (1) commit tag: [#issue번호]
  (2) [#issue번호]  commit tag: 
왜 제목에 대한 이야기를 꺼내게 되었는지 설명드렸다. 자주 사용되는 방법(1)은 PR안에 적힌 내용(2)와 달랐기 때문에 방법을 통일할 것을 제안드렸다.
 
2. 내용
- 제목에 대한 일관되지 않은 표기 방법
  - '어떤 기능인가요?'를 '기능 설명'으로 수정
- 부연설명은 주석으로 바꾸면서 view에 직접 드러나지 않도록 하되, 서술할 때는 어떤 내용을 적어야 하는지 리마인드 할 수 있게 바꾸었다.
- close #이슈번호의 위치
하단에 두는것 보다, 상단에 작업 내용을 서술하면서 같이 작성하면 이슈를 닫는 것을 잊어버리지 않을 것 같았다.
이후에, - 대쉬를 사용하면 '제목'이 같이 연동된다는 리뷰를 받고 완전 좋다~ 생각하면서 바로 적용했다.
 
대화를 중단하는 것보다, 해결 방법을 찾는 방향으로 대화를 하는게 중요하다고 생각한다.

우리가 해결할 수 있는 문제로 대화 이끌어가기

내가 주로 하려고 했던건
'문제'가 실제로 그렇게 '문제'라고 생각되지 않도록, 그리고 같이 해결할 수 있는 내용으로 말하고싶었다.
 
한 예시로 PR을 읽던 중, 디스코드 마이크를 켜고
"이전 PR에서도 같은 코멘트를 남겨주신 부분이 있는데, 혹시 어떤 차이가 있어서 절대경로로 import 되는 걸까요?"
와 같이 '우리'가 해결할 수 있는 문제로 말했는데

또 생각해보면 설정을 먼저 검색으로 찾아보고 화제를 꺼내는 것도 좋았을 것 같다.

 
무언가를 의논할 때 태도
특히 팀원이 불안해하는 경우 딱딱하게 접근하기 보다, 가벼운 농담을 곁들이는 것도 좋다고 생각한다.
이 때 내가 비슷한 Task를 (다른 프로젝트에서) 맡았을 때 어떤 경험을 했다면,
그 내용을 정리해서 발생 가능한 상황을 예측 가능하도록(눈에 보이도록) 제시하는 것도 좋다.
 
그리고 농담은.. 그때그때 다르지만, 초보자의 관점에서.. 충분히 할만한.. 방정맞을 수 있는 그런 개인적인 일화들을 언급했다. (종종 농담을 하는데 긴장감이 완화되는데 도움이 됐으면 좋겠다고 바라고 있다)
 
여기서 그치지 않고 이야기를 더 진행해보면 좋다.
내 이야기를 듣고 다른 생각들이 떠오를 수 있고,
내가 문제를 너무 복잡하게 접근했다고 생각한다면, 오히려 다르게 해결 할 수도 있을 것 같으니 라이브러리를 찾아서 적절한 근거를 준비해올 수도 있다. 그때 본격적으로 대화를 진행해도 좋지 않을까?

 
팀원을 설득하려면, 어떤 문제를 해결하기 위해 의견을 내려면 준비를 하자
우리 팀에 어떤 문제가 있다.
팀원들도 문제라고 인식할 수 있다. 하지만 아무도 말을 꺼내지 않는다면?
문제에 대해 이야기를 진행하려면 그 주제를 꺼낸 사람에게 어느정도 책임감이 주어진다(고 생각한다)
그렇다면 미리 준비를 하자.
1. '내'가 원인이라고 생각하는 근거
  - 공유된 곳에 정리하기(예: 노션)
2. '내'가 생각하는 해결책 제시
3. '팀원'들의 의견을 질문하고 해결책을 의논하기
 
타인의 말에서 '의도'를 '추측'하는 것을 배제하고 받아들여야 한다
의도는 왜곡되기 마련

 

UI 테스트가 필요하다

필요성을 깨달은 건, PR 코드리뷰와 컴포넌트를 나중에 수정했을 때
(다른 곳에서도 사용할 때동작이 같은지 점검하고 싶었다)

 

- StoryBook

- 테스트 코드

 

테스트 [장점]

1. 직접 눈으로 확인할 수 있다. (컨트롤러 동작 확인도 가능)

2. 어떤 상황에서 문제가 발생하는지 코드 단에서 설명이 가능할 것 같다.

 

3차 팀에서는 UI 컴포넌트 테스트를 따로 하지 않았다.

 

그런데 점점 컴포넌트를 만들고 PR 리뷰를 하면서

만들게 된 컴포넌트 UI를 직접 확인하는게 필요하다는 생각이 들었다.

 

첫번째로는 Icon 컴포넌트를 만들었을 때였다.

Icon 이미지를 확인할 수 있는 페이지가 없었다.

그래서 PR에 올라온 코드를 보고(?) 이미지를 확인(?) 했어야 했는데, 이 때 필요했구나 싶었다.

 

코드리뷰를 할 때 Icon을 하나씩 렌더링 하면서 실제 이름과 svg가 매칭이 되는지 확인해봤고,

Star과 FilterIcon의 svg 결과가 똑같아서 수정이 필요했다.

human error는 언제나 발생할 수 있는데

코드를 꼼꼼히 본다고 하더라도, 놓치는 부분은 어쩔 수 없이 발생하는 것 같다.

 

storybook은 이럴때가 아니라도 필요한데,

코드를 따로 작성해야 하는 번거로움이 있더라도 UI를 테스팅할 수 있다면 환경을 설정하는게 좋을 것 같다.

PR올려주신 화면의 테스트를 하면서, 리뷰로 예상하지 못했던 결과가 발생한 상황과 조건에 대해 말씀을 드렸다.

그 당시에는 열심히 조건을 나눠서 쓰려고했는데, 다시보니 어지럽다

그런데 질문을 주셔서 같은 상황을 다시 확인했을 때, 내가 적었던 내용대로 했음에도 같은 상황이 발생하지 않았다.
이상한데? 분명히 몇 번이나 맞는지 확인해봤기 때문에 내가 착각했던 건 아니었을텐데..
 
잘못 말씀드렸다면 팀원분의 시간을 빼앗은 것일 텐데 하는 생각에 정말 죄송한 마음이 들었다.
하지만 분명히 몇번이나 확인한 뒤 리뷰를 남겼기 때문에 침착하게 다시 확인했다.

알고 보니, 숨겨진 조건이 있었던 것.
적어두지 않았던 부분에서 문제가 발생했는데,
리뷰에 꼼꼼하게 작성했하고 생각했지만 놓치는 부분이 있어서 곰곰히 생각해봤다.
 
UI 테스트를 하는 내 행동을 하나씩 모두 기록해서, 팀원에게 설명해도 동일하게 이해할 수 있도록 하는 방법이 있을까?

글로 설명하면 빠지는 부분(조건)이 있는 것 같다.
만약. 테스트 코드가 있었다면 어땠을까?

 

깃허브 PR

- 1명만 approve 하면 merge 가능이라는 규칙을 정했다.

- 그런데, 내가 리뷰를 조금 늦게 작성했을 때 pending 상태에서 merge되면 아쉬우니까 눈 이모지를 붙이자고 제안했다.

- 리뷰를 누군가 작성해주기를 계속 기다리면 병목이 발생한다.

 

덧붙여서,

QA리뷰, 버그, UI(Figma와 다른 부분), UX 개선, 클린(?) 코드등 다양한데

가장 어려운 부분은 아마 설계인 것 같다. (SOLID 원칙? 함수형 프로그래밍? 추상화?)

그리고 생각보다 테스팅 리뷰도 노력이 들어가고 세심하게 읽어야 해서 쉽지는 않다고 생각하는데

다른 사람의 코드를 제때 읽는것도 중요한 것 같다. PR리뷰는 남기지 않더라도.

그리고 여기에 더해, 제대로 코드리뷰를 하지 않으면(코드를 읽어보지 않으면) 어마무시한 무언가가 되어 나에게 돌아올 수 있다.

나중에 프로젝트가 커졌을 때 .. 다른 사람이 작성한 코드를 사용하게 될 때가 오는데, 확장성이 가능한가, 추상화가 잘 되어있는가 등이 코드를 유지보수할 때 어렵게 만들 수 있다.

따라서 어떻게 개선될 수 있는지 간단하게라도 리뷰를 해보는 것을 추천한다. 내가 작성하지 않아도, 다른 사람의 코드에서 멋있게 작성한 내용을보면 배울 수 있다.

PR도 이력서 - 면접이랑 비슷하지 않을까?
 
질문과 답변. 
질문도 잘 해야 하고
답변도 질문을 기반으로 해야 한다. 질문을 잘 이해하지 못한 경우, 다시 물어보고 정확한 문제를 파악하려는 노력을 기울여야 하는데, 그게 쉽지는 않다. 본인이 정답이라 생각하는 내용을 그대로 말하기보다, 그 사람이 현재 어려워하는 상황의 입장이 되어서 같이 고민해야 한다.
 
가끔 이해가 안되거나 어렵다면 노트에 손으로 적어보거나, 노션등에 기록해가면서 이해를 따라가보자.
질문할 수 있는 내용도 적어두면서.
 
주의해야 할 점. 생각의 결론을 미리 만들어두고 논리를 구성하지 말자.

 

PR리뷰의 장점

다른 사람의 코드를 읽게 되는 일이다. 새로운 라이브러리를 쓰게 되는 경우 특히 적응하는데 시간이 필요한 경우가 있는데 그런 경우 팀원의 코드를 읽으면서 자연스럽게 n회독을 하게 되는 셈이 된다.

눈에 익숙해질 때까지 보면 처음엔 생소하더라도, 나중에는 이해할 수 있게 된다. (그 과정에서 문서도 찾아보면서.)

팀원들의 코드를 꼼꼼히 읽어보자

 

누군가 '어떤 질문'과 함께 '의견'을 물어보면, '좋다' '싫다' 표현 외에, 그 질문의 근본적인 내용을 되짚어보기도 하자.
- 이건 상대방에겐 도전적일 수 있다. 표현을 잘 해야 함.

- 그런데, 정말 때로는 필요하다.

- 어떤 질문을 받았을 때, 이게.. 맞나? 한번쯤 생각이 들었다면 언급은 하고 지나가야 한다.

- 말하지 않고 지나갔을 때, 나에게도 책임이 있다는 것을 기억하자.

 

상대방의 말이 이해하기 어렵다면, 노트에 적어보자.

- 질문이 떠오르면 적어놓고 질문할 타이밍에 해도 좋다.

 

디스코드

- 소리로 반응을 나타낼 수 있다. (짝짝짝, 두둥탁 등) 상대방을 격려할 수 있고 재밌다(나만?)

- 이모지로 반응하기 어려운 표정, 몸짓등을 나타내는 것도 좋다. 재밌다. 가만히 있는 것 보다 반응이 있으면 재밌당 희희

슬랙

- 따봉, 체크표시, 눈모양 다양하게 활용하자. 읽었다는 표시는 하면 정말 좋다.

 

컨벤션

영어 단어 통일

단어를 통일해보는 것도 괜찮을 것 같다.
[예시] '함께'라는 의미를 가진 accompany, together 등을 여러가지 단어로 표현할 수 있는데 팀 내에서는 어떤 단어로 사용하자는 규칙을 정하기 (wiki ?)

 

개선점 제시하기

케러셀 추가할 수 있는 부분

웹접근성에 따라

케러셀도 여러가지로 표현이 가능하다. 몇개 사이트만 돌아봐도 캐러셀을 다양하게 표현하는지 알 수 있고, 웹접근성으로 검색해볼수도 있다.

 

1. 캐러셀이 현재 어느 위치에 있는지 ○ ○ ○ ● ○ ○

2. 색 대비

3. 현재 위치 커서를 다른 모양으로 바꾸기

4. 현재 위치 커서를 애니메이션으로 표현하여, 앞으로 몇 초 동안 현재 섹션이 화면에 노출되는지 알려주기

5. 호버하면 케러셀 이동 멈추기