개발자 안티패턴2 - "급하니까 나중에 고칠께요."

코드리뷰를 하다보면 정말 좋지 않은 코드를 많이 보곤 하죠. 이럴 때 '이것 제대로 고쳐주세요', 라고 이야기하면 가끔씩 들려오는 이야기가

 

"급하니까 나중에 고칠께요."

"일단 배포하고 수정할께요."

 

비슷한 부류로 이러한 케이스도 있죠.

 

"일단 배포하고 테스트 쓸께요."

 

이러한 상황이 많다면 근본적으로 다시 어떻게 일을 하고 있는지 검토가 필요할 겁니다. 아니면 혹시 주위에 이러한 개발자가 보인다면, 이러한 개발자는 온 몸에 시한폭탄을 두르고 다니는 개발자이기 때문에 좋은 길로 잘 인도해주거나 좀 거리를 두는 것이 좋을 것입니다. 그러면 이러한 개발자를 어떠한식으로 올바르게 성장 시킬 수 있을까요? 

 

먼저 어떠한 개발자들이 이러한 이야기를 많이하는지 대충 살펴보면:

(1) 정말 급한 요청을 처리하는 개발자: 오케이 인정, 이번은 봐주지만 매주 그러면 안 됨

(2) 마지막에 엄청 큰 코드리뷰를 올리는 개발자: 수능 공부를 하루전날 밤세워서 할 사람이지만, 개선 가능성 큼

(3) 게으른 개발자: 역시 개선의 여지는 있음. 개인적으로는 고집 쎈 것보다는 나음

(4) 고집 쎈 개발자: 말을 해도 못 알아들으니 그냥 같이 일하기 싫음

 

그러면 "급하니까 나중에 고칠께요"라는 말을 하지 않도록 어떻게 개선할 수 있을까요?

 

(1)번 케이스는 흔하게 발생하는 것 같지만, 그렇게 코드리뷰나 테스트 코드를 쓰지 못할정도로 급한 케이스는 한달에 한번도 많은 것이라고 생각합니다. 만약 한 달에 비슷한 케이스가 많이 일어난다면, 기본적인 코드 퀄리티와 개발 프로세스를 검토할 필요가 있습니다. 일단 지금 부터 나가는 코드에 대해서라도 테스트를 조금 더 쓰는 것에 신경 쓴다면 충분히 개선 될 수 있습니다.

 

(2)번이 제일 많이 발생하는 케이스인데, 개발 방법을 바꿔줘야할 필요가 있습니다. 하나의 큰 코드 리뷰보다는 하위 호환성을 고려한 짧은 코드리뷰로 여러 개 만들어내는 것을 연습하면 충분히 개선 가능합니다. 아직 경력이 많지 않거나 좋은 개발 환경에서 일해보지 못한 개발자분들에게서 많이 볼 수 있습니다. 하나의 코드리뷰나 커밋에 테스트나 환경설정 변경 이외 순수 로직 변경 코드가 파일 10개가 넘어가면 작게 나눌 수 있도록 고민해보면 좋습니다. 연습이 좀 필요할 수 있지만 작은 코드 개발 루틴이 습관이 되고 익혀두면 코드리뷰로 개선되는 코드퀄리티가 월등하게 올라가게 되고, 하위호환성 고려를 잘해두면 롤백할 때에도 리스크가 적습니다. 특히 하나의 큰 코드리뷰 자체는 이미 "되돌아갈 수 없는 강"을 건너가버린 것입니다. 되돌아갈 수 있게 디자인 논의/미팅 많이 하시고 코드리뷰도 프로토타입이든 

 

만약 세번 이상 비슷한 리뷰 커멘트가 달린다면 (3) 또는 (4)번에 해당하는 확률이 높으니 다시 한번 어떠한 커멘트가 달렸고 왜 그것이 고쳐지지 않았는지 되돌아 볼 필요가 있습니다. 참고로 비슷한 코드리뷰 커멘트는 다섯번 여섯번 달리지 않습니다. 리뷰어가 보통 그냥 포기하게 되거든요.

 

(3)번 유형 중에서 배우는데에도 게으른 개발자라면 성장 가능성이 매우 낮습니다. 언젠가 도태될 개발자입니다만, 게으름이 장점이 될 수 있는 분야에서 일하면 좋을 수 있습니다. 서비스 개발 말고도 CI / CD나 대쉬보드, 알람 등과 같은 것에 관심을 둔다면 팀에 가치를 가져올 수 있수도 있습니다.

 

(4)번이라면 언젠가 팀/회사 내에서 도태가 될 개발자죠. 사실 대화 몇 번 해보고 실제 코딩 실력을 보면 대충 각은 나오는데, 입만 살고 코딩 실력이 없으면 최악의 팀원입니다. 이러한 팀원으로 인하여 팀 분위기가 와해되고 뒷담화까지도 빈번하게 이루어지기도 합니다. 제발 이러한 개발자가 되지 마시고, 이러한 개발자가 있다면 피하세요.

 

 

따라서 가장 중요한 것은 개발자로서 언제나

 

- "고집을 버려야 한다"

- "누구에게나 배울 수 있다는 겸손한 자세를 가져야 한다"

 

는 것이라고 생각합니다. 경력 5년 이하의 개발자들은 쉽지만 경력이 5년이 넘어가면 이게 잘 안되는 개발자분들이 있습니다. 그래서 연차가 올라가면 피드백 내용에 대해서 다시 생각해보고, 다른 개발자들의 의견도 존중해주고, 대화하는 방식도 바꿔야하기도 합니다. 그게 어떻게 보면 다른 개발자를 성장시키면서 회사를 이끌어 나갈 수 있는 테크리드가 되어가는 과정이 아닌가 생각합니다. 이러한 되면 본인 뿐만 아니라 개발자들이 서로에게 배우는 분위기가 형성되어 결과적으로 팀 전체가 높은 수준의 개발 프로세스를 가질 수 있게 되기도 합니다. 개인의 관점에서도 배우는 것이 늘어나게 되고 자기 계발이 자연스럽게 따라오기 때문에 더 성공적인 개발자가 될 수 있지 않나 생각합니다.

 

그러면 다음에는 어떠한식으로 다른 개발자들과 생각하고 대화하면 좋을지에 대한 글 하나 더 써보도록 하겠습니다.

 

다음편: "개발자 안티패턴3: 정답을 단정짓지 말라"