들어가면서

읽기 쉬운 코드라는 책의 서평 이벤트에 당첨되어 책을 받았다. 책의 서문에서는 이 책의 핵심 독자는 엔터프라이즈 개발자(특히 백엔드 개발자)라고 말하는데, 개발자로서 공통적으로 가지는 부분에 대해선 이견 없이 읽을 수 있었다. 예제 코드는 C#을 기본으로 다루고 있다. 이 책을 읽는 한 가지 팁이 있다면, 책을 처음부터 읽으려고 하기보다 책의 가장 뒷면에 있는 프랙티스 목록 파트를 먼저 읽어보는 것을 추천한다. 실제로 실천할 수 있는 부분들을 제시해 주고, 이에 관련한 스킬 부분의 페이지 가이드대로 따라가면 훨씬 실용적으로 읽을 수 있다.

이번 글에서는 읽고 나서 와닿았던 부분들을 정리해 보려고 한다.

본론

3장 복잡성을 잘 다루는 방법

소프트웨어 공학이 해결해야 하는 가장 핵심적인 문제는 소프트웨어 자체가 너무 복잡해서 인간의 두뇌에 잘 맞지 않는다는 점이다. 뇌는 제한된 복잡성만 처리할 수 있다. 인간의 단기 기억은 7개 대상을 추적할 수 있는데, 주의를 기울이지 않으면 7개 이상의 일을 처리하는 코드를 만들게 된다. 컴퓨터는 이 부분을 관리해 주지도, 막아 주지도 않는다. 소프트웨어 공학은 복잡성을 증가시키지 않겠다는 의도를 담은, 신중한 과정이어야 한다. 오히려 작업이 느려질 수 있다고 반발할 수 있지만, J.B. 라인베르거의 말을 인용하자면, "우리는 조금 느려질 필요가 있다. 입력 속도가 빠를수록 모든 사람이 유지 관리해야 하는 코드가 늘어난다. 코드는 자산이 아니라, 책임이다."

13장 관심사의 분리

관련 없는 관심사들을 분리하십시오. 사용자 인터페이스를 바꾸는 데는 데이터베이스 코드를 편집하는 부분이 들어 있지 않아야 하며, 그 반대도 마찬가지이다. 관심사의 분리는 코드베이스의 다양한 부분을 분리해야 함을 의미합니다. 분해는 분리되었던 부분을 재조합할 수 있을 때만 의미가 있습니다. 순수 함수의 반환값이 다른 순수 함수의 입력으로 들어가는 형태를 가지는 순차적 조합이 머리에 잘 들어오는 더 좋은 대안입니다.

회사에서 소위 객체 지향 코드베이스라 부를 만한 것을 단번에 내버리고, 하스켈에 자리를 내주리라 기대하지는 않습니다. 대신 함수형 코어, 명령 셸의 형태로 나아가는 것을 권하고 싶습니다. 그렇게 하면 코드베이스에서 순수 함수 형태로 구현되지 않은 부분을 분리하기가 쉬워집니다. 이런 작업은 일반적으로 횡단 관심사 문제를 적용해야 하는 부분이면서 데코레이터로 가장 잘 처리할 수 있는 부분이기도 합니다.

50/72 규칙

깃 커밋 메시지 작성

• 요약은 50자 이내, 명령형으로 작성
• 내용을 추가할 경우 두 번째 줄은 빈 줄로 두기
• 각각의 줄은 72자를 넘지 않도록 작성

80/24 규칙

• C에 기반한 언어인 경우, 문자 80 x 24줄 크기를 유지하는 것이 좋다. 이 크기는 터미널 창에 해당한다.
• 실제로 잘 동작하며 전통적으로 사용해온 값을 따른 것이다.
• 80/20 파레토 원칙과 비슷하다.
• 하지만 이 크기를 너무 문자 그대로 받아들이지 말라.

이분법

• 문제의 원인을 알아내기 어려운 상황이라면 이분법이 유용할 수 있다.
• 코드의 절반을 제거한 후 여전히 문제가 있는지 확인 해 보기
• 동작하는 가장 작은 예제를 찾아낼 때까지 코드를 줄여나가기

함수형 코어, 명령 셸

• 궁극적인 추상화란 참조투명성 이다.
• 참조투명성은 프로그램의 동작을 변경하지 않고, 함수 호출을 그 결과로 대체할 수 있다.
• 순수 함수 역시 잘 구성되며, 유닛테스트를 하기도 쉽다.

정보 전달 단계

• 자신을 포함한 미래의 독자를 위해 코드를 작성하세요.
• 다음 우선순위 목록에 따라 행동과 의도를 알려주는 것이 좋다.

1. API에 특유의 데이터 형식을 제공해서 독자에게 정보를 주세요.
2. 메서드에 유용한 이름을 지정해서 독자에게 정보를 주세요.
3. 좋은 주석을 작성해서 독자에게 정보를 주세요.
4. 자동화된 테스트 코드를 사용하는 예제를 제공해서 독자에게 정보를 주세요.
5. 깃 커밋 메시지를 잘 작성해서 독자에게 정보를 주세요.
6. 좋은 문성를 작성해서 독자에게정보를 주세요.

결론

이 책은 읽기 쉬운 코드를 만들기 위한 방법들을 제시해 주는데 위의 본론 내용 외에도 다양한 방법 들을 이야기 한다. 백과사전만큼 긴 스토리는 아니지만 그렇다고 짧은 스토리도 아니다. 한번씩 프랙티스 목록을 보면서 내가 어떤 부분을 개선해 나갈 수 있을지 생각해 보는 것도 좋을 것 같다.