협업 프로젝트
실수를 대하는 자세
- 실수는 예방하는 것이 아니라 관리하는 것이다.
- 산불 예방?
- 산불이 절대 안나게 할수는 없다.
- 생태학에서는 불을 인위적으로 억제하면 오히려 그 지역에 가연성 물질이 과도하게 축적되어 한번 산불이 나면 엄청난 규모로 불이 날 수 있다고 설명한다.
- 실수를 아예 하지 않을수는 없다. 누구나 실수를 한다.
- 실수를 조기에 발견하고 빠른 조치를 취하는 것이 중요하다.
- 실수에 대해서 학습을 통해 “다음에 행동할 때에는 이렇게 하자” 는 계획을 세운다.
- 실제로 실수
관리
>예방
인 회사일수록 수익성이 더 높다. - 실수가 없으면 학습하지 못하기 때문
- 실수하지 말라고 하는 조직은, 학습하지 말라고 지시하는 것과 같다.
- 코딩테스트
테스트케이스
를 생각해보면…
- 동등한 관계일수록 실수를 공유하고 함께 배우기 쉽다!
하나의 프로젝트에서 최대한 많은 지식을 얻어가자!
- 각자 구현한 기능, 사용한 기술, 겪었던 어려움은 최대한 공유하자
- 기술면접에서 프로젝트 질문을 한다.
- 나는 로그인 기능 구현을 담당하지 않았는데, JWT 질문을 하시네?!
- 정기 회의 안건에 이 부분을 넣어서, 주기적으로 공유하는 시간을 가지면 좋을듯
- 학습을 하는 모임이기 때문에 / 회사에서는 이런 제안을 하기 어렵다.
회사에서 사용하는 협업 방식
좋았던 부분
- Github 기능 활용
Issue
→Branch
→PR
→코드리뷰
→Merge
→브랜치 삭제
- 이슈/PR 템플릿 활용
- Pull Request 와 코드리뷰
- Github
Action
을 이용한 CI(Continuous Integration) 관리
- 세세한 문서화 작업 (Notion)
- 매일 Daily Scrum 작성
- 매주 1회 정기 배포 (Goal)(생성성)
- 매 프로젝트마다 정해지는 프로젝트 리더
아쉬웠던 부분
- 개발 기간의 빠듯함
- PR을 자주 날리고 코드리뷰를 받는 것이 어렵다
- 기능 개발 우선시 → 리팩토링 후순위
- 시간 관리의 중요성 → 우선 순위를 잘 세워야
- 세부 기획/디자인과 동시에 진행되는 개발 : 잦은 수정에 따르는 어려움
- 기능들 간의 높은 결합도
- 기능별로 Issue를 만들고 PR 날리는 것의 어려움
- 분업의 어려움