[IT BOOK REVIEW] 1. CLEAN CODE (1)

개발자라면 한번쯤 접해봤을 책, Clean Code

좀 더 좋은 코드를 작성하고 싶어서 해당 책 내용을 정리하게 되었다. 

 

0. 책에 대한 정보

 

Clean Code(클린 코드)

『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 소개하고 있다. 소프트웨어 장인 정신의 가치를 심어 주며 프로그래밍 실력을 높여줄 것이다. 여러분이 노력만 한다면. 어떤 노력이 필요하냐고? 코드를 읽어야 한다. 아주 많은 코드를. 그리고 코드를 읽으면서 그 코드의 무엇이 옳은지, 그른지 생각도 해야 한다. 좀 더 중요하게는 전문가로서 자신이 지니는 가치와 장인으로서 자기 작품에 대한 헌신을 돌아보게 된다.

저자

로버트 C 마틴

출판

인사이트

출판일

2013.12.24

 

 

1. 깨끗한 코드 

코드 ? 요구사항을 상세히 표현하는 수단 ! 

깨끗한 코드 : 
- 간단하고 효율적인 코드 
- 한가지에 집중 ! 각 함수, 클래스, 모듈이 주변 상황에 현혹되거나 오염되지 않은 코드가 좋은 코드  
- 작성자가 아닌 새로운 사람이 처음 코드를 봤을 때, 읽기 쉽고 고치기 쉬운 코드 
-  주의 깊게 작성한 코드
- 새 코드를 짜면서 끊임 없이 기존 코드를 읽는데, 주변 코드를 읽지 않으면 새 코드를 짜지 못함. 
 : 결론, 주변 코드가 읽기 쉬우면 새 코드를 짜기가 쉽다는 점. 

