들어가며
개발자라면 많이 들어봤을 클린 코드라는 도서가 있습니다. 클린코드 책을 읽은 많은 지인들이 이 책을 추천하고 또 '클린코드는 중요하다'라는 이야기를 많이 접할 수 있었습니다.
하지만 학부 시절에는 크게 클린 코드의 중요성을 느끼기는 쉽지 않았습니다. 대부분의 코드들을 유지보수 할 일도 많지 않았을 뿐더러 어떻게든 돌아가는 코드를 짜는 것 자체의 난이도는 크게 어렵지 않기 때문입니다.
하지만 프론트엔드 개발자로 입사하게 되고, 많은 개발자들이 거쳐간, 많은 사람들이 이용하는 큰 규모의 프로젝트의 코드를 읽으며 클린코드의 중요성을 몸으로 느낄 수 있었습니다.
흔히 말하는 레거시 코드를 맞이할때마다 그 상황을 가장 잘 표현한 사진이라고 할 수 있습니다. 우연찮게 좋은 코드가 작성된 부분을 수정할 때에는 몇 줄 고치고 끝나는 작업도 있지만 코드를 읽는 것에만 며칠이 걸리는 경우도 종종 있습니다.
특히, 대부분의 나쁜 코드는 읽는 것만 어려운 것이 아닌 새로운 요구사항을 만족시키기에도 쉽지 않습니다. 많은 개발자들은 주어진 시간과 개발 난이도를 저울질하여 아예 새로운 기능을 만들기도 합니다(그래서 거의 동일한 동작을 하지만 각기 다른 모듈로 구현된 코드도 흔하게 볼 수 있습니다).
제가 작성한 코드도 언젠가, 누군가에게 레거시로 여겨지겠지만 좋은 코드를 작성하는 것으로 최대한 그 시기를 미룰 수 있다는 생각이 들었습니다. 금번 기회를 통하여 클린코드가 무엇인지 알아보고 저의 생각을 정리해보고자 합니다.
좋은 코드는 무엇일까?
깨끗한 코드는 한 가지를 제대로 한다.
- 비야네 스트롭스트룹(Bjarne Stroustrup)
간혹 하나의 함수인데 여러 가지의 비즈니스 로직을 수행하는 경우가 있습니다. 물론 예를 들어 '회원가입' 버튼을 예시로 들자면 여러 가지 기능을 수행해야 할 것이긴 합니다. 클라이언트 단의 유효성 검증, 서버 단의 유효성 검증, 그리고 회원가입 요청 정도로 나눌 수 있겠군요.
여기서 좋은 코드를 작성하기 위해서는 어느 정도의 분리가 필요합니다. 유효성 검증은 A 함수, 서버 단의 유효성 검증은 B 함수, 회원가입 요청은 C함수로 분리하고 회원가입 클릭은 A, B, C를 순차적으로 실행해주기만 하면 되도록 말이죠.
function validateClientInput(data) { /* 클라이언트 단 유효성 검증 */ }
function validateServerInput(data) { /* 서버 단 유효성 검증 */ }
function sendSignUpRequest(data) { /* 회원가입 요청 */ }
function handleSignUp() {
if (!validateClientInput(data)) return;
if (!validateServerInput(data)) return;
sendSignUpRequest(data);
}
즉, 회원가입 클릭 시 실행되는 함수는 여러 책임을 위임합니다. '회원가입 요청을 처리한다'라는 본래의 역할에 충실할 수 있도록 말이죠.
하지만 되려 잘게 나눈 코드들이 가독성을 해칠 수도 있으므로 분리의 기준을 잘 잡는 것도 중요하다고 생각합니다.
깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
- 그래디 부치(Grady Booch)
위는 세 글자로 요약하자면 '가독성'입니다. 클린코드는 가독성이 좋은 코드를 의미합니다. 잘 읽히는 코드는 아래와 같은 특징을 가집니다.
의도를 명확하게 드러내는 네이밍
식별자들의 이름은 그 자체로 역할과 목적을 명확하게 나타낼 수 있어야 합니다.
// 나쁜 예:
let d; // 이게 뭘 의미하는지 알 수 없음
// 좋은 예:
let deliveryDate;
주석이 필요 없는 코드
주석이 없더라도 코드를 읽었을 때 무엇을 하는지 알 수 있어야 합니다.
주석 역시, 결국 사람이 관리하는 만큼 관리를 제대로 하지 않을 시에는 되려 혼란을 줄 수 있어 필요할 때만 사용해야 합니다.
나쁜 코드는 무엇일까? 왜 발생할까?
나쁜 코드는 위에서 설명한 좋은 코드, 클린 코드의 반대라고 볼 수 있습니다. 명확한 네이밍을 갖지 않고 하나의 코드가 여러 책임을 갖고 있는 경우가 이에 해당됩니다.
그렇다면 나쁜 코드는 왜 발생할까요?
'깨진 유리창 법칙'이라는 말을 많이들 들어봤을 것입니다. 나쁜 코드가 그대로 방치되어 있다면 나 역시 나쁜 코드를 작성할 가능성이 높아집니다. 좋은 코드를 작성하기 위해서는 많은 시간과 노력이 들기 때문이죠.
그렇다고 기존에 있는 나쁜 코드를 한 번에 개선하는 것 역시 쉽지는 않습니다. 나쁜 코드 그리고 오래된 코드일수록 이 코드를 건드리면 발생하는 사이드 이펙트는 점점 커지게 됩니다. 예를 들어 전역적으로 적용한 코드가 '나쁜 코드'라면 기존 기능들에 아무런 영향이 없도록 수정해야 할 것이며 그것을 검증해야 할 것입니다. 그렇기에 우리는 나쁜 코드를 '점진적'으로 고치려는 습관을 가져야 합니다.
이 경우 '보이스카웃 규칙'을 코드 작성에도 적용하면 좋습니다. 보이스카웃 규칙은 '캠핑장을 떠날 때에는 처음 방문했을 때보다 더 깨끗하게 치우고 가야한다.'라는 오래된 규칙입니다. 코드 작성 역시, 내가 코드를 작성하고 고칠 때 기존 코드보다 더 깨끗한 코드를 만드는 것이지요.
모호했던 식별자의 이름을 고친다던가.. 불필요하게 중복된 로직을 제거한다던가.. 간단한 작업이어도 코드가 작성됨에 따라 전보다 조금 더 나은 코드가 나오게 되는 것입니다.
마치며
금번 포스팅에서는 클린코드가 무엇인지, 클린코드를 작성하기 전에 나쁜코드가 발생하는 이유는 무엇이며 어떻게 타파할 수 있는지에 대하여 간단하게 정리해보았습니다.
작지만 강력한 규칙들을 하나 둘 적용하는 것으로 저 뿐만 아니라 향후 프로젝트를 이어받는 개발자가 좀더 편안한 개발생산성을 느낄 수 있도록 노력해보고자 합니다.
