Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
TIL-assignment #5. 3장 함수
#clean_code
2년 전
828


TIL (Today I Learned)

오늘 읽은 범위 : 3장 함수

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

  • 작게 만들어라.

    if/else/while문에 들어가는 블록은 한 줄이어야 한다. 즉, 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.

  • 함수는 한 가지만 해야한다. 여기서 말하는 한가지란 추상화 수준이 하나인 단계를 말한다. 함수가 한 가지만 하는지 판단하는 방법으로 "의미 있는 이름의 다른 함수"를 추출할 수 있는지 파악한다.

  • 추상화에도 수준이 있다. 코드는 위에서 아래로 읽혀야 좋기 때문에 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. (내려가기 규칙)

  • switch문이나 if/else문은 작게 만들기 어려운데, 이 경우, switch문을 저차원 클래스에 숨겨 반복되지 않도록 한다. 즉, 추상 팩토리함수를 만들어 switch문의 유형(case)에 대한 인스턴스를 생성한다.

  • 서술적인 이름을 사용하라. testableHTML -> SetupTeardownIncluder.render

  • 함수 인수는 적을수록 좋다. 가장 좋은 건 인수가 없는 함수.인수가 여러개 필요하다면 독자적인 클래스로 묶을 방법을 생각해보자.
    단항 함수는 동사/명사 쌍을 이뤄야 한다. ex. writeFiled(name): name이라는 field에 작성하는 함수
    다항 함수에서는 함수 이름에 인수를 "키워드"로 넣어서 인수 순서를 명확히 할 수 있다. ex. assertEquals(expected, actual) -> assertExpectedEqualsActual(expected, actual)

  • 함수에서 인수는 입력으로 사용해라. 객체지향언어에서 출력 인수로 사용하도록 설계한 것이 this이다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택해라.
    ex. appendFooter(report) -> report.appendFooter(): report에 footer를 추가함.

  • 명령(뭔가를 수행)조회(뭔가에 답하기)를 분리해라.
    ex. if(set('username', 'bob')) {}
    -> if (attributeExists('username')) {setAttribute('username', 'bob')}

  • 오류 코드보다 예외를 사용하라. 오류 코드를 반환하기 보단 try/catch로 예외를 처리하면 오류에 대해 처리해야 하는 코드가 원래 코드에서 분리될 수 있다. 또한 try/catch 블록은 정상 동작과 오류 동작을 뒤섞기 때문에 별도의 함수로 분리하는 것이 좋다.

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

  • "반복하지 마라"라는 소제목 하에서 하위 루틴을 발명한 이래로 지금까지 일어난 혁신을 소스 코드에서 중복을 제거하려는 지속적인 노력으로 볼 수 있다고 설명한 점이 인상깊었다. 객체지향형프로그래밍의 상속이나, 구조적 프로그래밍, AOP, COP 등을 지금까지는 서로 다른 어떠한 패러다임으로 생각했는데 모두 중복을 없애는 것이라는 공통점으로 설명될 수 있다는 점에서 이 책의 저자가 모든 개념들에 대해 얼마나 깊이 통찰하고 있는지를 느낄 수 있었다.

  • 대가 프로그래머는 시스템을 "구현할 프로그램"이 아니라 "풀어갈 이야기"로 여긴다. 이 문장은 어떤 방향성을 추구하며 설계해나가야 할지를 한 번에 표현해준다고 생각한다.
    프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 표현력이 강한 언어(=함수)를 만들어 이야기를 풀어간다. 라는 표현에서 이 책의 "3장.함수"의 존재 이유가 와 닿았다. 우리는 어떻게 프로그래밍 언어를 clean하게 작성할까를 고민하기 때문에 이 책을 읽는다. 그렇다면 함수 역시 "언어"이기 때문에 어떻게 clean하게 작성할지를 고민해야 하는 것이다.

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

  • SRP(Single Responsibility Principle)를 위반한다. -> 코드를 변경할 이유가 여럿이기 때문

  • OCP(Open Closed Principle)를 위반한다. -> switch문의 case를 추가할 때마다 코드를 변경하기 때문

  • 다형성(polymorphism)