[클린 코드] 클린 코드 1~3

https://book.naver.com/bookdb/book_detail.nhn?bid=7390287 

Clean Code

읽으면서 요약하고, 덧붙이고 싶은 내용이 있으면 덧붙이면서 정리할 예정입니다.

1. 클린 코드

1.1 코드는 요구사항을 표현하는 언어이다. 
 
1.2 처음부터 좋은 코드를 짜는 것이 답이다. 
 
1.3 나쁜 코드는 생산성을 떨어트린다. 일정과 요구사항이 있더라도, 좋은 코드를 사수하는 것이 프로그래머의 책임이다.

 

클린 코드란?

1. 보기에 즐겁고 우아한 코드 (구조가 깔끔하고, 논리를 이해하기 쉬운 코드). 가독성이 중요. 반드시 필요한 내용만 담는다. 다른 사람이 이해하기 쉽고 고치기 쉬워야 한다.
2. 효율적인 코드. 속도, CPU 자원 등
3. 오류 처리가 철저한 코드. 세세한 사항까지 꼼꼼하게 처리하는 코드.
4. 한 가지에 집중하는 코드. (결국 논리가 명확하면 한 가지 목적에 집중하는 코드가 되는 듯)

1.5 새 코드를 짜면서 기존 코드를 읽는 시간이 훨씬 더 길다. 코드를 읽기 쉽게 만들자. 
 
1.6 코드를 한 번 잘 짰다고 끝이 아니다. 계속해서 개선해 나가자. 
 
1.8 좋은 코드들의 예시와 구조들을 보고 연습을 하자.

2. 의미 있는 이름

2.1 이름을 잘 짓자. 
 
2.2 의도가 분명하게 드러나도록 이름을 짓자. 존재 이유, 수행 기능, 사용 방법을 내포해야 한다. 
 
2.3 다른 의미로 오인될 수 있는 이름을 붙이지 말아야 한다. 또 특정 변수가 실제로 List가 아닌데 accountList라는 이름을 붙이지 말자. (accounts 같은 대안이 있음)
다른 변수 혹은 함수끼리 서로 너무 비슷한 이름을 붙이지 말자. 코드 자동 완성 할 때 귀찮다. (ㄹㅇ) 
 
2.4 같은 변수 명 여러 번 못 쓴다고 철자를 살짝 바꾸지 말자. class를 이미 썼다고 klass로 쓴다든지. (책에 나와있는 예제다. 실제로 class 말고 klass로 쓴 경우를 본 적이 있는데 으레 그렇게 하는 줄 알았다.)
Product라는 클래스 이름이 이미 있다고 ProductInfo 혹은 ProductData라는 클래스 이름을 붙이지 말자. 그 이름이 어떤 정보를 제공하지 않기 때문이다. 
 
2.5 발음하기 쉬운 이름을 사용하자. 프로그래밍은 사회적 활동이고, 이름을 소리내서 발음할 일도 많다. (그리고 결국 발음하기 쉬운 이름이 2.2에도 부합하는 것 같다.) 
 
2.6 찾기 기능으로 검색하기 쉬운 이름을 사용하자. (이것도 결국 변수, 함수의 존재 이유와 의미를 담은 좋은 이름을 지으면 검색하기도 쉬울 듯.) 또, 특정 상수 같은 경우에도 86400000 대신 MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000 처럼 미리 상수로 선언한 후 사용하면 좋다. 
 
2.7 헝가리식 표기법 (변수명에 타입 표기) 는 현대에는 대부분 불필요하다. 또 어차피 접두어, 접미어를 붙여봐야 코드를 읽을 때 주 관심 대상이 되는 것도 아니다. 
 
2.8 루프문 쓸 때 i, j, k 쓰는 케이스를 제외하고 나만 아는 변수명 짓지 말자. 
 
2.9 클래스, 객체 이름은 명사나 명사구가 좋다. 
 
2.10 메소드 이름은 동사나 동사구가 좋다. 
 
2.11 재미있는 이름 말고 명확한 이름을 쓰자. 
 
2.12 개념 하나 당 단어 하나를 사용하자. 일관성 있는 어휘를 쓰자. 같은 기능을 하는 메소드를 fetch, retrieve, get 등의 제각각인 단어로 표현하면 혼란스럽다. 
 
2.13 한 단어를 여러 가지 목적으로 쓰는 것도 좋지 않다. 다른 개념에 같은 단어를 쓰지 말자. 다른 맥락인데도 일관성을 고려한다고 같은 단어를 쓰지 말자. 숫자 a와 숫자 b를 더하는 메소드와 list에 원소 하나를 더하는 메소드를 둘 다 add로 쓰지 말고 각각 add, insert로 쓰든가 하자. 
 
