함수를 작게 만들어라 => 100줄을 넘어서는 절대 안 되고, 20줄도 길다. => 3000줄이나 되는 끔찍한 함수를 만들지 말자. => if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다. => 중첩 구조가 생길 만큼 함수가 커져서는 안 된다. 그래야 함수는 읽고 이해하기 쉬워진다.
한 가지만 해라! => 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다. => 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.
코드는 위에서 아래로 이야기처럼 읽혀야 좋다. => 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.
서술적인 이름을 사용하라! => 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
🤔오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
함수를 작게 만들어야 하는 것은 많이 들어봤지만 20줄도 길다는 얘기는 조금 충격적이었습니다. => 잘게 나누고 명확할수록 더 읽기 좋다는 것을 알게 되었습니다. => if 문 안에 들어가는 로직도 함수로 뺄 수 있으면 빼봐야겠습니다.
함수가 한 가지 일만 하도록 하는 것이 의미 있는 이름을 짓는데 큰 도움이 될 것 같습니다.
코드를 위에서 아래로 이야기처럼 읽히도록 한다는 게 마치 처음에 나왔던 책과 비슷하다는 내용이 생각납니다.
🔎궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
이런 규칙을 정할 때 가장 고민이 되는 것은 같은 팀원분들과 어떻게 타협점을 잡을지입니다. 만약에 팀원들이 이런 방식을 싫어한다면 어떻게 이해시키고 실행할지 고민됩니다.
회사에 입사해서 클린 코드에 나오는 방식을 사용하지 않으면 어떡할까 라는 고민도 같이 됩니다.
👀소감 3줄 요약
저자가 정말 명확하게 방법을 제시해줘서 리팩터링에 큰 도움이 될 것 같습니다.
깨끗한 코드는 끊임없는 관심 속에 만들어진다는 것을 느꼈습니다.
어제도 내가 작성한 코드를 리팩터링 하지 않았는데 오늘은 명확하게 목표를 설정해야겠습니다. => 지금 프로젝트에서 하루에 함수 한 개 리팩터링 해보기
한 개념에 한 단어를 사용하라 => 추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다.
메서드 이름은 독자적이고 일관적이어야 한다. => 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.
한 단어를 두 가지 목적으로 사용하지 마라. => 다른 개념에 같은 단어를 사용한다면 그것은 말장난에 불과하다.
불필요한 맥락을 없애라 => 짧은 이름이 긴 이름보다 좋지만, 의미가 분명해야 한다.
🤔오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
클린 코드를 읽으면서 내가 작성한 코드를 보니까 의미가 명확하지 않은 것들이 많았습니다. => 다행히도 주석을 달아놓아서 의미 파악은 가능했지만 없었으면 힘들었을 것입니다. => 예전에 작성한 코드를 보면서 비슷한 것들이 있는지 확인 후 교체하면서 연습 필요하다고 생각했습니다. => 직접 바꿔보면서 연습해 연습!
불필요한 맥락을 지우고 의미를 명확하게 한다는 것이 상당히 힘들다는 것을 느꼈습니다. => 처음에 나온 장인 정신처럼 내가 작성한 코드에 만족하지 못하는 성향이 있는 것 같습니다. => 다른 사람이 봤을 때 어떻게 생각할까 라는 고민을 하는 것 같습니다(팀원이 내 코드를 봤을 때).
🔎궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
문제 영역에서 가져온 이름을 사용하라(34p) => 문제 영역이 정확하게 어디인지 잘 모르겠습니다. => 구글에 'Problem Domain' 검색해서 의미 파악해보기
우수한 프로그래머와 설계자라면 해법 영역과 문제 해결 영역을 구분할 줄 알아야 한다.(35p) => 해법 영역은 프로그래머가 주로 사용하는 기술적인 용어를 얘기하는 것 같습니다(프로그래머 용어). ex) 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 -> JobQueue, AccountVisitor 등 => 문제 영역은 프로그래머보다는 고객의 영역에 가까운 것 같습니다(고객이 제시한 문제, 고객 친화적 용어).
작은 것에도 충실한 사람이 큰 것에도 충실하다. => 호미로 막을 일을 가래로 막지마라. => 일찍 일어나는 새가 벌레를 잡는다. => 오늘 할 수 있는 일을 내일로 미루지 마라.
좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. => 일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다. => 그들이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. => 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 행동은 전문가답지 못하다.
깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드다.
깨끗한 코드는 한가지에 '집중'한다.
깨끗한 코드는 단순하고 직접적이다.
깨끗한 코드는 다른 사람이 고치기 쉽다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
더러운 코드를 작성하고 재설계를 한다는건 상당히 힘들다. => 실제로 프로젝트 하면서 '우선 만들고 리펙토링 하자' 는 생각은 잘 안지켜졌다. => 재설계를 하자고 생각하지만 하나를 고치면 다른 곳도 문제가 생겨서 방관한 적도 있다.
나쁜코드를 작성해서 프로젝트 기간동안 다른 팀원에게 수정 사항을 받은적이 있다.
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다. => 코드가 추측이 아니라 사실이라는 말이 잘 모르겠습니다.
👀소감 3줄 요약
프로젝트를 진행과 동시에 클린 코드를 읽으면서 책 내용 활용
첫 부분을 읽으면서 왜 이 책이 좋다고 생각하는지 알게 되었습니다. => 개발자의 습관에 대한 내용 => 다양한 예시와 유명한 개발자들의 말을 인용
