[TIL] 클린코드(Clean Code) - 3장. 함수

📆 TIL (Today I Learned) 날짜

2022.02.22

📚 오늘 읽은 범위

3장. 함수

📝 책에서 기억하고 싶은 내용

• 켄트가 코드를 보여줬을 때 나는 함수가 너무도 작아 깜짝 놀랐다. 그때까지 나는 장황하게 긴 스윙 프로그램 함수에 익숙했다. 그런데 Sparkle은 모든 함수가 2줄, 3줄, 4줄 정도였다. 각 함수가 너무도 명백했다. 각 함수가 이야기 하나를 표현했다. 각 함수가 너무도 멋지게 다음 무대를 준비했다. 바로 이것이 답이다! (p.43)
• 함수가 '한 가지'만 하는지 판단하는 방법이 하나 더 있다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. (p.45)
• 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. 나는 이것을 내려가기 규칙이라 부른다. (p.46)
• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 서술적인 이름을 사용하면 개발자 머릿속에서도 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다. (p.49)
• 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)는 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다. 인수는 어렵다. 인수는 개념을 이해하기 어렵게 만든다. (p.50)
• 명령과 조회를 분리하라! 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다. 둘 다 하면 혼란을 초래한다. (p.56)
• 오류 코드보다 예외를 사용하라! 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다. 자칫하면 if문에서 명령을 표현식으로 사용하기 쉬운 탓이다. 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다. (p.57)
• try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다. 그러므로 try/catch 블록을 별도 함수로 뽑아내는 편이 좋다. 정상 동작과 오류 처리 동작을 분리하면 코드를 이해하고 수정하기 쉬워진다. (p.58)
• 오류 처리도 한 가지 작업이다. 함수는 '한 가지' 작업만 해야 한다. 오류 처리도 '한 가지' 작업에 속한다. 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다. 함수에 키워드 try가 있다면 함수는 try 문으로 시작해 catch/finally 문으로 끝나야 한다는 말이다. (p.59)
• 함수를 어떻게 짜죠? 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 논문이나 기사를 작성할 때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리한다. 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라. (p.61)
• 대가(master) 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다. 시스템에서 발생하는 모든 동작을 설명하는 함수 계층이 바로 그 언어에 속한다. 재귀라는 기교로 각 동작은 바로 그 도메인에 특화된 언어를 사용해 자신만의 이야기를 풀어간다. (p.62)

😀 오늘 읽은 소감 및 떠오르는 생각

• 지난 프로젝트에서 오류코드를 반환 받아서 그 오류코드가 뭔지 보고 해당 로직을 수행하는 방식의 코드를 작성한적이 있다. 근데 이번 클린 코드 책을 읽으면서 그런 방식이 아주 비효율적이란 것을 깨달았다. 앞으로는 예외를 잘 활용하여 코드를 깔끔하게 짜봐야겠다.
• 함수 이름을 지을 때 타이핑이 오래 걸리지 않게 되도록이면 짧고 압축적으로 짓는 것이 좋은 것이라 생각했는데 그런 방식이 안 좋다는 것을 알았다. 함수 이름은 길어도 좋으니 서술적인 이름을 사용하여 누구나 함수 이름만 보고도 이 함수가 어떤 작업을 하는지 알 수 있도록 해야겠다.
• 함수 인수의 개수가 많으면 좋지 않다는 사실을 몰랐는데 이번에 깨닫게 되었다. 되도록이면 인수의 개수를 줄이도록 노력해야겠다. 되도록이면도 아니고 노력하는 것도 아니고 그래야만 하겠다!
• 그동안 함수는 한 가지 작업만 해야 좋다는 것을 몰랐다. 그냥 이 함수 호출하면 이런거 좌라락~ 처리되게 하는게 편하고 좋은 것이라 생각했다. 어떤지 그 함수를 수정 할 일이 생기면 그 후처리 작업을 너무 많이 해줬어야 했고 그래서 시간도 오래 걸리고 그랬다. 이제야 그 이유를 알았다. 앞으로는 그러지 말아야지..
• 코드 작성을 할 때 너무 한번에 탁 짜내려 노력하지 않아야겠다. 작성하기도 전에 머리속으로만 생각하면서 머리만 굴리다 정작 코드 작성 시작도 못하고 작업 속도만 더뎌지는 일이 발생하곤 하는데 일단 작성하고 그 후에 계속 다듬어 가는 방식이 더 효율적이겠다.

🤔 궁금한 내용 및 잘 이해되지 않는 내용

• SRP(Single Responsibility Principle) : 단일 책임 원칙, 변경해야 하는 이유는 오직 하나여야 한다.
• OCP(Open Closed Principle) : 개방 폐쇄의 원칙, 확장(상속)에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.

클래스 설계 원칙