개발자로서 커리어를 시작하며, 개발 문화를 체험하고 공부하며 느꼈던 점을 공유하고자 합니다.
0. TL;DR
- 당신의 코드에 의문을 가지는 것은 당신에게 의문을 가지는 것이 아닙니다.
- 코드 리뷰는 코드를 리뷰하는 것이지, 당신을 평가하는 것이 아닙니다. 기분 나쁘게 생각할 것이 아니라, 만일 리뷰어와 다른 생각을 가지고 있다면 치열하게 토론하고 더 좋은 코드를 만들어 나가세요.
- 컨벤션은 왜 지켜야 할까요?
- 컨벤션은 코드를 읽고 유지보수하는 데에 있어서 엄청난 시간을 절약해 줍니다. 더불어 코드를 작성하는 데에 있어서도 팀원들과의 협업을 원활하게 해 줍니다.
- 타 직군도 사람이에요 사람!
- 협업은 개발자끼리만 하는 게 아닙니다. 디자이너, 기획자, 마케터, 영업직원 등등 모든 직군은 서로 협업을 하며 프로덕트를 만들어 나갑니다. 서로를 존중하고 배려하며 상대방이 충분히 이해할 수 있는 언어로 협업을 진행합시다.
1. 당신의 코드에 의문을 가지는 것은 당신에게 의문을 가지는 것이 아닙니다.
부트캠프에서 개발을 배우며 여러 사람들과 함께 협업을 진행했고, 깃허브를 통해 서로 코드를 리뷰하며 프로젝트를 완성시켜 나갔습니다. 그러던 중 다른 사람의 코드에 사소한 문제점을 발견하였고(당시 코드의 전체 맥락을 읽고 이해하지 못하면 알아볼 수 없는 변수명을 사용하고 있었다.) 코드를 작성하며 모두가 알아볼 수 있는 변수명이 더 좋다고 생각해, 수정 요청을 하였습니다. 하지만 그 코드를 작성한 사람은 이를 기분 나쁘게 여기며 더 이상 리뷰를 받아들이지 않고 더 이상 원활한 협업이 진행되지 않았습니다.
다른 직군(특히 수직적인 문화가 많았던)의 일들을 오래 했던 나로써 개발직군의 문화는 모두 생소했지만 그 중에서도 가장 독특했던 문화는 동료들끼리 연차, 직급과 상관없이 서로가 작성한 코드를 리뷰해주고 수용하는 문화였습니다.
개발자로서 근무하며 공부는 필수적이고 (물론 현실에 안주하겠다면, 더 이상 공부하지 않고 그저 그런 개발자로 살아남는 선택을 할 수도 있습니다.) 그 공부의 양과 깊이가 엄청나기 때문에 모르는 분야는 있을 수밖에 없습니다. 극단적인 예로 react팀의 멤버이자, redux의 창시자 Dan Abramov조차 자신이 모르는 것이 많다고 이를 인정하고 있습니다. 해당 블로그
인간이란 언제나 본인의 관점에서만 생각하게 되기 때문에 본인이 겪어온, 그리고 공부한 양과 깊이에 따라 같은 동작을 하는 코드라도 엄청나게 다른 코드를 작성할 수 있게 됩니다.
이를 상호보완하기 위해 다른 관점을 가진 사람들끼리 서로의 코드를 리뷰해주고 보완해 나가며 좋은 케이스가 있다면 공부하고 잘못된 케이스가 있다면 바로잡아주며 공동의 프로덕트를 완성시켜 나갑니다.
위의 사례처럼 코드 리뷰를 감정적으로 받아들이게 되면 코드 리뷰를 통해 더욱 좋은 프로덕트를 만들게 되는 것이 아닌 오히려 협업을 방해하는 요소가 되어버립니다. 팀간의 공동의 목표를 가지고 더욱 좋고 오래 유지할 수 있는 프로덕트를 만들기 위해 코드 리뷰를 진행하는 것입니다. 코드 리뷰를 통해 작성자에 대한 비난을 하거나, 자신의 코드에 대한 비난을 받는 것이 아닙니다.
2. 컨벤션은 왜 지켜야 할까요?
회사에 입사해 가장 먼저 한 일은 레거시 코드를 읽고 분석하는 일이었습니다. 코드를 읽으며, 코드의 컨벤션이 없다는 것을 느꼈습니다. 변수명은 물론이고, 함수명, 파일명, 폴더명까지 모두 다른 컨벤션을 가지고 있었습니다. 이는 코드를 읽는 데에 있어서 엄청난 시간을 소모하게 만들었고, 더 이상 코드를 읽는 것이 힘들어졌습니다.
컨벤션은 코드를 읽고 유지보수하는 데에 있어서 엄청난 시간을 절약해 줍니다. 코드를 읽는 데에 있어서 변수명, 함수명, 파일명, 폴더명 등등 모두 컨벤션을 통해 어떤 역할을 하는지, 어떤 의미를 가지는지 한눈에 알아볼 수 있게 됩니다. 또한 컨벤션을 통해 코드를 작성하는 데에 있어서도 팀원들이 서로의 코드를 더 쉽게 읽을 수 있게 됩니다.
컨벤션을 지키지 않은 코드를 읽다보면 변수명이나 함수명이 무엇을 의미하는지 또 다른 의존적인 코드를 읽어야 하고, 이를 반복하다보면 엄청난 시간이 낭비되게 됩니다. 개발이라는 일의 특성상 과거의 누군가가 작성했던 코드를 읽는 시간이 많아지게 되고, 내가 작성한 코드 또한 미래의 누군가가 읽게 될 것입니다. 서로를 배려해 컨벤션을 지켜 코드를 작성하고, 모두가 읽기 쉬운 코드를 작성합시다.
만일 팀에 코드 컨벤션이 없다면, 팀원들과 상의해 함께 커뮤니티 컨벤션을 베이스로 회사의 실정과 맞는 코드 컨벤션을 만들어 보는 것은 어떨까요?
3. 타 직군도 사람이에요 사람!
부트캠프에서 프로젝트를 진행할 당시, 디자이너와 FE팀과의 소통에서 가장 힘들었던 부분은 서로 프로덕트를 바라보는 방향이 다르다는 점이었습니다. 디자이너는 디자인을 통해 사용자가 어떤 경험을 할지를 중점으로 생각하고, FE팀은 디자인을 통해 사용자가 어떤 기능을 사용할지를 중점으로 생각했습니다. 이는 서로의 입장에서는 당연한 것이지만, 상대방의 입장에서 생각하려 하지 않았습니다.
프론트엔드 개발자로 프로젝트를 진행하며 수많은 타 직군의 사람들과 교류하고 협업하게 됩니다. 같은 개발직군인 백엔드 개발자 뿐만 아니라, 디자이너, 기획자 등 하나의 프로덕트를 만들기 위해 다양한 직군의 사람들과 협업하게 됩니다.
이때 가장 중요한 점은 프로덕트를 같은 눈으로 바라보고, 서로 부족한 부분들을 함께 채워주는 것이 아닐까요? 필요한 점이 있다면 상대방이 납득할 수 있는 이유를 가지고 설득하고 서로의 관점을 존중하며 협업하는 것이 중요합니다. 특히나 개발자로써 타 직군의 사람들에게 요청할 때 가장 중요한 점은 나의 의견을 어려운 전문 용어를 사용하여 뒷받침하는 것이 아닌, 상대방이 충분히 이해할 수 있는 언어로 설명하고 요청하는 것입니다.
학창시절 우리 모두 부모님이 책을 펴고 공부해! 라고만 말씀하셨을 때, 우리는 부모님의 말씀을 듣지 않았을 것입니다. 하지만 부모님께서 우리가 공부를 해야하는 이유를 충분히 납득 가능하도록 설명하셨다면, 이를 듣지 않고 공부를 안할 이유가 있었을까요? 타 직군의 사람들에게 요청할 때에도 마찬가지입니다. 상대방이 충분히 이해할 수 있는 언어로 설명하고 요청합시다.