TIL (Today I Learned)

2024.01.30

오늘 읽은 범위

3장. 함수

책에서 기억하고 싶은 내용을 써보세요.

• 함수를 작게 만들어라 (p.42)

• 함수는 한 가지를 해야 한다. 그 한가지를 잘 해야한다. 그 한가지만을 해야한다. (p.44)

• 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다.(p49)

• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. (p49)

• 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. (p. 61, 공감되는 문장)

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 사실 함수를 단위 별로 작게 만들고 한가지만 해야한다는 것은 익히 들어서 알았던 내용들이다. 하지만 다시금 읽으면서 오늘 혹은 과거의 작성한 나의 코드를 돌아보게 되었다.. (반성,.)

• 해당 챕터에서 큰 덩어리(?) 함수를 시작으로 함수의 클린 코드 조건을 따라가며 리팩토링 하는 과정을 보여준다. 함수가 쪼개지면서 제 역할을 확실히 정의하는 동시에 그에 따라 함수의 이름도 재정의되는데, 역시나 네이밍이 중요한 것 같다. 이름으로써 함수의 역할을 확실히 정의내릴 수 있었고 함수의 역할이 예상되었다.

  코드를 동작하는데 있어 대수롭지 않게(?) 여겨질 수도 있는 네이밍이 다른 챕터에도 언급되는 것을 보면서 클린 코드의 시작은 네이밍이라는 기본을 단단히 다질 수 있었다.

• 코드를 작성할 때 인자의 개수는 최대한 적게 유지하려고 노력했던 것 같은데, 불리언 값을 인자로 넘기는 것에 대해서는 대수롭지 않게 작성했다.함수 내부에서 분기처리를 너무나도 당연하게 작업했었는데 해당 챕터를 읽고 보니 함수의 역할은 한가지 라는 중요하고 알고있다고 자부했던 규칙을 스스로 위배하고 있었다..!!🤯 (반성..)

• 코드를 작성하는 것도하나의 글짓기. 작성하고 함수로 쪼개기로 수정을 반복하면서 클린 코드를 작성하자! 처음부터 어떤 함수를 정의내릴지 고민하면서 디테일한 설계에 시간쓰지말고 작성하고자 하는 내용에 대한 설계만 하고 코드를 쓰면서 다듬자. 처음부터 잘하려고 겁먹지말자. 나에겐 리팩토링있다!

• 오류 코드보다는 예외처리를 하자. 오류를 잡겠다고 조건문 파티를 펼쳤던 나의 지난 코드를 반성하게 되었다. 예외처리도 하나의 역할이므로 예외처리를 하는 공통 함수를 만들거나 클래스화 해봐야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 없었습니다!