2.14 프로그래머에게 익숙한 기술적인 개념은 이름을 지을 때 사용해도 괜찮다. 어차피 코드를 읽는 사람도 프로그래머다. 
 
2.15 적절한 기술적 용어가 없다면 문제 영역에서 이름을 가져온다. 문제 영역 개념과 관련 깊은 코드라면 거기에서 이름을 가져오자. 
 
2.16 스스로의 의미가 분명하지 않은 이름이 있다면 (예를 들어 주소에서의 state는 그냥 맥락 없이 떼놓고 보면 뭔지 잘 모르겠다) 클래스, 함수, 네임스페이스 등에 넣거나 최후의 수단으로 접두어를 붙여 맥락을 준다. 
 
2.17 그렇다고 불필요한 맥락을 넣지는 않도록 주의하자. 

3. 함수

3.1 함수는 작을 수록 좋다. 진짜 더 작을수록 좋다. 또, if / else / while 문 등에 들어가는 블록은 한 줄이어야 한다. 대부분 그 한 줄에 다른 함수를 호출한다. 바깥 함수도 짧아지고, 호출하는 함수 이름을 적절히 지어서 가독성 좋게 할 수 있다. 
+ 조건문도 너무 길어지먼 조건문 부분을 따로 캡슐화해서 빼버려도 좋다. 
 
3.2 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만 해야 한다.
함수를 의미를 유지하며 줄이기 불가능할 때까지(의미 있는 이름으로 다른 함수를 추출할 수 없을 때까지) 줄인다. 그렇게 하면 "한 가지 일"을 하는 함수가 된다. 
 
3.3 함수 내 모든 문장이 같은 추상화 수준에 있어야 한다. 특정 표현이 근본 개념인지 세부 사항인지 구분하기 어려운 코드는 읽기 어렵다. 위에서 아래로 프로그램을 읽으면 추상화 수준이 하나씩 낮아지도록 짜자. 쉽지 않지만 화이팅 
 
3.4 Switch문을 쓰면 함수를 작게 만들기 어렵지만 피할 수 없으니 저차원 클래스에 잘 숨기자. 다형적 객체를 생성하는 코드에서만 쓴다. 근데 이거 너무 자바 문법이라 잘 모르겠는데 내일 타스로 정리된 문서 다시 봐야지 
 
3.5 서술적인 함수 이름을 쓰자. 이름이 길어도 괜찮다. 
 
3.6 함수의 인수 개수는 적으면 적을수록 좋다. 출력 인수는 최대한 사용하지 말자. 그냥 사용하지 말자. 개념적으로 익숙하지 않고 함수를 읽기 불편하게 만든다. 플래그 인수는 추하다. 한 함수가 여러 일을 하게 만들기 때문이다. 플래그를 넘기지 말고 그냥 함수를 분리해라.
다항 함수도 안 쓰면 좋다. 독자적인 클래스 변수로 선언할 수 있는지 확인해보자. 변수를 묶어서 넘길 수 있는지? (Point 객체를 만들어서 x, y값을 Point 객체로 넘길 수 있음) TS에서는 구조 분해와 타입 엘리어스 쓰면 더 깔끔.
단항 함수는 함수와 인수가 동사/명사 쌍을 이루는 이름이어야 한다. writeField(name)처럼. 
 
3.7 사이드이펙트를 일으키지 마라. 
 
3.8 특정 행동을 수행한 후성공하면 true, 실패하면 false를 반환하는 함수는 가독성이 좋지 않다. 명령과 조회를 분리해서 혼란을 없애는 것이 좋다. 
 
3.9 오류 코드를 반환하는 방식보다 예외를 사용하는 방식이 코드가 깔끔하다. try / catch 구문은 원래 구조가 추하니 별도 함수로 뽑아내는 것이 낫다. 즉 정상적인 동작과 오류 처리 동작을 분리하자. 
 
3.10 중복되는 코드를 없애자. 
 
3.11 함수가 작다면 return, break, continue를 여러 차례 사용하는 것이 오히려 의도를 표현하기 쉬울 수 있다. 
 
3.12 코드를 쓸 때는 글을 쓰는 것처럼 퇴고하며 코드를 다듬고 정리해야 한다. 
 
+ 기본 객체를 만들 때 Object.assign을 쓰면 깔끔하다

 

(21.10.03)

3번 원칙에 의거해 예전에 썼던 코드들을 고쳐보려고 했지만 쉽지 않았다. 특히, '함수는 한 가지 일만 해야 한다'는 원칙이 가장 지키기 어려웠다. 코드를 짤 때는, 기승전결이 명확하고 군더더기 없는 좋은 레포트를 쓴다는 생각으로 짜야 하는 것 같다. 애초에 논리와 알고리즘이 명확하고, 그 코드가 어떤 동작을 해야 하는지를 확실히 이해하고 있어야 구조를 정리하기도 쉬운 것 같다.