[독서] 읽기 좋은 코드가 좋은 코드다

---

읽기 좋은 코드가 좋은 코드다

저자

더스틴 보즈웰, 트레버 파우커 지음

출판사

한빛미디어 | 2012-04-06 출간

카테고리

컴퓨터/IT

책소개

* 더 나은 코드를 작성하는 간단하고 실전적인 테크닉!이 책은 ...

---

블로거의 말:

 책을 훓어보며 읽어 내려간 뒤, 다 읽은지 한 일주일 정도 걸린 것 같다.
코더로써, 선배나 선임 개발자들에게 물어보는 내용은 대부분 로직이나 구조, 흐름 등의 내용일 것이다.
물론, 구조나 설계방식, 로직 혹은 순서도 등의 내용은 코드의 가장 뼈대가 되는 부분이다.
하지만, 하나의 코드를 여러명의 개발자들이 동시 다발적으로 접근하고, 수정하는 현업에서
기본 내공이 되는 것이 바로 이 책 안에 담겨있다고 생각한다.
누구도 알려주지 않았던 이야기나 변수명은 어떻게 지어야 할까? 등의 물음은
나로 하여금 좋은 코드란 무엇인지 다시 한번 깨닫게 해주었다.
학교에 다니며 코드를 공부하는 학생들이나, 나처럼 현업에서 일한지 얼마 되지 않은
초보 프로그래머 들에게 권하고 싶은 책이다.
이 책으로 하여금, 한 걸음 더 성장할 수 있을 것이라고 믿는다.



작성한 체크 리스트

Readable Code

1. 코드는 이해하기 쉬워야한다.

1. 코드가 다른 사람이 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.

< Part 1. 표면적 수준 개선 >

2. 이름에 정보 담기

1. 특정한 단어를 사용하라. ex> Get 대신 Fetch나 Download를 사용하는 것이 좋다.
2. tmp, retval 등의 보편적 이름을 피하라.
3. 대상을 자세히 묘사하는 구체적인 이름을 사용하라. ex> ServerCanStart() 보다 CanListenOnPort() 가 좋다.
4. 변수명에 중요한 세부 정보를 덧붙여라. ex> 밀리초 뒤에 _ms, 이스케이핑 변수에는 row_를 붙이는 습관.
5. 사용 범위가 넓으면 긴 이름을 사용하라. : 사용범위를 줄이는 연습도 해야함.
6. 대문자나 밑줄 등을 의미 있는 방식으로 활용하라. : 멤버변수, 로컬변수, 전역변수 등..

3. 오해할 수 없는 이름들

1. 의미가 오해되지 않는 이름이 최선의 이름이다. filter, length, limit 처럼 프로그래밍에 사용하기 의미가 모호한 단어가 많다.
2. 상한과 하한을 정할때 max_, min_을 붙이고, 경계를 포함하면 first/last, 경계의 시작만 포함하고 마지막은 배제하는 범위면 begin/end 가 보편적이다.
3. 불리언 값의 이름은 부정보다 긍정이 좋다. ex> disable_ssl 보다 use_ssl 이 좋다.
4. 특정 일반적인 단어를 조심해야한다. ex> get() 이나 size()는 사용자 입장에서 성능상 가벼운 함수라고 생각할 수 있다.(무거우면 안됨)

4. 미학

1. 여러 블록에 담긴 코드가 모두 비슷한 일을 수행하면, 실루엣이 동일해 보이게 만들어라.
2. 코드 곳곳을 '열'로 만들어서 줄을 맞추면 코드를 한 눈에 훑어보기 편하다.
3. 코드의 한 곳에서 A, B, C가 이 순서대로 언급되고 있으면, 다른 곳에서 B, C, A와 같은 식으로 언급하지 말아라. 의미있는 순서를 정하여 모든 곳에서 그 순서를 지켜라.
4. 빈 줄을 이용하여 커다란 블록을 논리적인 '문단'으로 나누어라.

5. 주석에 담아야 하는 대상

1. 주석에 담지 말것 : 코드 자체에서 재빨리 도출될 수 있는 사실
2. 주석에 담지 말것 : 나쁜 함수명과 같이 나쁘게 작성된 코드를 보정하려고 '애쓰는 주석'. 차라리 코드자체를 고쳐라.
3. 주석에 담을 것: 코드가 특정한 방식으로 작성된 이유를 설명해주는 내용
4. 주석에 담을 것: 코드에 담긴 결함. TODO: 혹은 XXX: 와 같은 표시를 사용하라.
5. 주석에 담을 것: 어떤 상수가 특정한 값을 갖게 된 "사연"

