[1주차] 클린코드 1~3장 정리

1장. 깨끗한 코드

📌 나쁜 코드

이 장에서는 깨끗한 코드의 중요성을 강조한다.

나 또한 '나쁜 코드'로 고생한 적이 있다.

1. 마감에 쫓겨 우당탕탕 코드짜기
2. 나중에 고치려고 보니 무슨 의도로 짰는지 알아볼 수도 없을 때
3. 시간은 왕창 썼는데 우당탕탕 짜다가 생각의 흐름을 놓쳐서 결국 처음부터 다시 짜야할 때
4. 코드가 잔뜩 꼬였는데 어디서부터 틀린지도 모를때.. 등등

처음에 우당탕탕 코드를 빨리 짜놓고 나중에 유지보수에 고생하느니,
처음부터 생각하면서 깨끗한 코드를 짜놓아 유지보수를 할 때도 알아보기가 편하게 하는 것이 좋다!!

 

📌 깨끗한 코드

그럼 깨끗한 코드란 무엇일까? 이 책에서는 깨끗한 코드를 다음과 같이 정의한다.

1. 우아하고 효율적인 코드 == 보기에 즐거운 코드
2. 세세한 사항까지 (like 오류) 꼼꼼하게 신경쓰는 코드
3. 잘 쓴 문장처럼 읽히는 코드
4. 작성자가 아닌 사람도 읽기 쉽고 고치기 쉬운 코드
5. 시간을 들여 깔끔하고 단정하게 정리한 코드
6. 중복을 피하고 표현력이 좋은 코드

그 중 저자가 가장 강조하는 것은,

중복을 피하고, 한 기능만 수행하고, 제대로 표현하고, 작게 추상화한 코드이다

 

코드를 읽는 시간 : 코드를 짜는 시간 은 10대 1을 훌쩍 넘는다!!
주변 코드를 읽기가 어려우면 새 코드를 짜기도 어렵다.

물론 잘 짠 코드가 전부는 아니고, 시간이 지나도 코드를 깨끗하게 유지하는 것이 필요하다.

📌 느낀점

당장 졸프 중에 코드를 짜면서도
내가 여기서 어떤 변수를 썼었지, 어떤 함수를 썼었지 기억도 안 나고
스크롤을 올려봐도 바로 찾기가 상당히 어려웠었다.

이런 경험들 때문에 클린코드의 중요성을 다시 한번 깨닫게 된 것 같다.
꼭 클린코드를 완성해서 깨끗한 코드를 짜봐야지!!😊

2장. 의미 있는 이름

📌 의도가 분명한 이름

좋은 이름을 짓는데 걸리는 시간보다 좋은 이름으로 절약하는 시간이 훨씬!! 많다.

의도가 분명한 이름은 코드를 읽는 이로 하여금 이 함수, 변수, 클래스 등이 무슨 일을 하는지 이해할 수 있도록 해준다. 예를 들어 int d; 로 정의된 변수 d는 이 이름으로는 이 변수가 무슨 일을 하는지 전혀 알 수가 없다.

ex. 만약 지뢰찾기 게임을 만든다고 하면, 게임판 변수를 theList에서 gameBoard로 바꿔보자.

📌 그릇된 정보를 피하기

1. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하는 것은 안된다.
   ex) hp, aix, sco 등
2. 서로 흡사한 이름을 사용하지 않도록 주의하자.
   유사한 개념은 유사한 표기법을 사용하지만, 쓰임이 다른데 변수명을 비슷하게 짓는 것은 피하자.

📌 의미있게 구분하자

1. a1, a2... aN과 같은 이름은 아무런 정보를 제공하지 못하는 의미 없는 이름이다.
   난 여기서 굉장히 찔렸다.. 알고리즘 공부할 때 진짜 많이 썼던 변수들 하하
2. 불용어를 추가한 이름도 아무런 정보를 제공하지 못한다.
   ex ) NameString과 Name의 차이가 있는가? Name은 무조건 String 일텐데...!!
   읽는 사람이 차이를 알 수 있도록 이름을 짓자.

📌 발음하기 쉬운 이름을 사용하자

발음하기 어려운 이름은 토론하기도 어렵다.
이 책의 저자가 다니던 회사에서는 genymdhms라는 변수를 사용했다고 한다 ㅇㅁㅇ
gererate ate, year, month 어쩌고.. 의 합성어라는데 정말 최악인 단어에는 틀림없다..
발음하기 쉬운 이름을 쓰자!!

📌 검색하기 쉬운 이름을 사용하자

예를 들어 e라는 문자는 변수 이름으로 적합하지 못하다.
e는 영어에서 가장 많이 쓰이는 문자이기 때문에 거의 모든 문장에 등장하기 때문이다.

간단한 메서드에서만 사용되는 로컬변수라면 문자 하나로 지어도 되지만,
여러 코드에서 등장하는 변수라면 검색하기 쉽게 길게 짓는 것이 좋다.

📌 자신의 기억력을 자랑하지 말자

문자 하나만 사용하는 변수 이름은 쓰지말자. ( 반복문에 쓰는 i,j,k 제외 )
한 글자 변수는 독자가 이해하기 어렵다.

📌 느낀점

변수 이름 짓기가 중요한 건 항상 코드를 짜면서 뼈저리게 느껴왔던 것이지만
어떻게 지어야 기억하기 쉬운 이름을 지을 수 있을지 참 고민이 많았었다.
앞으로는 위 규칙에 따라 이름을 지어보는 습관을 가져보려고 한다!!!

