Clean Code (1)

Clean Code: A Handbook Of Agile Software Craftsmanship (2009) 라는 책을 읽고 정리한 글입니다. 책의 예제는 Java 로 쓰여 있어서 Python으로 쓰인 코드도 함께 찾아보았습니다. 이 책은 그 자체가 클린코드입니다. 코드를 작성하는 원칙과 철학에서 실제 코드까지 설명이 명확하고 군더더기가 없습니다. 실제로 읽다가 노트북을 켜고 리팩토링하며 무릎을 탁친 경우가 적지 않았습니다.

👉 Clean Code (2)

1. 깨끗한 코드

'Later equals never'. 우리는 항상 지금은 급하니 빠르게 짜고 나중에 다시 정리하자고 다짐하곤 한다. 그러나 우리는 안다. 나중은 결코 오지 않는다는 것을.

저자는 보이스카우트 원칙을 말한다. '캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라'고. 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. 코드를 읽는 시간 대 짜는 시간 비율은 10대 1을 훌쩍 넘는다. 우리는 끊임없이 기존 코드를 읽는다. 깨끗한 코드, 가독성이 좋은 코드가 중요한 이유다.

클라이언트의 요구사항을 탓하고 싶은 유혹이 들 때도 있다. 불가능한 요청을 했다고, 기한이 너무 짧았다고. 나도 초반 몇 번의 외주에서 이런 나쁜 태도를 가지곤 했다. 그러나 의견을 제시하지 않고 시키는대로 한것도 개발자의 잘못이다. 이 책에선 의사의 경우를 들어 설명한다. '어느 환자가 오래 기다릴 수 없으니 수술 전에 손을 씻지 말라고 요구한다면, 의사는 단호하게 거부해야 한다.'

이 책을 세 마디로 요약하면 '중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기'이다.

• 코드도 기승전결이 있어야한다는 내용이 신선했다. '해결할 문제의 긴장을 명확히 드러내고, 명백한 해법을 제시하며 문제를 풀어야 한다'고.
• 나쁜 코드가 쌓일수록 팀의 생산성은 떨어진다. 그러다가 마침내 0에 접근한다. 심지어 회사를 망하게까지 한다. 'Killer app을 개발했던 한 회사가 나쁜 코드 때문에 제품 출시 주기가 점점 길어지고 이전 버전의 버그가 새로운 버전에 남아있고, 프로그램이 죽는 횟수도 늘어나고, 이를 고치면서 제품 출시를 맞추기 위해 나쁜 코드가 더 양산되고...를 반복하며 결국 사용자가 등을 돌리고 회사가 망했다는' 무시무시한 상황도 소개되었다.

2. 의미 있는 이름

클래스 이름으로는 Data, Info 같은 일반적이고 의미없는 이름은 피하라는 점이 흥미로웠다. 옛날처럼 변수 길이를 더이상 제한하지 않기 때문에 길더라도 서술적인 이름을 쓰는게 좋다. 같은 모듈 내에서는 같은 명사/동사를 쓴다. 되도록 알고리즘 이름, 패턴 이름 등 해법 영역에서 온 이름을 사용하고, 이게 없거나 문제 영역(domain)의 맥락이 중요하다면 여기서 온 이름을 쓴다.

3. 함수

1. 작게, 더 작게

하나의 메소드에 하나의 기능만. SRP(Single Responsibility Principle)를 존중한다. 함수는 한가지만하고 그 한가지를 '잘'해야 한다. 그렇다면 함수가 한가지만 하는지는 어떻게 판단할까? 함수명을 다른 이름으로도 표현할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 일반적인 기준은 'getter(조회)인지, setter(명령)인지' 이다.

당연히 하나의 함수에 추상화 수준은 하나여야 한다. 추상화 수준이 다르다면 여러 단계로 나눠서 정의하고 수행한다. 들여쓰기는 2단을 넘으면 좋지 않다.

2. 추상화 수준이 높은 함수부터 정의한다. '위애서 아래로 코드읽기'

한 메소드 안에서 다른 메소드를 불러올 때 부르는 함수를 먼저, 불러지는 함수를 나중에 정의한다. 그리고 이어지는 코드에서 그 메소드가 정의될 것을 기대하는 것이 자연스럽다. 당연히 코드 흐름이 고차원에서 저차원으로 진행되기 때문에 이해하기도 쉽다. DRF 의 mixins.py는 아래와 같이 적혀있다.

