깔끔한 코드란 없습니다.(There’s No Such Thing as Clean Code 번역)

안녕하세요. 도미닉입니다.

 

이 글은 최근에 바이럴된 https://www.steveonstuff.com/2022/01/27/no-such-thing-as-clean-code 의 번역 글입니다.

 

오역과 흐름을 위해 각색이 있을 수 있습니다. 참고해서 읽어주세요~

 

깔끔한 코드란 없습니다.

요즘에 모든 사람들은 깔끔한(clean) 코드를 짜기 위해 노력하고 있는 것 같습니다.

블로그 포스트들을 읽다 보면 작성자가 자신의 접근 방식이 얼마나 깔끔한(clean)지를 설명하지 않는 글을 찾기 힘듭니다.

개발팀들은 모여서 어떤 방법이 가장 clean 한지 토론합니다. 어떤 개발자들은 자신들이 clean code 를 작성한다고 장담합니다.

 

위선자라고 생각하시나요!

 

저도 결백하지 않습니다. 예전에 'clean' 이라는 표현을 여러 번 사용한 적이 있습니다. 또한 이 용어를 사용하는 사람들을 폄하하려는 것이 아니라는 점을 분명히 말씀드리고 싶습니다.

 

마케팅 용어나 목표, 개념에 대한 설명으로 'clean'은 괜찮습니다! 하지만 기술적인 용어로는 몇 가지 문제점이 있습니다...

 

Clean code 는 좋은 코드 잖아, 아니야?

사람들이 코드를 'clean' 하다고 표현할 때는 보통 어떤 면에서든 코드가 좋다는 뜻입니다.

 

문제는 좋은 코드의 이유는 여러가지가 있을 수 있다는 것입니다. 예를 들면 아래와 같이 다양합니다.

 

Readable
Understandable
Simple
Performant
Safe
Elegant
Testable
Encapsulated
Scaleable
Maintainable
Reusable
Easy to delete
Neat and tidy
Noninvasive
Systematic
Consistent

등등..

 

그러나 이러한 좋은 점은 어떤 면에서는 서로 상충됩니다. 가장 단순한 코드가 테스트하기 가장 쉬운 코드는 아닐 것입니다. 인터페이스와 주입된 종속성은 테스트에는 편리하지만 단순함 측면에서는 멀어지게 됩니다.

 

싱글톤에 대한 의존도가 높아지면 코드를 이해하기는 쉬워지지만 성능 유지 관리가 편한 애플리케이션은 되지 않을 것입니다.

 

이러한 특성들 중 일부는 근본적으로 서로 상반되어 작용하는 것으로 동시에 모두를 만족시킬 수 없다고 생각합니다. 개발은 트레이드오프(상충 관계)에 관한 것이므로 우리는 균형에 대해 인지하고 팀원들고 함께 논의할 수 있어야 합니다.

 

코드가 좋다면 그 이유를 설명해야 합니다.

누군가가 어떤 방식이 'clean'하다고 말할 때, 그 이유를 합리적으로 설명하지 못한 채 그 방법이 좋다고 하는 경우가 많습니다.

 

개발 방법에 대해 건설적인 토론을 하려면 한 방법이 다른 방법보다 더 나은 이유를 명확하게 설명할 수 있어야 합니다. 어떤 방법이 가장 'clean' 한 솔루션인지에 대해 논쟁하는 것은 마치 체중계를 꺼내 각 방법의 무게를 측정해야 하는 것처럼 좋지 않습니다.(어느 것이 깨끗한 지 측정하는 것보다 중요한 것이 있다는 의미인듯)

 

사실 한 방식이 다른 방식보다 더 좋거나 나쁜 이유를 표현하기는 매우 어렵지만 그럼에도 시도할 만한 가치가 있는 것입니다.

 

이런 식으로 이야기하시겠습니까?

 

X 방식이 훨씬 깔끔한 느낌이 들어서 마음에 들어요.

 