6. 명확하고 간결한 주석달기

1. 'it'이나 'this'같은 대명사는 주석에 담지 말것.
2. 함수의 동작을 실제로 할 수 있는 한도 내에서 최대한 명확하게 설명하라.
3. 신중하게 선택된 입/출력 예로 주석을 서술하라.
4. 코드가 가진 의도를 높은 수준에서 개괄적으로 서술하라.
5. 같은 줄에 있는 주석으로(ex> Function(/*arg= */)) 의미가 불분명한 함수의 인수를 설명하라.
6. 많은 의미를 함축하는 단어로 주석을 간단하게 만들라.

< Part 2. 루프와 논리를 단순화하기 >

7. 읽기 쉽게 흐름제어 만들기

1. 비교 구문을 작성할 때는, (변화하는 값 > 고정되는 값) 이 좋다.
2. if/else 의 블록 순서는 일반적으로 긍정적이고, 쉽고, 흥미로운 경우를 앞에 놓아라.
3. 삼항 연산자나 do/while 그리고 goto 같은 프로그래밍 구조는 종종 코드의 가독성을 떨어트린다. 대체방법이 있으면 사용하지 않는게 최선이다.
4. 중첩된 블록보다 '선형적인' 코드를 추구하라.
5. 함수 중간에 반환하면, 중첩을 피하고 코드를 더 깔끔하게 작성할 수 있다.

8. 거대한 표현을 잘게 쪼개기

1. 커다란 하위표현을 '설명 변수'로 대체하라.
2. 드모르간 법칙을 사용하라. ex> if(!(a && !b)) => if (!a || b)
3. 복잡한 논리적 조건들이 두개 이상의 값을 가지고 있지 않는게 이상적이다.
4. 개별적인 표현을 잘게 쪼개는 방법은, 커다란 코드의 블록을 쪼개는 데에도 적용 될 수있다. 두려워하지 마라.

9. 변수와 가독성

1. 방해되는 변수를 제거하라. (중도 변환을 이용하여 중간 결과값 변수 제거)
2. 각 변수의 범위를 최대한 작게 줄여라.
3. 값이 한 번만 할당되는 변수를 선호하라. (const or final)

< Part 3. 코드 재작성하기 >

10. 상관없는 하위문제 추출하기 : 일반적인 목적의 코드를 프로젝트의 특정 코드에서 분리하라.

1. 라이브러리와 헬퍼 함수들로 이루어진 집합을 구성하라.

11. 한번에 하나씩

1. 수행 작업을 모두 나열하라. 논리적 '문단'을 파악하고 "분리한다"
2. 애초에 프로그램이 수행하는 모든 작은 일들을 빠뜨리지 않고 정확하게 서술하는 것이 중요하다.

12. 생각을 코드로 만들기

1. 쉬운말로 설명하라. ex> 고무 오리 방법! 큰 소리로 자신에게 설명하라.

13. 코드 분량 줄이기 : 새로운 코드를 작성하는 일을 피하라.

1. 제품에 꼭 필요하지 않는 기능을 제거하고, 과도한 작업을 피한다.
2. 요구사항을 다시 생각해서, 가장 단순한 형태의 문제를 찾아본다.
3. 주기적으로 라이브러리 전체 API를 훑어봄으로써 표준 라이브러리에 친숙해진다.

< Part 4. 선택된 주제들 >

14. 테스트와 가독성

1. 각 테스트의 최상위수준은 최대한 간결해야 한다.
2. 테스트에 실패하면, 버그를 추적해서 수정하는 데 도움이 될 만한 에러메시지를 출력해야 한다.
3. 코드의 구석구석을 철저하게 실행하는 가장 간단한 입력을 사용하라.
4. 무엇이 테스트되는지 분명하게 드러나도록 테스트 함수에 충분한 설명이 포함된 이름을 부여하라. ex> Test1() 보다 Test_함수이름_상황 이 좋다.

15. '분/시간 카운터'를 설계하고 구현하기
-> 실제 상황에 따라 내용을 정리한 부분. 심심할때 읽어보면 괜찮음.(그러나 다시 읽어볼 것 같지 않다.)

마치며: 

 체크 리스트는 책을 읽어본 사람들이나 어떤 내용인지 이해가 갈 것이다. 모든 것을 하나하나 전부 적어서 소개할 만큼의 여유가 없어서 위 처럼 간단하게 작성했으니, 이해가는 만큼만 보시고 궁금하면 책을 읽어볼 것.