🤔개발천재가 되려면 들여쓰기부터 잘하라고?

학부생 시절 좋은 코드라 함은 남들 10줄 쓸 코드를 2줄에 끝마치는 코드라고 생각했다.

흔히 백준 같은 사이트에서 알고리즘 문제 풀이를 봤을 때 최 상위에 올라간 그런 코드 말이다.

물론 그 부분도 중요하다. 하지만 그보다 더 중요한게 있다.

좋은 코드에 대한 관점을 바꾸다

2018년 여름 ICT 인턴을 통해 현재 재직중인 회사 개발팀에 들어오게 되었다.

당시 사수셨던 셀장님께서 내게 토이 프로젝트로 렌트카 예약 시스템을 만들어 보라고 하셨다.

(실무 투입에 앞서 내 코드를 보고 싶다고 하시면서... )

당연하게도 긴장 500% 상태로 프로젝트를 시작했다. 한 줄 한 줄 작성할 때마다 긴장의 순간이었다.

(코드에 어떤 알고리즘을 쓸까? 어떻게 써야 와 대단하단 소릴 들을까 등등 이런 생각 뿐이었다)

출처: mbc 무한도전

한 껏 힘을 주고 코드를 짜니 진도가 잘 나가지 않는 건 당연했다. 당시 학교 앞 자취방에서 출퇴근 하였는데 퇴근하고 학과 랩실로 가서 밤 늦게 코드 작성하기 일쑤였다. 집에 와서 간단히 씻고 쪽잠 자고 출근한 적도 몇번 있었다.

그렇게 겉멋만 잔뜩 들어간 토이 프로젝트 코드가 완성되었고 대망의 피드백 당일이 되었다. 피드백은 길지 않았다. 코드를 슥슥 보시더니 흠... 하는 소리와 함께

파트장님: 들여 쓰기가 잘 안 지켜져 있네 ?
개발자는 남의 코드를 보고 한눈에 파악 해야해.
들여쓰기는 기본이야. 개발자의 기본은 꼼꼼함 이야

나: 아.....

이번 토이 프로젝트로 보고자 한 건 화려한 코드 보다 협업 관점에서 얼마나 배려 있게 코드를 작성 했는지였다.

맥락을 짚어도 아주 잘못 짚었다는 생각이 들었고 치기 어린 행동을 한 내 자신이 부끄러워지는 순간이었다.

그렇게 실무는 전혀 다른 관점에서 생각해야 하는 걸 깨닫게 되었다.

결국 유지보수 싸움이에요

회사에 오기 전 스터디 활동을 했었다. 그때 만난 인연이 옆자리 프로님이다.(현 회사에서는 프로그래머직군을 줄여서 이름뒤에 000 프로님 이라고 부릅니다) 👉 https://velog.io/@undefcat

그때 프로님이 Clean Code 라는 하얗고 두꺼운 책을 보시길래 좀 멋져보였다. 그래서 나도 그 책을 구매했다.
그리고 카페에서 아메리카노 한잔을 시키고 패기롭게 책을 펼쳐보았다. '으... 먼소리야' 라고하며 채 2장을 보기도 전에 덮어 버렸다.

그래서 프로님한테 책이 좀 어렵다고하니 읽기 쉬운 코드가 좋은 코드다 라는 책을 추천해 주었다. 확실히 얇고 내용이 축약되어 있어서 끝까지 읽긴 했다. 근데 도통 남는게 없는 느낌이었다.

나 : 클린코드는 너무 노잼이었고, 두번째 책은 읽히는데 음 뭔가 책이 읽어도 머리에 하나도 안 남는거 같아요. 다들 좋은책이라고 하는데 왜이러죠?

프로님 : 그럼 아직 그 지식이 필요할 때가 아닌가 보죠. 어차피 필요하지 않을 때 공부 해봤자 다 날라 갑니다. 필요할 때 보세요.

그렇게 회사에 들어와 일을 하지 1년이 넘어 갈 무렵 다시 질문을 하게 되었다.

나 : 요즘 코드를 짜는데 이게 좋은 코드인지 확신이 서질 않네요.

마냥 코드만 날마다 짠다고 실력이 늘고 있는지도 잘 모르겠어요...

프로님 : 그때 클린코드랑 읽기 쉬운 코드가 좋은 코드다 가지고 계시죠? 지금 한번 보세요. 그런 고민이 들 때 보면 다른 느낌 일 거에요.

다시 책을 펴보니 정말로 그때 관심 없고 이해되지 않던 내용이 쏙쏙 들어왔다.

나: 오 진짜 그렇네요!

프로님 : 그쵸? 저도 그런 고민일 때 책을 사서 봐서 재미있게 본거 같아요. 그리고 결국 개발이란게 결국 유지보수의 싸움이에요. 그런 관점에서 바로 코드 보면 생각해야 할게 많을 거에요.

맞는 말이다. 생각해보면 객체지향이니, 함수형 프로그래밍이니 패러다임의 뿌리는 결국 유지보수다.
코드는 한번 쓰고 마는게 아니다. 협업을 할 수도 있고 내 손을 떠나 후임자가 만질 수 도 있다.

물론 보안, 메모리 최적화 관점에서 더욱 다양한 코드 기준이 있겠지만
좋은 코드의 기본은 결국 유지보수의 관점에서 이루어져야 한다고 생각이 들었다.

그래서 개발 시간을 측정할 때 개발시간과 더불어 +코드청소시간(리펙토링)도 확보 해야함을 알게 되었다.

후임자를 배려 하는 마음으로

대부분 이 사실을 알지만 현실에서 지키기가 참 어렵다.

변수명 짓기, 함수 이름 짓기도 나름 영어에 대한 지식이 받쳐 주어야 한다. 공부할 시간이 필요하다.

그리고 코드를 짠 시간 만큼 코드 청소시간을 확보하기도 녹록지 않다. 업무 특성상 어떤 변수가 생길지 모르고 그에 맞춰서 개발기간은 더더욱 짧아지게 된다. 다들 급하게 요청 온 작업을 하느라 정신없이 코드를 짜고 바로 커밋한 경험이 있을 것이다.

결국 코드를 짤 때 앞으로 누가 내 코드를 만질 수도 있다는 기준을 항상 상기하고 문서화를 잘 시켜 주어야 한다.

• 에디터 플러그인 단축기를 이용해 들여쓰기를 맞춰주자 (각 에디터 플러그인에 beautify 키워드로 검색해서 가장 많이쓰는 걸 쓰자)
• jsDoc, phpDoc, javaDoc 같은 명세 주석을 잘 달아 준다. 복잡하거나 앞으로 여지가 있는 부분도 꼭 주석으로 남겨준다.
• 변수명이나 함수명 짓기에 도움 되는 사이트를 즐겨찾기 해놓고 잘 활용한다.
• 기획, 설계, DB 명세서 등 문서들을 잘 정리 해둔다.
• git과 같은 버전관리를 쓴다면 커밋 메세지를 잘 정리한다.

이렇게 부분만 지키더라도 미래의 나 혹은 후임자에게 많은 도움을 줄 수 있다.

만약 코드 청소 시간이 확보 되었다면 클린 코드와 같은 책을 읽고 정리해 두었다가 적용해 가며 좋은 코드에 대해 내재화 하면 된다.

• 함수는 한가지 기능만 하기
• boolean 값은 매개변수로 받지 말고 두 함수로 나누기

등등 유지보수 관점에서 선택해서 적용하면 된다.

사실 말은 쉽고 행동은 어렵다. 하지만 조금만 이타적인 마음을 내면 그렇게 어려운 일도 아니다.