지금 회사는 코드리뷰 시스템이 있고 리뷰어들의 승인이 있어야 올라갈 수 있는 시스템인데요. 즉 다른 사람의 코드를 읽고 이에 대해 생각할 수 있는 능력. 코드의 오류나 논리적 오류들을 파악할 수 있는 능력이 매우 중요합니다.
그런데 비단 코드리뷰 뿐만이 아니라 기획 회의를 들어가거나 디자이너와 협업을 할 때에도 무슨 문제점이 없는지 어떤게 필요한지 이를 파악해서 자신의 의견을 내는 것은 매우 중요합니다.
애석하게도 대한민국의 교육을 겪어온 사람들이라면 보통 이런 문화가 익숙하지 않습니다. 일단 자신의 생각을 논리정연하게 말하는 것도 어렵습니다. 게다가 보통 일단 다른 사람의 의견을 비판하거나 적극적으로 개진해 본 적이 없기 때문에 특히나 더 어려워한다고 생각합니다.
‘쓸데없는 말을 하는 거 아냐?’, ‘이런 말을 하면 무시당하지 않을까?’, ‘이런것까지 물어봐야 하나?’, ‘이런말하면 기분나쁘지 않을까?’ 라는 생각이 먼저 들기 때문이죠.
저 역시도 제 의견을 자신있게 말하는데 어려움을 겪는 편이고, 코드리뷰를 어떻게 해야 잘 할 수 있는지 알면 알수록 어렵습니다.
그래서 저처럼 경험이 없는 사람들을 위해서 한 가지 팁을 공개하고자 합니다.
기획서나 코드는 무조건 틀렸고 절대 받아들일 수 없는 것이라고 생각해라
뭔가 좀 부정적이고 독불장군 같은 태도이지만 오히려 이런 자세를 가지는 것이 오류를 찾는 힘을 길러줍니다.
회사 임원이 가지고 있는 능력 중 하나는 어떤 기획서나 제안을 했을 때 그 자리에서 그 제안이 통과될 수 없는 이유를 10가지 이상 말하는 것이라고 합니다.
만약 임원이 OK한 프로젝트가 사실은 나 자신의 커리어를 무너뜨릴 수 있고 더 나아가 회사에 큰 문제를 일으킬 수 있다면 어떨까요? 즉 임원은 자신이 책임져야 할 업무가 많기 때문에 보수적으로 접근하는 편인데, 아마 큰 회사일수록 이런 능력을 가진 사람이 필요하기 마련입니다.
코드도 마찬가지입니다. 만약 팀원이 올린 코드 중 일부가 빌드를 fail하게 만들거나 전체 서비스를 망가뜨릴 수 있다면 어떻게 해야 할까요? 샅샅이 찾아내서 그 코드를 제거해야 합니다.
코드에 문제가 없겠지라는 접근방식보다 보수적으로 접근해서 PR을 받아들일 수 없는 이유를 찾아내는 연습을 해보는 것이 중요합니다.
기획회의를 들어가더라도 마찬가지입니다.
상대방을 배려한다고 ‘아 괜찮아요’ 말하기 보다 이 기획이 통과되면 안되는 이유를 찾아보세요. 눈에 보이지 않던 문제들이 하나씩 보일겁니다.
- 이 위치에 버튼을 넣게 되면 유저들이 불편해 하지 않을까요?
- 지금 시점에서 이 기능을 넣는 것은 로직을 바꾸어야 하는 부분이 많아 개발 소요가 많이 필요합니다.
- 여기서 뒤로가기 버튼을 클릭할 경우엔 어디로 가야하죠?
- 모바일 버전 기획과 데스크탑 버전 기획의 레이아웃이 너무 달라서 반응형으로 만드는 시간이 오래 걸릴 것 같은데요. 개발 소요가 적도록 레이아웃을 변경하는 건 어떨까요?
생각보다 많이 발견할 수 있습니다. 적극적으로 기획의 문제점을 찾아보세요.
특히나 기획회의에서 나온 내용들은 결국 개발자가 만들어야 되기 때문에 그 기획에서 오류를 찾아내는 것은 굉장히 중요합니다.
잊지마세요. 그 자리에서 눈총을 받으면서 말하는 것이 나중에 실제로 서비스를 개발할때 욕먹는 것보단 낫다는 것을.