📔

Clean Code

기억하고싶은 내용과 궁금증 및 견해

많은 개발자들이 말하는 적절한 추상화 뭘까?

개발자들이 자주 언급하지만 막연하게 이해하는 추상화 수준을 실전에서 어떻게 판단하고 적용할 수 있는지 구체적으로 알아보자.

tl:dr 함수 이름 + 추상화 수준 일관성 + 의미적 응집도

추상화 수준이란?

[3장] 함수

기억하고싶은 내용

우리는 저자다.
Javadoc 에서 @author 필드는 저자를 소개한다. 우리는 저자다. 저자에게는 독자가 있다.  그리고 저자에게는 독자와 잘 소통할  책임도 있다. 
다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하길 바란다. 

코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 읽기쉬운 코드가 짜기가 쉽지는 않더라도 말이다.  급하다면, 서둘러 끝내려면, 쉽게 짜려면 읽기 쉽게 만들면 된다.

[0- 1장] 깨끗한 코드

주석이 아닌 시스템이 말하게 하기

들어가면서

주석에 대해 진지하게 생각해보았던가? 남발은 하지 말고 꼭 필요한곳에 주석을 사용하자는건 알지만 남발의 기준은? 꼭 필요한곳의 기준은? 애매 모호한 부분을 좀 더 알아보려고 한다.

브라이언 w.커니헨, P.J.플라우거는 나쁜 코드에 주석을 달지말라. 새로 짜라.라고 한다. 코드로 그만큼 충분히 의도를 표현하지 못했다고 이해해볼 수도 있다. single of truth가 되는 코드가 이미 잘못되었는데 여기에 덧붙이는 주석은 오히려 문제점을 더 가지고 올 수 있다고 생각한다. 어떤 문제점이냐면 주석은 오래될 수록 코드에서 멀어진다. 그래서 결국 거짓말을 하게 되고 프로그래머들이 주석을 유지하고 보수하기가 현실적으로 어려워 지는 문제점이다.

[4 장] 주석 - 주석이 아닌 시스템이 말하게 하기

tl:dr 분별있는 프로그래머는 모든것이 객체라는 생각이 미신임을 잘 안다. 때로는 단순한 자료구조와 절차적인 코드가 가장 적합한 상황도 있다.

읽고나서 견해

챕터의 초반부터 getter/setter는 private 변수의 의미를 무색하게 만드는 자기모순적인 패턴이라고 비판한다. 변수를 숨기면서 동시에 노출하는 이 어중간한 접근이 객체도 자료구도조 아닌 마치 최악의 하이브리드를 만드는 모순을 보여주었다.

[6장] 객체와 자료구조 곱씹어보기

tl:dr 코드 형식은 단순히 스타일의 문제가 아니라 커뮤니케이션의 문제이다.

기억하고싶은 내용과 궁금증 및 견해

주요 내용들을 정리하자면 다음과 같다.

수직 형식 (Vertical Formatting)

•

파일 크기: 작은 파일이 이해하기 쉬움 (200~500줄 정도가 적당)

•

신문 기사처럼: 위에서 아래로 읽을 때 고수준 개념이 먼저, 세부사항은 아래로

[5장] 형식맞추기 - 단순한스타일이 아닌 커뮤니케이션의 문제