21.12.26 코드스테이츠 2주차 First Project 회고록

👀  2주차 First Project 회고록

 

📌  2주차 첫 번째 프로젝트의 시작 

 

팀원 모두 "첫" 프로젝트 경험이다 보니 배운 걸 복습하면 된다는 가벼운 생각으로 임했다.

그런데 아이디어 이야기를 하면할수록 큰 가닥이 잡히고, 해낼 수 있겠는데 ..? 라는 용기가 생겼다.

스토리 라인을 탄탄히 짰고 업무 분배도 기간에 맞춰 계획했다.

모두들 할 수 있다는 자신감에 부푼 채 프로젝트를 시작했다.

 

 

📌  우리팀이 잘한 점 

 

📎  팀프로젝트와 직접적으로 관계없는 내용의 질문이더라도 팀원 모두가 함께 고민했다.

 

프로젝트를 하면서 대화의 생산성과 상관없이, 대화 자체를 많이 해야한다는 것을 느꼈다.

팀 프로젝트에서 빠질 수 없는 "GitHub 관리" 를 예로 들어보겠다.

 

우리 팀은 깃허브를 대화 주제로 삼았을 때,

 

✔ Git commit message 의 표준이 정해져 있는 "이유"는 무엇인가

✔ 태스크 카드는 어떤 "기준"으로 잘게 혹은 크게 나눌 것인가

✔ Git branch 가 나뉘면서 "어떤" 일이 발생하는가

 

등, 정말 궁금한 부분들을 거리낌없이 질문하고 답변했다. 

당시에는 이런점들까지 고민할 필요가 있나 싶었지만, 2주가 끝나고 보니 큰 프로젝트를 시작하기 위한 밑거름이 되어 있었다.

 

📎  맡은 업무가 끝났을 때에도 다른 팀원에게 진행 상황을 묻고 돕는 걸 당연하게 여겼다.

 

SR 기획대로 흘러가면 좋으련만. 예상치 못한 변수들이 많았다.

이때 "도울 게 있으면 말해주세요" 라는 말 한 마디가 큰 힘이 되었다.

모두 최선을 다하고 있다는 걸 알기 때문에 서로 돕겠다는 말이 나왔던 것 같다.

 

 

📌  우리팀이 개선할 점 

 

📎  정해진 시간을 고려하지 않고 무리한 계획을 세웠다.

 

"앱의 확장성"을 "기획의 크기"로 착각했던 게 아닐까.

나중에 리팩토링하면서 기능추가해야지 !! 단순하게 생각했다. 내가 의도한 목표는 클린 코드였는데 말이지 ..

그런데 전체 그림이 크다보니 점점 부담으로 다가와서 조급함을 항상 가진 채 코드를 짰었다. 😂

완벽한 기능 하나 구현해내는 게 중요하다 ...!!!! 욕심부리지말고 코드의 질을 생각하자 !!!!

 

📎  체력을 관리하는 루틴을 지키지 못했다.

 

4주 프로젝트 들어가기 전에 무리하지 말라는 선배들의 조언을 많이 들었다. ㅎㅎ 그게 마음대로 되나요 ..

미리 체력이 방전되는 걸 방지하기 위해 저녁시간 이후에 1시간을 체력 관리 시간으로 빼놨었다. 

그런데 다들 해결되지 않는 문제를 고민하느라 이 시간을 온전하게 채우지 못했다 ㅠ 

 

게다가 나는 팀원들에게 체력 관리로 일관된 피드백을 받았다 ... 완전 경고장 🧨

 

개인적인 만족도를 채우려고 팀원들에게까지 밤샘을 강요하진 않았는데 그런 내가 안쓰러웠나보다 

오늘 내일만 하고 말 거 아니니 체력관리 하라는 팀원들의 충고가 고마웠다 ㅠ 감사합니다 !

 

 

📌  개인적인 회고 

 

📎  모두의 코딩 실력은 다르다. 코드에서 당연한 건 없다.

 

프로젝트 기획에 앞서 간과한 사실이 있었다. 바로 서로의 코딩 실력을 모른다는 점이었다.

"할 수 있을 것 같다"와 "할 수 있다"는 엄연히 다른데, 중간 지점을 찾지 않고 시작했던 게 화근이 되었다.

스스로의 실력을 객관적으로 파악하는 것도 개발자로서 중요한 능력임을 깨달았다.

 

또 새롭게 안 사실 중 하나는, 나 스스로 '웹이라면 당연히 이래야지' 리스트를 정해 놓고 있었다.

 

✔ x축 중앙정렬은 되어있어야지.