아니만 아래와 같이 이야기하시겠습니까?

 

저는 X 방식이 마음에 듭니다. 오류 메시지 표시를 핵심 로직에서 분리했기 때문입니다. 서비스 로직과 오류 메시지 표시를 동시에 고려할 필요가 없으므로 이해하기 더 쉽습니다. 이렇게 분리하면 다른 객체를 테스트하는 동안 다른 객체를 모킹할 수 있으므로 테스트 커버리지가 높아집니다. 물론 상위 객체에 종속성을 주입해야 한다는 단점이 있지만, 테스트 커버리지를 고려하면 충분히 감수할 만한 가치가 있습니다.

 

두번째 문장은 실제로 우리가 논의하고 있는 방식의 장단점에 대한 확실한 내용을 전달합니다. 'clean' 하다와 같은 용어는 아이디어를 명확하게 표현하는 능력을 향상시키지 않고 도망가게 합니다.

 

정확한 용어를 사용해야 합니다.

코딩은 일반적으로 팀 스포츠입니다. 혼자서 해킹을 할 때는 원하는 대로 할 수 있지만, 팀과 함께 작업할 때는 아이디어를 논의해야 합니다. 팀 전체가 공통적으로 이해할 수 있는 구체적인 용어를 사용하여 개발 방식에 대해 토론할 수 있다는 것은 서로 이해하는데 매우 중요합니다.

 

'clean code'는 사람마다 다른 의미입니다.

 

어떤 개발자에게는 코드가 잘 정리된 아키텍처를 가지고 있을 때 'clean code' 일 수 있습니다. 다른 개발자에게는 코드가 일관된 서식으로 작성되었을 때 'clean code'일 수도 있습니다.

 

'캡슐화된', '테스트 가능한', '모킹 가능한', '재사용 가능한'과 같은 단어는 우리 모두가 동의할 수 있는 의미를 가지고 있습니다. 프로젝트 전체에 영향을 받는 다양한 코드 특성을 설명하기 보다 구체적인 단어를 사용하면 모두 같은 생각을 공유한다는 것을 확신할 수 있습니다.

 

'clean' 은 'good' 과 같은 수준의 명확성을 갖습니다. 코드가 좋다고 말할 수 있는 것처럼 'clean' 하다고 말할 수 있지만 더 구체적인 근거를 가지고 명확하게 설명할 필요는 없습니다.(좋다라는 것은 기분이고 느낌이어서 근거를 명확하게 대지 않아도 되지만 'clean' 하다는 것은 구체적인 근거와 이유를 밝혀야 한다고 이해됩니다)

 

그래서 clean code 가 뭔데?

저는 어떤 코드를 볼 때 좋은 코드라고 생각이 들지만 그 이유를 잘 모를 때 'clean' 하다고 표현하는 경우가 많다는 결론에 도달했습니다.

그저 알맞은 표현처럼 느껴질 뿐이죠.

 

아니면 코드가 좋은 이유는 알지만 이를 표현할 다른 단어를 찾지 못할 때 블로그 게시글의 결론이 "자, 얼마나 깔끔한지 보세요!"로 끝나는 경우도 있었습니다.

 

직관적인 표현도 좋지만 우리는 개선할 수 있습니다. 이 코드가 좋다고 생각하는 이유를 이해하고 명확하게 표현하려면 직관을 넘어 더 깊이 파고들어야 합니다. 이 코드에는 다른 방식에는 없는 어떤 특징이 있을까요? 이러한 특징이 우리 프로젝트에 적합한가요? 어쩌면 이 코드가 실제로는 올바른 해결법이 아닐 수도 있습니다.

 

'clean' 한 코드가 아니라 ____ 한 코드가 필요하다는 것을 이해할 수 있기 바랍니다. 프로젝트에 필요한 코드를 설명하는 단어로 빈 칸을 채우는 것은 여러분의 몫입니다.

 

원문 : https://www.steveonstuff.com/2022/01/27/no-such-thing-as-clean-code