세상에 나쁜 코드는 있다.
나쁜 코드
책에서는 나쁜 코드 이야기를 꺼내며 80년대 후반 킬러 앱을 개발한 한 회사를 소개한다. 빠른 출시를 위해 마구잡이로 짠 코드로 인해 결국 망해버린 회사였다. 이렇게 극단적이지는 않으나 비슷한 사례를 우린 꽤 가까이에서, 자주 찾아볼 수 있다. 10년이 넘은 회사의 레거시 코드, 어디선가 들어본 적 있지 않은가? 예전에 한 학교 커뮤니티의 유지보수 업무를 맡은 적이 있는데, 무려 쇼핑몰 회사에서 10년 전에 작성한 php 코드였다. 문서화 하나 되지 않았던 그 코드는, 결국 아무도 건드릴 엄두를 못 내고 매번 인공호흡을 통해 살아나고 있다..
문서화도 되지 않은 날 것의 레거시 코드
'문서화되지 않은' '레거시' 코드는 정말 최악이다. 레거시 코드를 다시 짜라는 업무를 받은 적도 있었다. 음.. 그런 걸 신입에게 왜 시킨 걸까? 물론 구조가 그리 복잡하진 않았지만.. 어쨌든 신입에게 그런 일을 맡기게 되면 일단 그 코드를 이해하는 것부터 시작한다. 정말, 정말정말 오래 걸린다.
클린 코드를 작성하려면
책에서는 '나쁜 코드를 작성하는 것은 전적으로 프로그래머의 잘못'이라고 이야기한다. 일하다보면 마감기한 때문에 정말 습관처럼 나쁜 코드를 짜는 개발자들이 많으리라. 하지만 저자는 그것 자체가 잘못이라 이야기하는 것이다. 기한 안에 정확하게 일을 완수하는 가장 빠른 방법은 '항상 코드를 깨끗하게 유지하는 것'이라 이야기하고 있다.
클린 코드란?
'보기에 즐거운' 코드, CPU 자원을 낭비하지 않는 코드, 세세하게 오류 처리한 코드, 메모리 누수, race condition이 없는 코드, 일관성 있는 명명법을 사용한 코드 등 다양한 예시를 들고 있다. 해결해야 하는 문제를 정확히 명명하고 이에 대한 명백한 해법을 제시하는 코드라고도 표현한다.
전체적으로 '가독성' 높은 코드를 클린 코드라고 하는 것 같다.
더해서 TDD(Test Driven Development) 이야기도 나온다. TDD에 관해서 10장짜리 정리 보고서를 만든 기억이 있는데, 참고한 책에서 TDD의 가장 큰 Risk는 대부분의 개발자가 TDD를 새로 배워야 한다는 점이라고 짚었다. 배우기만 하면, 그 효용은 훨씬 크다는 점을 강조했다. OTI 창립자 Dave Thomas는 테스트 케이스가 없는 코드는 클린 코드가 아니라고 지적했다. 추가로, 코드는 단위가 작아야 한다고도 지적했다.
Michael Feathers는 '누군가 주의 깊게 짰다는 느낌'이 드는 코드라고 이야기한다.
Ron Jeffries는 클린 코드의 비결을 '중복 줄이기, 표현력 높이기, 작게 추상화하기'라고 이야기한다. 여기에서 표현력에는 이름 짓기나 객체나 메서드를 적절하게 쪼개는 행위도 포함된다.
정리하면, 클린 코드를 짠다는 건 깨끗한 변수 이름, 깨끗한 함수, 깨끗한 클래스를 만드는 것이라고 볼 수 있다.
우리는 저자다
읽기 쉬운 코드를 짜기는 힘들지만, 우리는 코드를 쓰는 내내 기존 코드를 읽는다. 즉, 조금 더 시간을 들여 읽기 쉬운 코드를 만든다면 이후 코드를 짜는 사람에게도 큰 도움이 될 것이라는 뜻이다. '독자가 이해할 수 있는' 코드를 짜자.
나쁜 코드 예시
1. 나쁜 의도는 없었지만.. 깊은 중복의 늪
올해 초에 진행했던 프로젝트에서는 내가 코드리뷰를 담당했는데, 코드리뷰를 하지 않은 코드 중에 이런 코드가 있다. 조건문 안에 있는 index 값이 13까지 있는데 1부터 13까지 반복문을 돌며 저 코드가 반복된다. 심각한 중복이라고 볼 수 있다. 왜 이렇게 중복을 했냐라고 묻는다면 Modal 중간에 있는 visible 안에 들어있는게 state다. 저 때 마무리 작업을 위해 모였는데 30분만에 모달을 끼워넣어야 해서 다들 급하게 끼워넣다보니.. state를 무려 13개를 만들고 return도 13개하는 현상이 발생해버렸다.
코드리뷰를 안 한 내 탓이 크기는 하다.
2. fetch를 100번쯤 사용하면서 함수 추상화를 하지 않은 죄
쓰다보니 fetch, axios 기계가 된 FE 개발자. 나뿐만은 아닐 거라 생각한다. 가장 뼈저리게 느꼈던 때는 해커톤이었다. 마지막 날 새벽에 교수님 피드백을 듣고(무박해커톤이었다) 페이지 두 개를 추가했고 6시간 동안 총 4개의 페이지를 완성하는 동안 fetch만 8번을 적었다. 그렇게 적는 동안 함수 추상화를 하지 않았다면.. 잘못이겠지.
3. 무슨 의미를 가지고 있는지 모르겠는 변수 이름
이게 왜 아직도 padding89인지 알 수가 없다.. 이런 변수는 어디에든 보이면 일단 짜증부터 난다. 알밤아..
이외에도 함수 바로 위에 설명 주석은 지금까지 단 적이 없다. 그렇게 추천해줘도 이것도 나쁜 코드의 예라고 할 수 있다.
1장을 읽은 후기 ✍
사실 나 이 책 1장은 벌써 세 번째 읽는다. 방학 때 일하러 오면 빌려 읽었던 것 같다. 이 말인 즉슨 나는 '내 코드는 별로 좋은 코드가 아니'라는 걸 알고 있지만 개선하는 방법은 아직도 모르는 애송이.. 인 것이다. 이번에 참여한 동아리 스터디에서 꼭! 클린 코드 짜는 구체적인 방법까지 알아가고 싶다. 그리고 각자 코드 얘기하는 것도 너무 재밌을 것 같다.
📍 참고
클린 코드(Clean Code) - 로버트 C.마틴