✔ 반응형을 위해서는 vw, vh 속성을 활용해야지.

✔ margin 과 padding 은 최대한 지양해야지.

....

 

등등 혼자 정해놓고, 팀원과 소통할 때 지켜지지 않은 항목이 있으면 답답해했다.

나에게 당연한 것들이 있듯 상대방에게도 당연한 항목들이 있다고 생각하니

대화를 더 자주, 더 넓게 하게되었고 커뮤니케이션 상의 오류가 훨씬 줄어들었다.

👩🏻‍🦰  : 저는 css에서 margin과 padding으로 레이아웃을 잡는 건 지양하는 편인데 어떻게 생각하시나요 ?
🧒🏻 : 음, %나 em같은 상대적인 단위가 있으니 괜찮지 않을까요 ?
👩🏻‍🦰  : 상대적인 단위로 레이아웃을 조정하고 싶으신거라면 vw나 vh 같이 사용자가 보는 화면의 비율에 따라 값을 지정해줄까요 ? %와 em 모두 부모 엘리먼트의 속성에 영향을 받아서요 !
🧒🏻 : 그럼 부모 엘리먼트에 100vw, 100vh 속성을 주고 자식 엘리먼트에는 상대적인 비율로 조절하면 될까요 ?
👩🏻‍🦰  : 그 방법이 편하시다면 그렇게 하셔도 됩니다 ! 만약 중앙정렬을 하시거나 원하는 자리가 있으시다면 flex나 position 같은 속성들 찾아보시면 좋을 것 같아요 : )

 

다음번엔 기획 단계에서 프로토타입을 짤 때

각자 고수하던 css 코드 방식이나 html 구조 등을 공유하는 시간을 가지면 좋을 것 같다.

 

📎  프로젝트의 진척도를 객관적으로 확인할 수 있는 issue 탭을 자주 보자. 내것만 보지 말고 !!

 

프로젝트에 앞서 git flow 영상, git cli 영상 등을 보며 git을 학습했다.

혼자 Today I Learned repository를 운영하면서 뚝딱이긴했어도 팀이 같이 하나의 repository를 사용하는 건 처음이었다.

브랜치를 나누는 것도 처음, 태스트 카드를 쓰는 것도 처음, pull request를 보내고 merge 하는 것도 처음이었다.

혹여나 브랜치가 망가져 다른 팀원에게 피해가 갈까

 

✔ branch 나누기 - task card 적기 - 코드 작성 - pull request 보내기 - merge 하기 - pull 받기

 

이 과정은 교과서 처럼 지켰던 것 같다.

 

그래서인지 태스크 카드는 "의무적으로 작성"만하고 프로젝트 진행률을 파악하는데에 쓰질 못했다.

끝나고 보니 너무 개념적으로 나눠놔서 언제 이 일이 시작됐고 끝났는지, 또 얼마나 걸렸는지 파악하기 어려웠다.

git issue 탭을 보면서 팀플이 가능한 상태여야 하는데

다른 팀원이 무슨일을 하나 직접 물어보는 형태가 많았기에 이런 부분에서 일의 효율이 떨어지지 않았나 싶다. 

 

본인 일의 흐름은 크게크게 잡아놓되 (ex.1주/3일 단위로)

태스크 카드는 잘게 나눠서 상황에 맞게 써야한다는 것을 깨달았다.

-> 팀원이 내 태스크 카드를 보고 진행 상황을 파악할 수 있게 !!!

 

"태스크 카드를 잘게 나눈다는 의미 자체가 본인의 역량과 수행도를 잘 파악하고 있다는 뜻"이기 때문에 더 크게 다가왔다. (조금의 변명을 해보자면 인생 첫 개발 팀플이라 내가 이 일을 얼마나 빠르고 바르게 처리할 수 있는지 몰랐 ...)

 

그리고 추가적인 업무가 생기면 바로바로 태스크 카드를 작성해서 반영하자 !!

사실 이 작업은 꽤나 번거롭다. 코드 작성하기도 바쁜데 해야 될 일을 양식에 맞춰 to do list를 작성해야한다니 ㅜ

그치만 코드를 짜기 전 내가 해야할 일들을 한번 더 확인할 수 있었고 하루의 목표가 명확해지는 느낌을 받았다.

공부 시작하기 전에 다이어리에 "오늘 해야될 일" 체크리스트를 만들어 놓는 느낌이랄까.

그래도 hotfix 남길때 태스크 카드 쓰는 건 너무너무 번거롭다 ....

 

다음번 팀플에는 팀원들끼리 태스크 카드를 꼼꼼히 나눠서 진행해보고 싶다 !!