[클린코드] 1장 코드단위를 짧게하라

이 글은 유지보수 가능한 코딩의 기술 자바편을 요약 및 정리하여 작성한 내용임을 밝힙니다. 필자가 작성하는 내용은 책의 내용을 그대로 사용하여 작성한 부분도 많지만 인용하여 작성한 부분도 있기 때문에 보다 정확하고 자세한 내용을 위해 해당 책을 구매하여 보시는 것을 추천드립니다.

1. 가이드라인

분류	비고
목표	코드 단위는 15라인을 넘어가지 않게 작성한다.
실천	단위는 15라인을 넘지 않게 하고, 큰 단위는 15라인 이하의 작은 단위로 나눈다.
효과	작은 단위는 이해하고, 테스트하고, 재사용하기 쉬워 유지보수성이 좋아진다.

독립적으로 관리 및 실행을 할 수 있는 최소한의 코드 그룹을 단위(unit)이라고 합니다. 자바에서는 메서드나 생성자가 단위입니다. 단위는 재사용, 테스트가 가능한 가장 작은 코드 조각입니다.

2. 필요성

단위를 짧게 유지하면 테스트, 분석, 재사용성 모두 좋아지는 장점이 있습니다.

2.1. 짧은 단위는 테스트하기 쉽다

하는 일이 하나뿐인 코드는 비교적 테스트하기 쉽습니다. 짧은 단위는 보통 딱 한가지 일만 하지만, 긴 단위는 여러 일을 처리하며 다양한 책임을 지는 경향이 있습니다.

2.2. 짧은 단위는 분석하기 쉽다

아무래도 긴 단위보다는 짧은 단위가 더 빨리 코드 전체를 읽고 내부 로직은 분석하기 용이합니다.

2.3. 짧은 단위가 재사용하기 쉽다

긴 단위보다 짧은 단위가 재사용 가능한 코드가 될 가능성이 높습니다. 긴 단위는 대개 특정한 세부 로직을 구현하거나 여러 기능을 특수한 형태로 조합한 경우가 많아 짧은 단위보다 기능이 집중된 편입니다. 이런 기능을 다시 쓸 일은 많지 않아서 재사용하기 어렵지만, 짧은 단위는 확실히 더 범용성적이어서 다른 요구사항에도 잘 맞는 가능성이 높아 재사용하기 좋습니다. 코드를 재사용하면 전체 코드베이스를 줄일 수 있는 효과도 있습니다.

3. 적용 가이드

모든 로직을 15라인을 넘지 않게 작성하는 것은 사실상 불가능 합니다. 하나의 단위를 단일책임만 갖도록 코드를 작성하더라도, 15라인으로는 작성할 수 없는 복잡하고 방대한 로직이 필요할 경우가 있습니다. 15라인을 넘지 않는 코드라인을 작성하라 라는 가이드라인은 개발자의 명확한 라인수 제한을 통해 보다 유지보수성이 좋은 코드를 작성할 수 있도록 도와줍니다.

3.1. 리팩토링 기법으로 가이드라인을 적용

단위에 새 기능을 넣어 확장하는 경우 기존에는 15라인이 넘지 않았지만, 확장함으로서 15라인이 넘어가는 경우가 발생할 수도 있습니다. 이런 상황에서 우리는 코드 악취를 의심해야 합니다. 15라인이 넘는 코드는

단위 코드를 짧게 하는 두 가지 리팩토링 기법을 소개합니다.

3.1.1. 리팩토링 기법 : 메서드 추출

단위에 있는 코드를 메서드로 추출함으로서 구현부가 단순해 지는 효과를 얻을 수 있습니다. 또한 명확하고 가독성 좋은 메서드명을 사용할 경우 주석이 없더라도, 해당 메서드가 어떠한 역할을 하는지 쉽게 알 수 있습니다. 이를 소스 코드가 스스로를 설명하는 형태(self-exsplanatory)라고 합니다.

Note :유지보수가 가능한 코드를 작성하는 일은 언제나 다른 가이드라인과 타협의 문제입니다. 한 단위를 여러 단위로 나누면 전체 코드 볼륨이 커지고 코드베이스를 작게하라라는 가이드라인을 위반한 것처럼 보이지만, 분석/테스트할 대상 단위의 크기와 복잡도는 줄었으므로 결국 유지보수성은 나아진 셈입니다. 코드베이스를 작게 만들어야 하는 건 맞지만, 짧은 단위의 장점이 코드베이스가 증가한 단점보다 훨씬 더 가치 있다고 볼 수 있습니다.

3.1.2. 리팩토링 기법 : 메서드를 메서드 객체로 대체

4. 반대의견

4.1. 단위를 많이 두면 성능이 떨어진다

단위를 짧게 작성하면 결국 단위 개수가 늘어날 테고 그러다 보면 메서드 호출 또한 잦아지곘죠. 성능상 좋을 게 없습니다.

이론적으로는 단위가 많아지면 긴 단위를 적게 작성하는 것에 비해 메서드 호출 횟수가 증가하면서 성능에 부정적인 영향을 끼칩니다. 호출을 한 번 할 때마다 자바 가상머신(JVM)이 할 일이 아주 조금이라도 늘어나겠죠. 그러나 실은 최악의 경우를 생각해도 기껏해야 밀리 초 단위 정도의 성능 저하에 불과하기 때문에 크게 문제가 되지는 않습니다.

4.2. 코드를 펼치면 더 읽기 어렵다

코드를 여러 단위로 펼치면 읽기가 어렵습니다.

실제로 필자의 경우에도 단일책임원칙으로 메서드를 작은 단위로 작성하고, 여러 곳에서 해당 메서드를 사용할 경우 간혹 오히려 가독성이 더 떨어지는 것을 경험할 때가 있습니다. 이런 문제가 발생하였을 때 필자의 개인적인 생각은 모델링이 잘못되었 경우라고 생각합니다.

4.3. 도저히 단위를 나눌 수 없다

절대로 단위를 나눌 수 없어요.

의외로 메서드를 나누기가 까다로운 경우도 있습니다. 예를 덜어, 자바의 case문과 SQL 쿼리 문이 대표적인 예입니다. 해당 문제는 메서드 추출 기법으로도 직접적인 추출은 불가능 합니다.(swict 문을 다루는 방법을 추후에 다시 소개합니다)

SQL문과 같은 것들은 가이드라인이 정해져 있지는 않습니다. 하지만 리팩토링이 어려워 보이더라도 그냥 무시하고 넘어가지 마시고, 팀 동료나 리더에게 이슈를 제기하여 좀 더 다양한 측면으로 고민해 보시는것을 추천드립니다.

4.4. 단위를 나눈다고 별반 나아질건 없다

각 단위가 하는 일이 무엇인지를 잘 나타내는 이름을 메서드명으로 작명을 하게되면 코드를 전부 다 뜯어 보지 않더라도 해당 코드가 어떻게 동작하는지 개발자가 쉽게 이해할 수 있습니다. 기능을 잘 나타내는 이름으로 메서드를 작성하는 것이 중요합니다.