[Clean Code] 클린 코드와 같은 건 없다.
There’s No Such Thing as Clean Code을 번역하고 추가적인 내용을 적은 글입니다.
지금은 누구나 클린 코드를 위해 노력하는것 처럼 보인다. 하지만 어떻게 클린한 코드에 다가가는지 설명하는 블로그는 보기 힘들다. 개발자들은 어떤 것이 더 클린한 것인지 모여서 토론한다. 다른 개발자들은 클린 코드를 연습하고 있다고 확신한다.
나는 마침내 클린 코드와 같은 것은 없다고 깨달았다.
클린이란 단어로는 유용함을 측정할 수 없다. 클린은 코드를 설명하지 않기 때문에 코드는 클린할 수 없다.
나도 물론 위선자이다.
나 자신도 결백하지 않다. 과거에 클린이라는 단어를 많이 사용했었다. 또한 클린이라는 단어를 사용하는 사람을 얕보지 않는다는 것을 확실하게 하고 싶다. 마케팅 용어나 비선을 설명하는데 클린이라는 단어는 매우 좋은 선택이다. 그러나 기술적인 관점에서는 몇몇 문제를 야기 시킨다.
클린 코드는 정말 좋은 것인가?
사람들이 코드를 클린하다고 설명할 때는 일부 코드가 좋다는 표현을 종종 사용한다. 다시 말하면 코드는 여러 이유에 의해서 좋다고 볼 수 있다. 예를 들면
- Readable (가독성)
- Understandable (이해 할 수 있는)
- Simple (단순한)
- Performant (성능)
- Safe (안전한)
- Elegant (우아한)
- Testable (테스트 가능)
- Encapsulated (캡슐화)
- Scaleable (확장 가능)
- Maintainable (유지보수 가능)
- Reusable (재사용 가능)
- Easy to delete (삭제하기 쉬움)
- Neat and tidy (단정하고 깔끔)
- Noninvasive (비침습적)
- Systematic (체계적인)
- Consistent (일관된)
- 또는 기타 여러 가지
그러나 이러한 특징은 서로 같이 사용되었을 때 어떤 면에서 이상한 부분이 발생한다. 가장 간단한 코드는 테스트하기 어려운 것처럼 말이다. Interfaces나 Injected Dependencies(의존성 주입)은 테스트를 편하게 하지만 단순한 코드와는 거리가 있다.
Singleton에 대한 무한한 신뢰는 코드를 이해하기 쉽게 만들 수 있지만, 어플리케이션의 유지보수에는 도움이 되지 못한다.
이러한 특징들중 이론적으로 서로 반대대는 성향을 가지고 있으며 동시에 만족할 수 없다. 공학은 Trade-offs에 관한 문제이다. 따라서 어떤 장단점이 있는지 알고 있어야 하며 팀원들과 논의할 필요가 있다.
코드가 왜 좋은지 설명할 수 있어야 한다.
누군가 솔루션이 클린하다고 얘기할 때, 그 이유에 대해서 합리화 하지 못하고 그냥 더 나은 선택이라고만 얘기할 때가 있다.
기술적인 솔루션에 대해서 의미 있는 토론이 되기 위해서는 다른 솔루션에 비해서 좋은점을 명확하게 설명할 수 있어야 한다. 단순히 솔루션이 클린하다고 주장하는것은 좋지 않다. 마치 신비한 측정법에 따라 각 솔루션의 clean-o-meter를 측정하는것 처럼 말이다.
때때로 어떤 접근 방식이 다른 접근 방식보다 더 좋거나 더 나쁜 이유를 표현하는 것은 실제로 상당히 어렵지만 갈고닦을 가치가 있는 기술이다.
아래의 두 예시중에 어떤것이 좋은지 생각해보자
나는 솔루션 X를 좋아한다. 솔루션 X가 더 클린해 보이기 때문이다.
아니면
나는 솔루션 X를 좋아한다. 솔루션 X는 코어로직과 에러 메시지를 디커플링 시키며, 두 로직을 같이 생각하지 않아도 되기 때문에 이해하기 더 쉽다. 또한 어떤 면에서는 목을 사용할 수 있기 때문에 테스트 하기 쉽다. 부모 객체에 의존성을 주입해야 되는 비용이 발생하지만 테스트의 용의성을 위해서 감수할만한 트레이드 오프이다.
트레이드 오프는 솔루션에 대한 장단점을 논의할때 명확한 정보를 전달한다. 클린이라는 단어는 아이디어를 명확하게 만든다기 보다는 아이디어를 제한하는 변명거리이다.
확실한 용어를 사용해야 한다.
일반적으로 코딩은 팀단위로 진행한다. 원하는것을 위해서 혼자서 어떻게든 해킹을 할 수도 있겠지만, 보통은 공통의 아이디어를 논의하는 팀에서 일하고 있을것이다. 특정 언어를 사용하여 기술 솔루션에 대해 토론할 수 있고 팀 전체에서 공통적으로 이해하는 것은 서로를 이해하는 데 매우 중요하다.
개개인 마다 클린 코드는 다른 의미로 받아들여 질 수 있다.
어떤 사람에게는 구조적으로 잘 정의된것이 클린 코드일수 있고, 다른 사람들은 포멧팅이 잘되어 있어 심플한 코드를 클린 코드로 바라 볼 수 있다.
캡슐화(encapsulated), 테스트 용의성(testable), 목 생성 용의성(mockable), 재 사용성(reusable) 같은 용어는 모두가 동의할 수 있는 용어이다. 프로젝트에 영향을 미치는 다양한 코드를 설명하는 명확한 단어를 사용할때 팀원들은 같은 이해관계를 가질 수 있다.
클린은 좋다와 비슷한 레벨의 단어이다. 어떤 코드가 클린하다고 말하는 것처럼 코드가 좋다고 말할 수 있다. 하지만 그렇다고 해서 더 구체적인 근거로 이를 정당화해야 하는 것은 아니다.
그렇다면 클린코드는 무었인가?
결론적으로 모든 면에 있어서 확실한것은 아니지만 코드가 클린해 보일때 클린 코드라고 할 수 있다. 단지 솔루션이 올바른 것처럼 보이는것 처럼 말이다.
때때로 코드가 왜 좋은지 알고 있을때가 있지만, 명확하게 왜 좋은지 설명할 수 없을때가 있다.
직관적으로 알 수 있도록 감각을 키우는것은 좋지만 더 나아가서 생각할 필요가 있다. 더 파고 들어서 직관적으로 느끼는것 보다는 왜 코드를 좋게 생각하는지 명확하게 표현 할 수 있어야 한다. 다른 솔루션에 비해서 어떤 장단점이 있는지?, 프로젝트에 가장 적합한 특성인지? 살펴 보아야 하지만 결국에는 아마도 올바른 해결책이 아닐것이다.
희망적이게도 프로젝트에 클린 코드가 꼭 필요한 것은 아닐 수 있다. 프로젝트에 필요한 ___ 코드를 찾는것이 중요하다.
Comments