cleancode

1장 깨끗한 코드

{

{%/notice%}}

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

  ( 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업 = 프로그래밍 )

• 작성자가 아닌 사람도 읽고 고치기 쉽고 단순하고 직접적이다.

• 중복을 피하고 한 기능만 수행하게 작제 추상화하기

• 프로그래밍은 코드를 읽는 시간 대 짜는 시간 비율이 9:1

• 잘 짠 코드도 시간이 지나면 레거시가 되니 조금씩 코드를 정리/개선하자

2장 의미있는 이름

• 클래스/메서드 이름

  • 클래스 : 명사, 명사구가 적합

  • 메서드 : 동사, 동사구가 적합

• 의도를 명확하게 밝히자 ( 코드의 맥락이 코드자체에 명시적으로 드러내자)

• 잘못된 정보를 피하자

  • 약어를 함부로 사용하지말자

  • 0/O, l/1등과 같이 서로 헷갈리게 하는 변수명을 짓지말자

• 의미있게 구분하자

  • 단순히 컴파일러나 인터프리터를 통과할 목적의 네이밍하지 말자

  • a1,a2...와 같이 연속된 숫자나, 불용어를 지양하자

  • ex. getAccount(),getAccounts(), getAccountInfo()와 같은 메서드가 있다면 새로운 프로젝트 참가자는 메서드를 구분하기 힘들다.

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

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

  • 간단한 메서드에서 로컬 변수는 한 문자를 사용하더라도 상수나 대부분의 변수는 긴 이름이름이 검색하기에도 더 편하다.

    요즘 좋은 IDE들은 몇자 타이핑 안해도 자동 추천해주니 검색성능 면에서는 긴이름이 더 좋다.

• 인코딩을 피하자

  • 마찬가지로 요즘 IDE들은 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 똑똑하기 때문에 헝가리안 표기법을 지양 하자

• 한 개념에 한 단어를 사용하자

  • fetch/get/retrieve 나 controller/manager/driver와 같이 비슷한 의미의 단어를 혼용해서 사용하는 것을 지양하자

  • add/insert/append 와 같이 추가하는 메서드라고 하더라고 맥락이 다르면 다른 단어를 사용하자. ( 의도 를 명확하게 밝히는 것이 중요! )

3장 함수

가능한 한 작고 한가지 기능만 수행하도록 작성하자.

함수 매개변수로 boolean형 플래그를 넘기는 순간 함수에서 여러가지 일을 하도록 하는 것이다.

4장 주석

최대한 코드로 의도를 표현하자.

법적인 내용이나, 정보 제공, 경고, TODO등에 주석을 사용할 수 있다.

코드 컨벤션

최대한 피해야할 형식들이 존재하고 개개인마다 다르지만, 팀의 컨벤션을 최우선시 하자

객체와 자료구조

모든 부분이 객체지향으로 짤 수 없고 이것이 장점만 있는 것은 아니다. 자료구조,절차지향이 더 장점인 부분도 존재하기 때문에 적절히 사용하자.

오류 처리

조건문을 이용한 오류 코드보다 예외를 던지는 것을 이용하자.

null을 전달, 반환하지 말자.

읽기에 좋은 코드뿐이 아닌 안정성도 높은 튼튼하고 깨끗한 코드를 작성하자.

경계

짐 뉴커크는 간단한 테스트 케이스를 작성해 외부 코드를 익히는 방식을 학습 테스트라고 부른다.

이에 드는 비용은 공짜는 아니지만 실제 방식과 동일하게 작성한 이러한 케이스는 패키지의 버전 이전도 더 쉽게 도와준다.

테스트

이 책은 테스트, TDD에 대해 꽤나 힘을 실어주고 있다.

실제 코드보다 중요하며 좋은 테스트 코드가 좋은 실제 코드를 만들어 낸다고 하고 있다.