[클린 코드] 1장 - 깨끗한 코드

르블랑의 법칙(Leblanc's Law) - 나중은 결코 오지 않는다.

 

클린 코드의 필요성을 부정하는 사람은 없을 것 같아요. <클린 코드>는 첫 장으로 왜 클린 코드가 필요한지 설명하고 있어요. 클린 코드가 필요하고 깨끗하지 못한 코드가 나쁘다는 말을 부정할 사람은 없을 것 같아요. 이왕이면 깨끗한 코드가 더 좋은 결과물이겠죠. 문제는 이 깨끗한 코드를 어떻게 정의할까에요. 

저명한 개발자들은 깨끗한 코드를 다음과 같이 정의했어요.

 

1. 비야네 스트롭스트룹(Bjarne Stroupstrup) - 보기에 즐거운 효율적인 코드

• 우아하고 효율적인 코드
• 논리가 간단 ➡️ 버그 발생 감소
• 의존성을 줄여야 함 ➡️ 유지보수가 쉬워짐
• 오류는 명백한 전략에 의거해 철저히 처리
• 한 가지를 제대로 함

 

2. 그래디 부치(Grady Booch) - 추측이 아니라 사실에 기반한 코드

• 단순하고 직접적인 코드
• 잘 쓴 문장처럼 읽힘
• 설계자의 의도를 숨기지 않음
• 명쾌한 추상화와 단순한 제어문으로 가득

 

3. 데이브 토마스(Dave Thomas) - 다른 사람이 고치기 쉬운 코드

• 작성자가 아닌 사람이 읽기 쉽고 고치기 쉬운 코드
• 단위 테스트와 인수 테스트가 존재
• 특정 목적을 달성하는 방법이 여러 개가 아니라 한 개만 존재
• 의존성은 최소이며 각 의존성은 명확히 정의
• 코드는 문학적으로 표현해야 함

 

4. 마이클 페더스(Michael Feathers) - 주의 깊게 작성한 코드

• 누군가 주의 깊게 짰다는 느낌을 주는 코드
• 고치려고 봐도 딱히 손댈 곳 없는 코드

 

5. 론 제프리스(Ron Jeffries) - 중복을 피하고 한 기능만 수행하는 표현력(네이밍) 있는 코드

• 모든 테스트를 통과함
• 중복이 없음
• 시스템 내 모든 설계 아이디어를 표현
• 클래스, 메서드, 함수 등을 최소한으로 줄임

 

6. 워드 커닝햄(Ward Cunningham) - 그 문제를 풀기 위한 언어처럼 보이는 코드

• 짐작했던 기능을 각 루틴이 그대로 수행하는 코드
• 읽으면서 놀랄 일이 없는 코드

 

 

나의 생각

 

 현업을 경험하기 전, 이 책을 접했다면 1장부터 무조건적인 흡수를 하려고 했을 것 같아요. 나쁜 코드보다는 깨끗한 코드가 당연히 좋고, "이왕이면 작성할 때 더 고민하여 깨끗한 코드를 작성하는 게 좋지 않을까?"라는 생각을 했을 것 같아요. 하지만 지금으로서는, 깨끗한 코드를 작성할 코스트마저 다른 곳에 투자해야 할 상황도 있다고 생각해요.

 

 첫 번째, 회사 혹은 팀의 규모에 따라 상황이 다르다고 생각해요. 많은 사람들이 읽을 코드를 작성하는 대기업의 경우 클린 코드에 할애해야 하는 시간이 더 길어야 한다고 생각해요. 변화나 요구사항이 소규모 스타트업에 비해 상대적으로 적을 수 있기 때문에 클린 한 코드를 설계할 시간적 여유를 가질 수 있고, 함께 토론할 개발자가 많은 환경이기 때문이에요. 그리고 내가 작성한 코드가 정상적으로 동작하는 만큼이나 여러 개발자가 읽기 쉬운 코드를 작성할 필요성이 커진다고 생각해요. 여러 사람이 작성하지만 한 사람이 작성한 코드처럼요. 하지만 빠른 결과물과 빠른 변화를 추구하는 스타트업의 경우 클린 코드를 항상 유지하는 것은 매우 어려운 일이라고 생각해요. 개발자가 1명, 2명인 회사에서 당장 많은 결과물을 필요로 하는 경우 개발자가 100명, 200명이 되는 경우를 상정하고 처음부터 코드를 완벽하게 짜는 건 매우 어려운 일이라고 생각해요. 물론 시작부터 완벽하면 가장 좋겠지만요!

 

 두 번째, 깨끗한 코드의 정의는 각자 다 다르다고 생각해요. 한 회사, 한 팀에 속해 있더라도 깨끗한 코드의 정의가 모두 다르기 때문에 이걸 맞춰가는 컨벤션이 필요하고, 경우에 따라서 이 컨벤션에서 벗어나는 코드를 작성할 필요가 있다면 설득이 필요하다고 생각해요. 즉, 나에게 깨끗한 코드와 다른 개발자가 생각하는 깨끗한 코드가 다를 수 있기 때문에 어떤 경우에도 깨끗함을 유지해야 한다는 말은 맹점이 있을 수 있을 것 같아요. 물론 일반적으로 공감을 얻을 수 있는 공통된 관념 하에서는 당연히 깨끗한 코드를 유지하려는 노력이 필요한 것 같아요.

 

 세 번째는 개발자가 가진 경험에 따라 시야가 다르기 때문에 어떤 사람에게 깨끗한 코드가 다른 사람에게 나쁜 코드일 수 있을 것 같아요. 그래서 커뮤니케이션이 중요하고, 컨벤션을 함께 발전시켜 나가는 게 중요할 것 같아요. 특히 소규모 팀에서 개발 역량 차이가 큰 사람들 간의 협업에서는 이 부분이 더 중요하다고 생각해요. 

 

그럼에도 불구하고 "그럼 왜 이 책을 읽기 시작했냐"라고 한다면 저의 목표는 클린 코드를 작성하는 개발자가 아니라 클린 코드를 작성하는데 특별히 코스트가 들지 않을 만큼 클린 코드가 몸에 밴 개발자이기 때문이에요.

 

이 책에 나오는 내용이 클린 코드의 정답이라 암기해서 체득하는 것이 목표가 아니라, 다른 사람들이 생각하는 클린 코드를 읽고 나만의 클린 코드가 무엇인지 정의 내리고 싶어요. 클린 한 코드를 작성하는 개발자라기보다 계속해서 클린한 코드를 작성하려는 태도와 자세를 갖춘 개발자라는 말이 맞을 수도 있을 것 같아요. 

 

현재는 실력이 부족해서 깨끗한 코드가 무엇인지 정의 내리기 조차 어렵고, 더 나은 구조를 설계하는데 매우 많은 시간이 걸리지만 최종적으로는 습관적으로 작성하는 코드마저 깨끗한 코드가 되는 개발자가 되고 싶어요. 매일매일 코딩을 하고 있기 때문에 앞으로 클린 코드에서 읽은 내용을 정리하고, 그날의 코드에 녹여보려고 해요. 

 

 

클린코드(Clean Code) by Robert.C.Martin