정성스러운 장문의 질문을 받았습니다.
정성스러운 질문엔 정성있는 답변을 해드려야 하는 법,
열심히 작성해서 보내드렸더니 써놓은 글이 좀 아까워져서 글로 살짝 정리해봤습니다.
어디까지나 저만의 주관적인 생각인 점 감안하시고 읽어주시면 감사하겠습니다.
질문
4월부터 일을 시작한 신입입니다.
iOS 개발자는 저 포함 두명이며 한분은 사수이자 앱팀 팀장님이십니다.
간간히 개발은 하시지만 개발 외적인 업무가 많아 새로운 기능을 만들거나 프로젝트를 진행하는 것 자체는 저 혼자 진행하고 있습니다.
모든 프로젝트에 아키텍처가 적용되어 있지 않고 협업 컨벤션이나 협업 룰이 전혀 없는 상태입니다.
그렇기 때문에 제가 진행하는 새로운 프로젝트부터 아키텍처와 개발 문서, 히스토리를 미흡하지만 만들어가고 있는 중입니다.
고민되는 점은,
현재 회사에 계속 있게 된다면 지금부터 좋은 팀 문화와 좋은 품질의 코드, 협업 프로세스를 만들어 가고 싶습니다.
또한 여기서 얻을 수 있는 경험을 통해 이직을 해야할 때에도 저의 이점으로 만들어가고 싶습니다.
그렇기 때문에 지금 상태에서 제일 먼저 만들어가야 할 기반은 어떤것이 될지 궁금합니다.
가장 먼저 적용한 것은 깃 컨벤션을 적용해 커밋 메세지, 브랜치 관리, PR을 통한 히스토리 아카이빙을 만들어 가고 있습니다.
그리고 노션을 통해서 간단히 프로젝트 별 업데이트 상황과 이슈를 정리하고 있습니다.
여기서 그 다음에 준비하면 좋을 것이 무엇일지, 또는 이것보다 더 중요한 것이 무엇인지 궁금합니다.
답변
4월부터 일하셨으면 이제 두달 남짓 지나셨을텐데요.
아마 기대하셨던 모습이 아니여서 실망하셨거나 불안하셨던거 같습니다.
그래도 갈증을 느끼고 이런 저런 시도를 하시는 점은 분명 앞으로의 성장에 큰 발판이 되실껍니다.
지금 님이 어떤 능력을 얼마나 가지고 계신지 제가 알 순 없지만,
신입개발자로서 지금 제일 중요한 건 개발 능력이라고 생각해요.
일단 뭐든 만들 수 있는 기초와 기술적 기반들을 갖춰야 ‘협업’이라고 부를 수 있는 일련의 활동을을 해볼 수 있지 않을까요?
혼자 사용하는 컨벤션과 브랜치 전략은 같이 일하는, 또는 일할 동료들에게 어떤 도움이 될지 모르겠습니다.
저라면 커밋메시지, PR규칙, 프로젝트 히스토리등을 정리하기 보다,
변수 이름은 내 의도를 제대로 담아냈는지,
단일 역할 단위로 함수들을 분리했는지,
비지니스 로직에 대한 프로토콜은 제대로 정리했는지 등의
SOLID 원칙과 코드 가독성에 대한 정리를 더 우선시 할것 같습니다.
명확한 의도와 역할대로 나눠지고 정리된 함수들은 어떤 아키텍처를 적용하더라도
그저 어느 파일에 어떤 클래스나 구조체에 담겨있는지만 달라질 뿐 그 핵심이 달라지는 것은 아니라고 생각해요.
변화에 유연하게 대응하는 방법은 결국 원칙에 따라 잘 정리된 코드들뿐이라고 생각합니다.
함께 일하는 사수분이 바빠서 개발에 제대로 참여하지 못하신다면,
코드리뷰라도 적극적으로 요청드리면 어떨까요?
이미 만들어진 코드들 중 참고 할 수 있는 부분이 어딘지 여쭤보고 코드 스타일을 모방하듯 본인의 코드를 작성해보세요.
개선할 수 있는 부분이 있다면 개선해보세요.
그리곤 코드리뷰를 통해 의견을 주고 받고 함께 결론을 도출한다면,
그게 곧 컨벤션입니다.
요약하자면, 결국 조직의 운영방침들보다 개인의 개발방식들을 확립하는데에 더 집중하자는거죠.