2024.8.26-27
💡 책에서 기억하고 싶은 내용
<aside>
💡 작게 만들어라
- if/else, while문 등에 들어가는 블록은 한 줄이어야 한다. 중첩구조가 생길만큼 함수가 커져서는 안된다. 함수에서 들여쓰기 수준은 1단이나 2단 넘어셔면 안된다.
</aside>
<aside>
💡 한 가지만 해라
- 함수는 한 가지를 해야한다. 그 한 가지를 잘 해야 한다. 그 한가지만을 해야한다.
- 의미있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
</aside>
<aside>
💡 함수당 추상화 수준은 하나로
- 코드는 위에서 아래로 이야기처럼 읽혀야 한다.
- 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다.
- 각 함수는 다음 함수를 소개한다.
</aside>
<aside>
💡 switch case
- switch문은 작게 만들기 어렵다. 각 switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법이 있는데
다형성을 이용하는 것이다.
</aside>
<aside>
💡 서술적인 이름을 사용하라.
- 모듈 내에서 함수 이름은 같은 문구, 명사, 동사 사용한다.
</aside>
<aside>
💡 함수 인수
- 함수에서 이상적인 인수 개수는 0개다. 다음은 1개, 다음은 2개다. 3개는 가능한 피하는 편이 좋다. 4개 이상은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다.
- 함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지이다. 하나는 인수에 질문을 던지는 경우다. 다른 하나는 인수를 뭔가로 변환해 결과를 반환하는 경우다.
- 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다. (예:
writeField(name) )
- 함수 이름에 키워드 추가하는 형식. 즉 함수 이름에 인수 이름을 넣는다.
예:
assertExpectedEqualsActual(expected, actual (인수 순서를 기억할 필요가 없음)
</aside>
<aside>
💡 부수 효과를 일으키지마라
- 객체 지향 언어에서는 출력 인수를 사용할 필요가 거의 없다. 출력 인수로 사용하라고 설계한 변수가 바로
this
- 일반적으로 출력인수는 피해야 한다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.
</aside>
<aside>
💡 오류코드보다 예외를 사용하라
- try/catch 블록을 별도 함수로 뽑아내는게 좋다.
- 오류 처리도 ‘한 가지’ 작업에 속한다. 그러므로 오류를 처리하는 함수는 오류만 처리해야한다.
</aside>
<aside>
💡 반복하지 마라
</aside>
<aside>
💡 구조적 프로그래밍
- 함수를 작게 만든다면 간혹 return, break, continue를 여러 차례 사용해도 괜찮다. 오히려 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다.
</aside>
💡 읽은 소감
함수에 파라미터를 많이 넣어야 진정한 개발자처럼 보이는 거라고 생각했는데 오히려 정반대였다. 파라미터가 없을 수록 클린 코드라니!!😅 만약 이 책을 읽지 않았다면 나의 잘못된 생각으로 계속 코드를 작성할 뻔 했다.
왜 파라미터가 많아야 좋은 코드라 생각했냐면 chatGPT에서 코드 수정 도움을 받을 때 함수에서 파라미터를 받아 작성해주는 경우가 많았다. 그래서 아직 ‘코드를 보는 눈’이 없는 초보자인 나는 함수에 무조건 파라미터가 있어야하는구나라고 생각했기 때문이다. 챗gpt에 너무 의존하기보다는 클린코드와 같은 개발서적도 자주 읽으면서 ‘코드 코어’를 길러야겠다고 생각했다.
💡 궁금한 점
💡 3줄 요약
함수는 한 가지를 해야한다.
코드는 위에서 아래로 이야기처럼 읽혀야 한다.
시스템을 구현할 프로그램이 아니라 풀어갈 이야기로 여겨야한다. 함수가 분명하고 정확한 언어로 깔끔하게 맞아떨어진다면 이야기를 풀어가기가 쉬워진다.