3장. 함수

여기서는 읽기 쉽고 이해하기 쉬운 함수를 만드는 규칙을 소개한다.

📌 작게 만들자

함수는 짧으면 짧을수록 좋다.

짧은 함수를 위해서는 먼저, if/else/while문에 들어가는 블록은 한 줄이어야 한다.
이렇게 되면 바깥을 감싸는 함수가 작아질 뿐만 아니라 코드를 이해하기도 쉬워진다.

📌 한 가지만 하라 & 다른 일을 겸업해서 하지마라

함수는 한 가지의 기능만 잘해야 한다. 그렇다면 '한 가지'의 기능은 무엇일까?
먼저 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다.
한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다.
-> 추상화 수준이라..사실 이건 잘 이해를 못 했다.
다음으로 의미 있는 이름으로 다른 함수를 추출 할 수 있다면 그 함수는 여러 작업을 한다는 뜻이다.

Switch문

우리가 모두 알고 있듯이 switch문은 절대 한 가지 동작만을 하지 않는다.
위에선 한 가지 동작만 하라고 했는데...! 그래서 여기서는 switch문에 대해서 방향을 제시한다.
바로 한번만 참아준다는 것 ㅋㅋㅋㅋㅋㅋ switch문을 쓸 거면 한 번 정도는 용서해준다 이건가..
다형적 객체를 생성하는 코드 안에서 한 번만 쓰고 그 이외에는 쓰지 말자!!
( 물론 이 책의 저자도 불가피한 상황에서 switch문을 다른 방법으로 쓴 적 있다고 한다.. 최대한 피해보자 )

명령과 조회를 분리하자

함수는 뭔가를 수행하거나, 답하거나 하나만! 해야한다.

오류 코드보다는 예외를 사용하자

명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다!
오류 코드를 반환하면 호출자는 오류 코드를 곧바로 처리해야하지만,
오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되어 코드가 깔끔해진다.
== try/catch 블록을 별도 함수로 뽑아내는 것이 좋다.

오류처리도 한 가지의 작업이기 때문에, 오류를 처리하는 함수를 하나 뽑는 것이 좋다.

📌 위에서 아래로 읽히게 하라

코드는 위에서 아래로 읽혀야 좋다. 이는 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다는 뜻이다.
위에서 아래로 TO문단을 읽어내려가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기가 쉬워진다.

📌 서술적인 이름을 사용하라

2장. 의미 있는 이름에서 했던 말을 다시 복습하는 느낌이다.
함수가 하는 일을 좀 더 잘 표현할 수 있는 이름을 쓸 것! 길고 서술적인 이름을 쓰더라도 겁 먹지 말자.
긴 주석보다 긴 이름이 낫다. 다만 이름을 붙일 때는 일관성이 있어야 한다.
includeSetupAndTearDownPages, includeSetupPages, includeSetupPage 등등..
일관성 있는 이름이 어떤 건지 감이 빡 온다!

📌 함수 인수

함수에서 이상적인 인수 개수는 0개 이다. 3개 이상은 피하자. 사실 3개 이상을 쓸 일도 딱히 없다.
인수가 많아질수록 함수를 이해하기도, 테스트하기도 어려워진다.
또한 출력 인수가 입력 인수보다 이해하기가 어려운데, 출력 인수는 독자가 코드를 재차 확인하게 만든다.
( 사실 나도 개발을 할 때 출력 인수를 쓴 적은 없는 것 같다. 쓸 일이 있나..? )

많이 쓰는 단항 형식

함수에 인수 1개를 넘기는 가장 흔한 경우는 인수에 질문을 던지는 경우와 인수를 뭔가로 변환해 결과를 반환하는 경우다. 이런 이벤트 함수는 입력 인수를 받고 출력 인수를 반환하지는 않는다.
이런 경우를 제외하고는 입력 인수를 쓰지는 말자!!

플래그 인수

함수로 부울 값을 넘기는 관계는.. 쓰지 말자. 이 함수는 함수가 여러 가지를 처리한다고 알리는 셈이다.
위에서 말했던 것처럼 함수는 한 가지 일만!!! 해야한다.

인수 객체

인수가 2~3개 필요하다면 객체를 생성해 인수를 줄일 수도 있다.
Circle makeCircle(double x, double y, double radius);
-> Circle makeCircle(Point center, double radius) 와 같이!!

📌 반복하지 마라

중복을 없애라! 소스코드에서 중복을 제거하기 위해 지속적으로 노력하자.

📌 구조적 프로그래밍

모든 함수와 함수 내 모든 블록에 입구와 출구는 하나만 존재해야 한다.
== 함수는 리턴문이 하나여야 한다.
== 루프 안에서 break, continue, goto를 사용해서는 안된다.

코테용 프로그래밍에서는 수없이 짜는 게 루프 안에서 조건 따져서 break, continue를 하는 것인데.. 정작 클린코드에서는 하지말라니!! 증말 인지부조화가 온다. 하지만 이겨내자..!

⭐️ 결론

함수를 어떻게 짜는가?

논문이나 기사를 작성할 때 먼저 기록한 후 나중에 다듬는 것처럼
처음에 길고 복잡한 함수를 짜고 코드를 다듬고 함수를 만들고 이름을 바꾸고 중복을 제거하고 메서드를 줄이고 순서를 바꾸고.. 수없이 클린코드를 위해 다듬다 보면 클린한 함수를 짤 수 있을 것이다!

노력이 답이다⭐️