TIL (Today I Learned)

2022/02/23

오늘 읽은 범위

3장 함수

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

• 작게 만들어라! ->

함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.

• 한가지만 해라!->

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

• 내려가기 규칙 (위에서 아래로 읽기)->

코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. TO문단 읽듯이 프로그램이 읽혀야 한다.

ex) TO 무엇을 하려면, A를 하고,B를 하고, C를 해야 한다.

TO A를 하려면, 이렇게 해야한다.

TO B를 하려면, 이렇게 해야한다.

TO C를 하려면, 이렇게 해야한다.

• 서술적인 이름을 사용하라! ->

-"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다." 한 가지만 하는 작은 함수에 좋은 이름을 붙인다면 이런 원칙을 달성함에 있어 이미 절반은 성공했다.

-길고 서술적인 이름이 짧고 어려운 이름보다 좋다.

-길고 서술적인 이름이 길고 서술적인 주석보다 좋다.

• 동사와 키워드 ->

단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야한다.

• 명령과 조회분리 ->

if(set("username","unclebob"))

->

if(attributeExists("username")){

setAttribute(""username","unclebob");

}

개발자는 "set"으로 의도했으나. if문에 넣고 보면 형용사로 느껴진다.

그래서 if문은 "username"을 "unclebob"으로 설정되어 있다면으로 읽힌다.

"username"을 "unclebob"으로 설정하는데 성공하면으로 읽히지 않는다.

해결책은 명령과 조회를 분리해 혼란은 애초에 뿌리뽑는 방식이다.

• 오류 코드보다 예외를 사용하라! ->

오류 코드 대신 예외를 사용하면, 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.

• 대가 프로그래머는 시스템을 프로그램이 아니라 이야기로 여긴다.

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

• p.43에 예제로 들어준 Sparkle(자바/스윙) 프로그램을 보며, 나의 개인 웹사이트를 만들 때가 떠올랐다. 꽤나 어려워 보이고 복잡한 효과를 넣고 싶었는데, "이걸 어떻게 했을까?" 하며 찾아보니 매우 간단한 코드에 놀란 적이 있다. 사실 나는 어려워 보이는 기능이나 효과를 짧게 구현해냈을 때, 흥미를 느꼈던 편이라 매우 공감이 갔던 구문이었다.

• 사실 1장 2장에 비해 3장은 나에게 매우 어려웠다. 읽어나가는 속도도 느려졌고, 이해하지 못하는 개념도 많았다. 하지만 앞으로 실무에 나간다고 생각했을 때, 꼭 필요한 개념이며 중요한 이야기이기에 여러 번 읽어서 내 것으로 만들어가야겠다.

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

• 추상화-> 추상화는 로직에서 핵심 개념을 뽑아내는 것이라고 생각하시면 됩니다.
  코드를 모두 디테일하게 구현하는 것보다, 중요한 개념만 남기고 나머지는 추상화하는 방식입니다.

  https://kyuhyuk.kr/article/react/2021/12/09/Frontend-Clean-Code (추상화 개념 이해에 도움이 되었던 곳)

• OCP(Open Closed Principle) -> 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.

• 의존성 자석 ->오류 코드를 반환한다는 이야기는 어디선가 오류 코드를 정의한다는 뜻이며, 여러 클래스에서 오류 코드를 정의한 클래스를 사용하므로 다시 컴파일하고 다시 배치해야 한다. 그러므로 해당 클래스는 의존성 자석이다. https://velog.io/@krhong/CLEAN-CODE-%ED%95%A8%EC%88%98

• 구조적 프로그래밍 -> 절차적 프로그래밍

• AOP ->AOP는 Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다. 관점 지향은 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다. 여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다.