[스터디] 클린코드 17장 (2022년 9월 14일)

앞에 작성하지 않는 단원들은 JAVA 친화적으로 너무 보기 싫어서 안 봤다 ㅋㅋ 

 

몰라 마지막 단원으로 17장 읽고 클린 코드는 여기서 마무리!

 

솔직히 17장만 읽어도 이 책이 어떤 말을 하려는지 알 수 있는 것 같다.

 

---

주석

극단적인것 까지는 아니지만 주석은 99% 필요 없다고 생각을 가지고 있다.

물론 이 책을 읽으며 생각이 점점 확고해지지만 확실히 코드를 보다 보면 관리되는 주석을 본 적이 없다.

그럴 바엔 차라리 안 쓰는 게 좋다는 생각이 점점 커지는 중... 

부적절한 정보

주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다.

예를 들어, 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템, 기타 기록 관리 시스템에 저장할 정보는 주석으로 적절하지 못하다. 이러한 것들은 git을 이용해서도 모두 관리할 수 있다.

쓸모없는 주석

오래된 주석, 엉뚱한 주석, 잘못된 주석은 쓸모가 없다.

쓸모 없어질 주석은 아예 달지 않는 편이 좋다.

코드와 무관하게 따로 놀며 그릇된 방향으로 이끈다.

중복된 주석

코드만으로 충분한데 구구절절 설명하는 주석이 중복된 주석이다.

성의 없는 주석

주절대지 않는다.

당연한 소리를 반복하지 않는다.

간결하고 명료하게 작성한다.

주석 처리된 코드

주석으로 처리된 코드를 발견하면 즉각 지워라, 걱정할 필요 없다. 소스 코드 관리 시스템이 기억하니까

 

함수

함수는 최대한 쪼개라.

진짜 클린코드 읽으면 지겹도록 나온다.

거의 세뇌 당하는 정도?

너무 많은 인수

함수에서 인수는 작을수록 좋다.

출력 인수

출력 인수는 직관을 정면으로 위배한다.

함수에서 뭔가의 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경한다.

플래그 인수

boolean 인수는 함수가 여러 기능을 수행한다는 명백한 증거다.

피해야 마땅하다.

죽은 함수

아무도 호출하지 않는 함수는 삭제한다.

 

일반

한 소스 파일에 여러 언어를 사용한다

이상적으로는 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다.

당연한 동작을 구현하지 않는다

최소 놀람의 원칙에 의거해 함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 동작과 기능을 제공해야 한다.

당연한 동작을 구현하지 않으면 코드를 읽거나 사용하는 사람이 더 이상 함수 이름만으로 함수 기능을 직관적으로 예상하기 어렵다. 저자를 신뢰하지 못하므로 코드를 일일이 살펴야 한다.

경계를 올바로 처리하지 않는다

모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성하라

안전 절차 무시

컴파일러 경고 일부, 전부를 꺼버리면 빌드가 쉬워질지 모르지만 자칫하면 끝없는 디버깅에 시달린다.

중복

DRY원칙

코드에서 중복을 발견할 때마다 추상화할 기회로 간주하라.

추상화로 중복을 정리하면 설계 언어의 어휘가 늘어난다.

가장 뻔한 유형은 똑같은 코드가 여러 차례 나오는 중복 → 간단한 함수로 교체한다.

여러 모듈에서 일련의 switch/case 나 is/else 문으로 똑같은 조건을 거듭 확인하는 중복 → 다형성으로 대체

알고리즘이 유사하나 코드가 서로 다른 중복 → TEMPLATE METHOD 패턴, STRATEGY 패턴으로 제거

죽은 코드

실행되지 않는 코드가 죽은 코드다.

아무도 호출하지 않는 유틸리티 함수와 switch/case 문에서 불가능한 case 조건도 하나의 예다.

수직 분리

변수와 함수는 사용되는 위치에 가깝게 정의한다.

일관성 부족

어떤 개념을 특정 방식으로 구현했다면 유사한 개념도 같은 방식으로 구현한다.

최소 놀람의 원칙에도 부합한다.

표기법은 신중하게 선택하며, 일단 선택한 방법이라면 신중하게 따른다.

선택자 인수

선택자 인수는 큰 함수를 작은 함수 여럿으로 쪼개지 않으려는 게으름의 소산이다.

일반적으로, 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 편이 좋다.

모호한 의도

코드를 짤 때는 의도를 최대한 분명히 밝힌다.

독자에게 의도를 분명히 표현하도록 시간을 투자할 가치가 있다.

잘못 지운 책임

코드는 독자가 자연스럽게 기대할 위치에 배치한다.

서술적 변수

프로그램 가독성을 높이는 가장 효과적인 방법 중 하나가 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 방법이다.

이름과 기능이 일치하는 함수

이름만으로 분명하게 어떤 기능을 나타내는지 알 수 있게 해야 한다. 그렇지 않다면 더 좋은 이름으로 바꾸거나 기능을 정리해야 한다.

알고리즘을 이해하라

구현이 끝났다고 선언하기 전에 함수가 돌아가는 방식을 확실히 이해하는지 확인해라. 작성자가 알고리즘이 올바르다는 사실을 알아야 한다.

매직 숫자는 명명된 상수로 교체하라

일반적으로 코드에 숫자를 사용하지 말라는 규칙.

숫자는 명명된 상수 뒤로 숨기라는 의미다.

조건을 캡슐화하라

조건의 의도를 분명히 밝히는 함수로 표현하라.

함수는 한 가지만 해야 한다

한 함수 안에 여러 단락을 이어, 일련의 작업을 수행하고픈 유혹에 빠진다. 이런 함수는 한 가지만 수행하는 함수가 아니다. 한 가지만 수행하는 좀 더 작은 함수 여럿으로 나눠야 마땅하다.

일관성을 유지하라

코드 구조를 잡을 때 이유를 고민해라. 그리고 그 이유를 구조로 명백히 표현하라. 만약 일관성이 없다면 남들이 맘대로 바꿔도 괜찮다고 생각한다.

 

이름

구현을 보기전에 이름으로 예측 가능하도록 만들자.

정말 이거 중요한 듯. 별 거 아닌거 같은데 진짜 이름 잘 붙여놓으면 대대손손 편안함

 

서술적인 이름을 사용하라

소프트웨어 가독성의 90%는 이름이 결정한다.

적절한 추상화 수준에서 이름을 선택하라

구현을 드러내는 이름은 피하라.

이름으로 부수 효과를 설명하라

함수, 변수, 클래스가 하는 일을 모두 기술하는 이름을 사용한다.

이름에 부수 효과를 숨기지 않는다.

 

---

이렇게 두번째 클린 코드는 끝이 났다.

 

이번 17장은 위에서도 말했듯이 이 책의 요약정리 같은 느낌?

 

이 모든 것을 지킬 수 없지만 지키려고 노력한다면 조금이라도 성장하는 게 아닐까 싶다.

 

코드 짜다가 이 책에서의 상황이 보이면 기분이 찜찜해서 하기 싫어도 자동으로 다시 코드를 짜고 있는 나를 발견할 수 있다.

 

클린 코드를 읽으라고 하는 이유를 알 것만 같다.

 

100% 흡수하지는 못했지만 찍먹 정도 한 것 같은데...

 

아직 읽어보지 못했다면 읽는 것도 나쁘지 않다. 그렇다고 너무 클린 코드에 얽매이지 말라는 얘기도 들리기도 한다.

 

자기 주관만 뚜렷하게 지키면 될 듯