[#1 느낀점]

다른 사람이 개발한 소스를 분석하고, 서비스를 추가하기 위해 개발이 이루어지는 경우도 많다. 
이 때 기존 소스가 너무 복잡하게 구현되어 있어, 소스의 가독성은 떨어지고 파악해야 하는 영향도가 높아 생각보다 더 많은 시간을 투자해 소스를 분석하고 개발했던 경험이 있다. 

🙋‍♀️ 코드는 내가 짠 코드를 다른사람이 이어서 짜는 경우가 언제나 발생할 수 있으니 남들이 이해하기 쉽게 !! 간략하게 짤 것 !!! 🙋‍♀️

2. 의미 있는 이름 

1. 의도를 명확히 밝혀라
. 변수나 함수 그리고 그리고 클래스 이름 내에 의도가 분명한 이름으로 할 것 

2. 그릇된 정보를 피해라 
. 일관성이 떨어지는 표기법은 그릇된 정보

3. 의미 있게 구분하라 

4.  발음하기 쉬운 이름을 사용하고 / 검색하기 쉬운 이름을 사용하라
. grep 으로 단순한 문자 하나 사용하는 이름, 상수 텍스트 코드는 찾기 어려움. 

5.  클래스 이름 ->  명사나 명사구가 적합 /  메서드 이름 -> 동사나 동사구가 적합
e.g., Customer, Account (클래스) 
postPayment, deletePage, save 등 (메서드) 

6. 기발한 이름은 피하라
. 재미난 이름보다는 명료한 이름으로 하기

7. 한 개념에는 한 단어를 사용하기 
. 똑같은 메서드를 클래스마다 fetch, retrieve, get ( 다 비슷한 의미인데) 으로 제각각 부르면 혼란스러움

8. 의미 있는 맥락을 추가하라
. e.g., firstName, lastName, street, houseNumber, city, state, zipcode 라는 변수 존재할 때, 
. 변수가 좀 더 큰 구조에 속한다는 사실을 알 수 있도록 addr 접두어를 추가하여,
addrFirstName, addrLastName, addrState 라 쓰면 맥락이 분명해지는 것을 볼 수 있다. 

 

[#2 느낀점]

변수명 정하는 것은 언제나 어렵다. 가끔 내가 왜 변수명을 왜이리 고민하고 있지..이런 생각이 들기도 하는데, 유지 보수를 위해서는 정말 중요한 일이라는 생각이 다시 한번 들었다. 
개발한 것에 대한 로그를 확인하는 경우가 많다. 이 때 grep 명령어를 자주 사용하는데, 변수나 메서드를 검색하기 쉽게고의미있게 정하면 개발/운영 시간 단축이 될 수 있음을 느꼈다. 

🙋‍♀️변수나 함수를 정할 때 의미가 명확하게 이해되고 구분되게 지을 것 🙋‍♀️

3. 함수 

1. 더 작게 만들어라 
- 중첩 구조가 생길만큼 함수가 더 커져서는 안됨.

2. 한가지만 해라
- 함수는 한가지만 하기 
- 함수당 추상화 수준은 한가지로 할 것
. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈릴 수 있다. 
- 코드의 내려가기 규칙 
. 위에서 아래로 코드 읽기 
. 위에서 아래로 프로그램을 읽으면, 함수 추상화 수준이 한번에 한단계씩 낮아진다.

3. 서술적인 이름을 사용하라
- 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 

4. 함수 인수가 적을수록 좋다. 
- 이상적인 인수의 개수 : 0 개
- 인수가 4개 이상인 경우는 특별한 이유가 필요하다.
- 인수가 늘어나면 테스트 관점에서도 어려움. 각 종 인수 조합으로 함수를 검증해야하기 때문.

5. 부수 효과를 일으키지 마라
 e.g., checkPassword 라는 함수가 암호를 확인하는 함수인데,
해당 소스 내에 부수 효과로 세션을 초기화하는 내용이 들어가는 부수효과를 만들지 말자. 

6. 오류코드보다 예외를 사용하라
- 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
e.g., try/catch 

7. 반복하지 마라. 
- 반복되는 알고리즘은 코드 길이가 늘어나고, 알고리즘이 변하면 중복된 부분 모두 수정이 이루어져야함. 

[#3  느낀점]

함수를 간소화하려해도, 하나의 기능 이상을 넣는 경우가 나타난다. 함수를 더 작게 만들어서 노력해보는 습관을 가져야겠다.  
🙋‍♀️함수는 작게, 부수 효과를 일으키지 않도록 !!! 반복되는 부분은 없애서 유지보수에 용이하도록 만들 것 🙋‍♀️

4. 주석

코드로 의도를 표현하지 못해, 주석을 사용.
: 주석이 필요한 상황에 처하면, 코드로 의도를 표현할 방법은 없는지 확인

1. 주석은 나쁜 코드를 보완하지 못함 : 코드로 의도를 표현하기 ! 
- 코드에 주석을 추가하는 경우 : 코드 품질이 좋지 않기 때문

2. 좋은 주석의 예시  
(1) 법적인 주석 // 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시할 때 
(2) 정보를 제공하는 주석 // 정규 표현식이 시각과 날짜를 뜻한다와 같은 정보를 제공할 때 
(3) 의도를 설명하는 주석  // 구현을 이해하는 것에 넘어서 결정에 깔린 의도까지 설명할 때 
(4) 의도를 명료하게 밝히는 주석 // 인수나 반환값 자체를 의미 좋게 표현하면 이해하기 쉬움. 
e.g., assertTrue(a.compareTo(a) == 0); // a== a 
(5) 결과를 경고하는 주석  // 다른 프로그래머들에게 결과를 경고할 목적으로 주석 사용
(6) Todo 주석 // 앞으로 해야할 일을 todo 주석으로 남기기
- 필요하지만 구현하지 않은 이유라던가..? 미래의 모습을 설명하면 좋을듯
(7) 중요성을 강조하는 주석
// 대수롭지 않게 생각할 수 있는 소스가 중요한 경우에 해당 부분에 주석을 넣으면 중요성이 강조됨

3. 나쁜 주석의 예시 
(1) 주절거리는 주석
(2) 같은 이야기를 중복하는 주석
(3) 오해할 여지가 있는 주석
(4) 의무적으로 다는 주석
(5) 있으나 마나 한 주석
(6) 공로를 돌리거나 저자를 표시하는 주석
(7) 주석으로 처리한 코드
--> 해당 케이스는 다른사람들이 지우기 주저하고, 이유가 있어서 남겨준다 생각해서 오히려 더 헷갈림

 

[#4  느낀점]

다른 사람들이 헷갈릴 것 같은 부분에 주석을 다는 습관이나, 나중에 다시 사용할 것 같아서 코드에 주석처리를 하곤 했었다. 해당 경우는 다른 개발자들이 개발을 할 때 더 헷갈리게 만들 수 있어 조심할 필요가 있음을 다시 한번 느낄 수 있었다. 중요한 부분에 주석을 다는 건 나쁘지 않으나, 필요 없는 소스는 반드시 삭제하고 헷갈릴만한 부분은 만들지 말 것 !! 
🙋‍♀️ 주석으로 모호함을 설명하려하지말고, 제대로 코드를 짜기! 🙋‍♀️