Positiveko TIL

# 클린코드 | Clean Code

# 1장 깨끗한 코드

  • 4p. 나쁜 코드는 개발 속도를 크게 떨어뜨린다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 설계 의도에 맞는 변경과 설계 의도에 반하는 변경을 구분하지 못하고 나쁜 코드를 양산하면 생산성은 거의 0이 된다.
  • 7p. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
  • 9p. 비야네 스트롭스트룹 C++ 창시자 曰.. 나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능으 ㄹ최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 깨끗한 코드는 한 가지를 제대로 한다.
  • 10p. 오류 처리.. 메모리 누수.. 경쟁 상태.. 일관성 없는 명명법
  • 14p. 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. 이상이다.

# 2장 의미 있는 이름

  • 22p. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
    const elapsedTimeIndays;
const daysSinceCreation;
const daysSinceModification;
const fileAgeInDays;
  • 25p. 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다.
  • 28p. 검색하기 쉬운 이름을 사용하라
    // 의미가 불분명한 매직 넘버는 상수로 선언하기
const MILLISECONDS_IN_A_DAY = 86400000;
setTimeout(blastOff, MILLISECONDS_IN_A_DAY);
  • 33p. 한 개념에 한 단어만 사용하기. (eg. controller와 manager 혼용하지 않기)
  • 35p. 의미 있는 맥락 추가하기. (eg. addrFirstName, addrState, addrStreet, addrCity)

# 3장 함수

  • 42p. 함수를 작게 만들어라. (10줄도 길다.. 5줄로 만들어라 ^^..) 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.
  • 44p. 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
  • 49p. 이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.
  • 50p. 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)는 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다.
  • 54p. 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다. 함수 이름에 키워드 추가하면 인수 순서 기억할 필요 없음
    write(name)
assertExpectedEqualsActual(expected, actual)

# 4장 주석

  • 68p. 나쁜 코드에 주석을 달지 마라. 새로 짜라. 주석은 오래될수록 코드에서 멀어진다. 오래될수록 완전히 그릇될 가능성도 커진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까.

  • 69p. 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 진실은 한 곳에만 존재한다. 바로 코드다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다.

    # 좋은 주석

    • 법적인 주석: 소유권, 저작권 정보
    • 정보 제공: 리턴값에 대한 정보를 담을 수 있지만 이마저도 코드로 표현해주는 것이 좋다.
    • 의도 설명
    • 의미 밝히기
    • 결과 경고
    • TODO
    • 중요성 강조
    • 공개 API에서 Javadocs

    # 나쁜 주석

    • 같은 이야기를 중복적으로 하거나, 오해의 여지가 있고, 의무적으로 다는 주석이라면 쓸모없다.

# 9장 단위 테스트

  • 167p. 깨끗한 테스트는 다음 다섯 가지 규칙을 따른다. Fast: 테스트는 빨라야 한다. Independent: 각 테스트는 서로 의존하면 안된다. Repeatable: 테스트는 어떤 환경에서도 반복 가능해야 한다. Self-Validating: 테스트는 bool 값으로 결과를 내야 한다. Timely: 테스트는 적시에 작성해야 한다.
  • 168p. 테스트 코드는 어쩌면 실제 코드보다 더 중요할지도 모르겠다. 테스트 코드는 실제 코드의 유연성, 유지 보수성, 재사용성을 보전하고 강화한다.

# 11장 시스템

  • 194p. "복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다." - Ray Ozzie, Microsoft CTO
  • 196p. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. 또한 주요 의존성을 해소하기 위한 방식이 필요하다.
  • 197p. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 몰라야 한다.
  • 213p. 시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다. 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다. (...) 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

# 13장 동시성

  • 226p. 동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇what과 언제when를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다. 흔히 단일 스레드 프로그램을 디버깅하는 프로그래머는 정지점breakpoint을 정한 후 어느 지점에 걸렸는지 살펴보면서 시스템 상태를 파악한다.
Tags: 클린코드
Last Updated: a year ago

← 코드의 성능 향상 →