[개발자 책읽기] 클린 코드-애자일 소프트웨어 장인 정신 (3장 함수)

해당 글은 Robert C.Martin 클린 코드 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 클린 코드 - 애자일 소프트웨어 장인 정신 에서 확인해주세요.

 

클린 코드 - 애자일 소프트웨어 장인 정신 (Uncle Bob)

 

• 위키북스
• 지은이: Robert C.Martin (Uncle Bob)
• 옮긴이: 박재호, 이해영

 

 

---

 

이번 장에서 이야기하고자 하는 것

 

이번 장에서는 좋은 함수에 대해 이야가를 하고 있다.

 

함수는 한 가지를 해양한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야한다.

 

작게 만들고 한 번에 한 가지만 해라

 

• 한 함수는 6 ~ 7 줄 정도로 표현할 수 있어야 한다.
• 중첩된 if / while / for 를 사용하지 않아야 한다.
• 그래야 읽기 편해지고 이해하기 쉬워진다.
• 한 가지만 해라
  • 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
• 함수 당 추상화 수준은 하나로
  • 함수가 확실히 한 가지를 하기 위해서는 함수 내 모든 문장의 추상화 수준이 동일해야 함
    • render() 는 높은 추상화
    • Http.get(uri) 는 중간 추상화
    • String.valueOf("abs"); 는 낮은 추상화ㄴ
  • 한 함수 내에서 추상화 수준이 섞여있으면 읽는 사람이 헷갈림

 

서술적인 이름을 사용해라

 

• 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨꿋한 코드라고 부른다는 워드의 말
• 이름이 짧고 어려운 이름보다 서술적 이름이 더 좋다
• 이름을 정하느라 시간을 들여도 괜찮다

 

함수 인수

 

• 관점에 따라
  • 가독성의 관점
    • 이상적인 함수 인수는 0개 이며 1, 2, 3 순차적으로 간다
    • 읽는 사람은 void convert(String a, char[] b) 보다 void convert() 가 더 직관적이다
  • 테스트 코드의 관점
    • 인수가 3개라면 그 만큼 조합해야할 테스트 케이스가 늘어난다.
• 최선은 인수가 0개, 차선은 인수가 1개
• 플래그 인수는 한 번에 여러가지를 한다고 하는 것이므로 매우 좋지 않다.
  • true 면 이것을 하고 false 면 저것을 하기 때문
• 동사와 키워드를 조합하라

 

명령과 조회를 분리하라 + 오류 코드보다는 예외를 사용하라

 

• 함수는 무언가를 수행하거나 무언가에게 답하거나! 둘 중에 하나만 해야 한다.
• 오류 코드를 사용한다는 것은 명령과 조회 규칙을 위반한다.
  • 오류 코드를 명시하고 개발했다면 어디선가는 해당 코드를 정의하고 어디서는 import 한다는 뜻
  • 그럼 오류 코드 정의가 바뀐다면 그를 import 하는 모든 코드에서 의존이 생가게 되고 compile 에 관련이 있다는 의미가 됨 -> 이를 의존성 자석이라고 표현
• 즉, Try-Catch 블럭을 이용하자
  • 위에서 말한 의존성 자석을 끊을 수 있다.
  • 새로운 예외는 Exception 에서 파생되기 때문에 새 예외를 추가하더라도 의존성 자석이 끊기게 됨

 

함수를 어떻게 짤 것인가?

 

• 소프트웨어를 개발하는 행위는 여느 글짓기와 비슷하다.
• 글짓기 순서 : 초안 작성 -> 말 다듬기, 문단 정리 -> 출판
• 코딩 순서 : 처음에는 길고 복잡해도 좋다. 중첩된 루프토 괜찮다. 그런 다음 테스트케이스를 짜고 코드를 다듬으며 함수로 extract 하여 중복을 줄이고 제거한다. 이런 와중에도 테스트를 모두 통과하게 한다
• 이러한 순서를 최종적으로는 이 장에서 설명한 규칙에 따르도록 하면 된다.
  • 처음부터 완벽하게 짤 필요가 없다. 그것은 불가능하다

 

결론

 

• master 프로그래머는 시스템을 구현해야하는 프로그램이 아니라 풀어갈 이야기라고 여긴다.
• 이번 장에서는 함수를 특정한 규칙에 따라 잘 만드는 것에 집중하였지만 진짜 목표는 시스템이라는 이야기를 풀어나가는데 있다.

 

나의 해석과 회고

 

함수 인수를 읽고 있으니 사내에서 팀 리더가 했었던 말이 생각이 났다.

Test Code 를 보다가 assertEquals() 과 assertThat().isEqualTo() 가 있었는데, 내가 왜 전자를 사용하지 않고 후자를 사용하는가? 에 대한 질문을 했었다.

 

리더는 나에게 명확히 하기 위해서 라고 답변했던 것이 생각이 났다.

그 당시에는 어떤 말인지 정확히 이해가 가지 않았지만 이제야 알것 같다.

 

assertEquals() 는 정확히 assertEquals(expected, actual) 이다

 

assertEquals()는 2개의 인자를 받는데, 2개의 인자 순서에 따라서 해당 테스트 코드를 읽는 사람으로 하여금 혼동을 불러일으킬 수 있다고 생각된다.

 

그래서 위와 같은 경우는 assertExpectedEqualsActual(expected, actual) 처럼 동사와 키워드를 조합하는 네이밍이 더 적절하다고 보고, 가장 좋은 방법은 Chaining 을 통해 assertThat().isEqualTo() 와 같이 표현하는 것이 좋다고 생각이 된다.