• React 의 encapsulation?

# mixins.py

class DestroyModelMixin(object):
    """
    Destroy a model instance.
    """
    def destroy(self, request, *args, **kwargs):
        instance = self.get_object()
        self.perform_destroy(instance)
        return Response(status=status.HTTP_204_NO_CONTENT)

    def perform_destroy(self, instance):
        instance.delete()

destroy()를 래핑해서 perform_destroy()라는 함수를 만들었다. 불러와지는 메소드명이 명확해야 이 함수가 어떤 기능을 수행할지 미리 짐작할 수 있다.

3. 함수 인수

'최선은 무항 함수, 차선은 1항 함수'라는 주장이 흥미로웠다. writeField(name)이 writeField(outputStream, name) 보다 이해하기 쉽다. 다항 함수가 항상 이해하기가 어려워서 좌절하곤 했는데 나만 어려운게 아니라니 다행이다. 이항 함수를 쓰는 경우는 좌표를 표현할 때처럼 두개 인자가 자연적인 순서가 있는 경우다. 인수가 많아진다면 outputStream.writeField(name)과 같이 클래스 변수로 선언하는 방법도 있다.

• Dijkstra 알고리즘(최단 경로 찾기)을 개발한 Edsger Dijkstra는 모든 함수에서 입구와 출구가 하나만 존재해야 한다고 주장했다. 루프안에서 break이나 continue 를 쓰는 것을 지양하고 한번의 return만 하도록.
• 결론은 훌륭한 프로그래머는 시스템을 '구현할' 프로그램이 아니라 '풀어갈' 이야기로 여긴다. 함수는 이야기를 풀어가는 언어이다.

4. 주석

주석은 언제, 어떻게 달아야 할까? 저자는 주석을 달지 말라고 이야기 한다. License 정보를 담는 것이 아닌 이상, 필요가 없다. 코드와 주석도 항상 동기화해야하며 중언부언 달린 주석은 오히려 코드를 읽는 것을 방해한다. 차라리 설명이 필요 없는 깨끗한 코드를 쓰자.

5. 형식 맞추기

연관된 함수끼리는 수직 거리를 가깝게, 변수는 사용하는 위치에 최대한 가까이 선언하기, 이외에는 줄바꿈으로 개념 분리(import문과 함수 사이 줄바꿈) 등 형식에 관한 내용이었는데 아직은 에디터에 의존하는게 마음이 편하다. PEP8 스타일 가이드를 참고하거나 Pylama 같은 도구를 활용할 수도 있다.

6. 객체와 자료 구조

1. 추상화

사용자가 구현이 어떻게 되어 있는지 알 필요가 없다. 자료를 세세하게 공개하기 보다는 추상적인 개념으로 표현하는게 좋다. 추상화 수준에 따라 함수를 wrapping 하여 논리를 숨겨주는 기법이 유용하다.

# 구체적 Bad
class Vehicle:
    def getFuelTankCapacityInGallons():
        # pass
    def getGallonsOfGalsoline():
        # pass

# 추상적 Good
class Vehicle:
    def getPercentFuelRemaining():
        # pass

2. 객체 지향 vs 절차 지향

새로운 데이터 타입이 필요한 경우라면 클래스/객체 지향 기법이 적합하다. 반면, 새로운 함수가 필요한 경우라면 절차/자료구조가 적합하다. 시스템을 새로 짤 때 어떤 부분이 유연해야 할지 판단하고 선택하는 것이 좋다. 객체 지향은 자료를 숨기고 동작(함수)을 공개한다. 그래서 새로운 객체를 계속 찍어내기는 쉽지만 클래스 내 새로운 메소드를 추가하기는 골치아플 수 있다. 반면 자료구조 형태로 구현했을 경우, 자료를 숨기지 않고 별다른 동작도 없다. 그래서 새로운 동작을 추가하기 쉽다.

객체와 절차를 고민하며 코딩해본 적이 없어서 이 부분은 잘 와닿지 않았다. 나중에 다시 한번 읽어봐야 할 내용이다.

'Coding is as much an art as it is a science'
- Rebecca Parsons

To be continued!