Home
All Posts
📚

왕돈가스처럼 코드 쪼개 먹기

Created
2024/05/11
Tags
CleanCode
Refactoring
Category
Essay
2 more properties
<파이브 라인스 오브 코드>는 다섯 줄 제한 규칙으로 시작하는 체계적이고 효과적인 리팩토링 수련법을 설명합니다. 여러 개발자 분들과 함께 이 책을 읽으며 리팩토링 스터디를 진행했고, 아래는 개인적으로 느낀 점을 정리한 내용이에요. 내용 요약과 사견 정리는 여기.
책 <파이브 라인스 오브 코드>

백지에 좋은 습관 들이기

그동안 개발 언어나 프레임워크 개념서만 읽었지, 리팩토링이나 클린 코드에 관한 책은 처음이었다. 덕분에 그동안 썼던 코드들을 더 좋은 방향으로 수정해 볼 수 있었다. 배운 규칙과 방법들을 더 잘 '체화'한다면 아직 백지 상태에 가까운 나에게 좋은 코딩 습관을 들여줄 수 있을 것 같다.
책을 읽는 동안 시간에 쫓겨 예제 연습을 많이 못해보았던 게 아쉽다. 이후 간단한 코드라도 단계적으로 리팩토링 하고, 그 과정을 블로그에 기록하고자 한다. 이 책을 그냥 흘려보내기에는 아깝다.
저자는 서문에서 말한다. 많은 규칙이 로버트 C. 마틴의 <클린 코드>에서 파생되었고, 다수의 리팩토링 패턴이 마틴 파울러의 <리팩터링>에서 비롯되었다고 한다. 아직 이 두 책을 읽어보지 않았는데 이 책에서 많이 인용된 만큼 더욱 궁금해서 이후 읽어보고, 코드에 적용해 보려고 한다.

정답이 없는 리팩토링

얼마 전 한 개발 리드 분과 커피챗을 하면서 리팩토링에 관한 이야기를 했는데, 기억에 남아서 끄적여본다. 예를 들어 아래의 코드에서 어떤 부분을 리팩토링 하면 좋을까?
function sum(a, b) { return a + b; } sum (2, 3);
JavaScript
복사
딱히 없을 수도 있지만 굳이 찾아보자면. type 체크, 인자를 더 semantic 하게 네이밍, null 체크, 혹은 throw Error로 처리할지, 한다면 어떤 식으로 처리할지, 아니면 어떤 식으로 return 할 것인지도 추가로 체크해 줄 수 있겠다.
위와 같이 간단한 코드에서도 리팩토링 할 게 있다. 혹은 누군가는 없다고 말할 수도 있겠다. 정답은 없다. 이렇듯 각자 코드를 짤 때 어디에 가치를 더 두고 있는지도 영향을 많이 끼칠 것이다.
이어지는 이야기로, 개발을 소설에 비유할 수 있다고도 한다. 변수는 등장인물이고, 함수는 그 사람이 가지고 있는 역할이라는 것이다. 이것을 얼마나 잘 설명하느냐가 소설을 잘 썼냐 못 썼냐가 평가되고, 결국 독자가 얼마나 잘 이해하느냐가 결정된다. 코드도 마찬가지다. 코드를 어떻게 잘 쓰느냐는 곧 글쓰기의 영역과도 같다.

왕돈가스처럼 코드를 쪼개기

첫 회사에서 업무가 너무 많아 허우적대는 나를 보고 팀장님이 해주셨던 조언이 생각났다. '왕돈가스 잘라먹기'. 왕돈가스가 처음에 딱 나왔을 때는 너무 커 보이지만, 잘게 쪼개서 조금씩 천천히 먹다보면 다 먹을 수 있다는 것이다. 업무도 마찬가지니, 너무 걱정하지 말고 업무를 우선순위에 따라 잘 쪼개보라는 조언이었다.
책의 마무리 장에서도 말하듯, 큰 문제를 작은 조각으로 분해하는 능력은 프로그래밍의 중요한 부분이라고 한다. 결국 문제 해결을 위해서는 문제(e.g. 엄청난 레거시 코드 리팩토링이나 마이그레이션 등)를 잘 파악하고, 문제를 작은 단위로 쪼개어 원인을 찾는다. 그리고 각각의 문제에 대응되는 해결책에 따라 조금씩 해 나가면 커 보이기만 했던 문제는 어느새 해결되어 있을 것이다.

규칙이 답은 아니다

책의 말미에 저자는 한번 더 당부한다. 지금까지 언급된 규칙들이 리팩토링 할 때 안정감과 자신감을 부여하는 데 도움이 된다면 그만큼 좋은 것은 없다고. 규칙을 서로를 평가하는 도구로 사용하지 말라고. 이 책의 규칙들은 코드 품질에 대한 의견을 나누기 위한 '좋은 출발점'이 될 것이라고.
이 말이 참 와닿았다. 코드리뷰를 하다 보면 간혹 본인이 어떤 규칙을 무려(?) 책에서 언급했으니 이 방법이 맞는 것이라 하는 사람들이 있었다. 물론 책에서 말한 원칙과 방법이 틀린 것은 아닐 것이다. 하지만 책에서 말했다고 다 맞는 것은 아닐뿐더러, 우리가 처한 상황이나 맥락에서는 맞지 않는 방법일 수도 있다.
그러니 저자의 말처럼 여기서 말하는 규칙들을 너무 맹목적으로 따르기보다, 우리 코드와 서비스를 더 나은 방향으로 안내할 수 있는 가이드라인 정도로 생각하면 어떨까.