[Soft] 산타파이브의 월간코드리뷰 리뷰 (1)
사이드 프로젝트 한 번쯤은
컴퓨터공학과 학생이라면, 혹은 개발자라면 누구나 한 번쯤은 사이드 프로젝트를 해봤거나 할 예정일 것이다. 나도 몇 번의 사이드 프로젝트를 진행했었다. 만족할만한 결과가 있었을 때도 있고 중간에 흐지부지되었던 경험도 있다.
🎅 산타파이프 그들은
산타파이브는 작년 크리스마스 시즌에 🎄내트리를꾸며줘🎄 라는 이름의 사이트 프로젝트를 진행하였다. 사용자는 친구들에게 편지를 작성할 수 있고, 그 친구는 12월 25일 자정 이후에 그 편지 내용을 확인할 수 있다. 이 프로젝트는 250만명의 이용자들에게 3600만 건의 메시지를 배달하였다. 그야말로,, 엄청 성공적인 결과이다,,
산타파이브가 ‘탈잉’을 통해 해당 프로젝트를 회고하는 웨비나를 진행한다는 소식을 듣고 바로 참가 신청하였다. 해당 웨비나를 들으며 당장 나의 다음 사이드프로젝트에 적용시키고픈 내용들이 있었고, 이를 정리해보고자 이 포스팅을 작성한다.
사이드 프로젝트 시작하기
우선 사이드 프로젝트의 구체적인 내용에 앞서 소프트 스킬 과 팀빌딩 에 관련하여 설명해주신 내용이 있었다. 매우 공감가는 부분이 많았다. 그 중 첫 번째는,
각자의 목표 공유하기
‘각자의 목표 공유하기’ 이다. 사실 사이드 프로젝트를 진행하면서 흐지부지 된 경험이 굉장히 많다. 왜 그랬을까 생각해보면 각자에게 이 사이드 프로젝트의 의미가 너무 달랐는데, 그 부분을 ‘인지’ 조차 하지 못했던 것 같다. 각자 해당 프로젝트에 원하는 것이 무엇인지 공유해야 비로소,
🎄 각자 해당 프로젝트에 들일 수 있는 에너지가 어느정도인지,
🎄 그렇기에 서로에게 요구할 수 있는 정도가 어느정도인지,
파악할 수 있다. 다음에는 무조건 각자의 목표를 공유하고 시작하리라고 다짐했다.
그 다음으로 설명해주신 내용은 협업툴이다. 사이드 프로젝트를 진행하다보면, 필수적으로 협업툴을 사용하게 된다. 이 과정에서 내가 잘 몰랐는데 사용해볼 법한 협업 툴로 피그잼이 있었다.
협업툴, 피그잼!!
산타파이브 팀은 피그잼을 이용하여 유저 플로우와 와이어프레임을 기획했다고 한다. 또한 프론트엔드/백엔드 아키텍쳐도 이 툴을 이용하여 기획하였다고 한다.
몰랐던 내용 중 하나는 유저플로우 와 와이어프레임 이 구분된다는 사실이다. 항상 전체적인 와이어프레임만 기획했던 것 같은데 다음에는 유저플로우도 기획해봐야 겠다고 생각했다.
프론트엔드/백엔드기획에서 피그잼을 사용할 때는 어떤 컴포넌트들을 만들어야 할지, 만든다면 해당 컴포넌트가 뷰 컴포넌트인지 페이지 컴포넌트인지, 백엔드 유알엘은 어떻게 구성할지 등을 와이어프레임 자체에 기록했다고 한다.
싸워도 괜찮아!!
프로젝트를 진행하다보면 인간관계로 많이 스트레스를 받곤 한다. 당연히 의견 충돌이 있을 수도 있고 감정이 상할 수도 있다. 사실 개발자라면 누구나 이런 사실을 인지하고 있을 것이다. 나도 원래 알고 있었던 내용이고 그랬던 때도 많았는데, 이번 산타파이브 웨비나에서 하나 배운 내용이 있었다. 그건 바로,
싸워도 괜찮다는 걸 RULE 로 명시화하기
이다. 싸워도 괜찮다고 암묵적으로 인지하는 것과 RULE 로서 싸워도 괜찮다는 걸 명시해두는 건 매우 다르다. RULE 로서 명시되면 의견 충돌이 있어도 감정이 덜 상할 수도 있고 필수불가결한 내용이라고 인지할 수 있다. 산타파이브는 자주 충돌하고, 빠르게 사과하기 라는 RULE 을 갖고 있었다. 나도 다음 사이드 프로젝트를 진행할 때는 이와 같은 RULE 을 몇 개 정하고 가야겠다고 느꼈다.
프론트엔드
다음부터 프론트엔드 코드를 짤 때 다음 두가지 툴을 이용해야 겠다고 생각했다.
첫 번째는,
ESLint
로서 JavaScript 문법 에러를 탐지해준다.
두 번째는,
Prettier
로서 코드 포맷팅을 도와준다
위 두 도구를 이용하였을 때 장점은
- 형식적인 변화가 커밋되는 상황을 방지할 수 있다.
- 모두의 코드 작성 스타일을 통일 시킬 수 있다.
이다.
또한
Pull Request
를 읽기 좋은 단위로 만들었다고 한다. 나는 지금까지 특정 브랜치에서 단 한번의 풀리퀘스트를 보낸 후 브랜치를 닫았었다. 그러다보니 특정 기능을 추가하기 위해 만든 브랜치에서 모든 기능을 다 구현한 후 풀리퀘를 보내게 되었고, 생각보다 그 양이 많아질 때도 있었다.
읽기 좋은 단위로 풀리퀘를 만드는 게 아직은 어떤 의미인지 잘 모르겠다. 하나의 브랜치에서 여러번 풀리퀘를 보낼 수도 있을 것 같다.
우선 다음번엔 하나의 브랜치에서 여러번 풀리퀘를 보내는 걸 시도해 보아야겠다.
Leave a comment