Skip to content

Instantly share code, notes, and snippets.

@uptown

uptown/clean_code.md

Forked from wojteklu/clean_code.md
Last active August 10, 2022 08:59
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save uptown/9042c9619a355cd1ab9231d15b875c89 to your computer and use it in GitHub Desktop.
Save uptown/9042c9619a355cd1ab9231d15b875c89 to your computer and use it in GitHub Desktop.
Download ZIP
Summary of 'Clean code' by Robert C. Martin
Raw
clean_code.md

클린코드란?

  • 팀의 모든 사람에게 쉽게 이해되는 코드가 있다면, 그거시 바로 클린코드 입니다.

클린코드의 아름다운 모습

  • 클린 코드는 Author 외에도 읽고 개선할 수 있어야합니다. 그것을 바탕으로 모든게 쉬워집니다.
    • 읽기 쉽고
    • 수정하기 쉽고
    • 확장도 쉽고
    • 유지보수도 쉽고

일반적인 규칙들

  1. 팀의 규칙이 있고, 그 규칙을 지키세요!
  2. 바보같이 단순하게 유지하세요. 단순한 것이 항상 더 좋은겁니다. 복잡성을 줄이세요!
  3. 보이스카우트 규칙 -> Non-clean code를 발견했다면 수정하세요. (Leave the campground cleaner than you found it.)
  4. 항상 근본 문제를 찾으세요. 원인을 찾아내세요.

디자인 규칙들

  1. 세팅값들 같은 경우는 코드의 최상단에서 받게해야합니다 (Keep Configurable Data At High Levels)
  2. 상속 / interface 를 if/else 나 switch/case 보다 선호해야합니당
  3. 멀티쓰레드 코드는 분리하세요!
  4. 과도한 Configuration 가능성을 만들지 마세요. (쓰지도 않는 옵션 만들어놓는 이야기인듯)
  5. 의존성주입(DI)를 사용하세요!
  6. 디미터법칙을 따르세요. 단일책임원칙에 가까움

이해하기 쉬운 코드를 위한 팁

  1. 일관적이게 작성하세요. 모두 유사하다면, 다른 이가 알아먹기 쉬울거에요
  2. 번수명도 이해를 돕는 도구입니다. 자세히 ... !
  3. Condition을 한번더 변수로 지정하던지, 다른 매소드로 빼던지 해서 캡슐화 합니다. 그런 컨디션은 찾기힘드니까 최대한 한곳에서 처리하세요 (변수면 매소드 상단에, 메소드면, 특정이름 그룹으로 하던지 한 클래스에 모으던지 등)
  4. 원시타입보다는 전용 클래스를 만드는게 더 좋아요 Value objects like a pro.
  5. 논리적 종속성을 피하세요. 예를들어, 밥먹는 시간 알리미 라는 클래스가 있다면, 밥먹는시간 이 알리미 클래스에 들어있다면, 꽤나 골치아픕니다. 회사시간규칙 이라던지 밥관련변수 라던지 회사규약 같은 것들로 나눈다음 알리미 클래스에서 참조하면 어떨가요?
  6. (일부로 실수를 유도하는게 아니라면) 부정적인 조건문은 피하세요

클린한 작명법

  1. 명확하고, 해당 변수를 잘 설명할수 있는 이름이 좋습니당
  2. 변수들이 구별하기 쉬워야해요!
  3. 소통을 위해 발음하기 쉬워야합니다!
  4. IDE등에서 검색하기 쉬워야합니다!
  5. 원주율 이나 단위변환상수 등 매직넘버가 필요하다면 상수로 바꾸세요! 3.14 이렇게 써놓지 말기!
  6. Avoid encodings. Don't append prefixes or type information. 이거는 모-던 개발자들에게는 옛날이야기...

크-린 함수는 이래야한다!

  1. 작아야함. 더, 더, 더!
  2. 한가지만 해야함
  3. 이름은 최대한 이해하기 쉽게, 설명이 충분히 되게 (이름만보고도 어떻게 구현했는지 알아야 베스트일듯)
  4. 인자가 적을수록 좋데요
  5. 사이드이팩트가 없어야합니다. (예를들어서 find 함수에서 이메일이 전송된다던지 ...?)
  6. flag 성 인자를 사용하지 마세요. 그럴꺼면, 여러 메소드로 빼서 상위에서 if else 로 하던지 다형성으로 해결하던지 ...

주석다는법

  1. 코드로 설명할수 있다면 베스트입니다
  2. 중복된 내용적지 마세요
  3. 쓸데없는 이야기 쓰지마세요 (이거 쫌 어려움 이런거)
  4. 주석은 코드 위에 다세요. 함수 끝나거나 블록 끝나는데 달지마세요 (Don't use closing brace comments.)
  5. 코드를 주석처리하지마세요. 그냥 지우세요 git이 있잖아요!
  6. 의도한 바가 특별히 있다면, 주석 사용할 수 있어요
  7. 코드에 대한 설명이 필요하다면, 주석 사용할 수 있어요
  8. 해당 코드가 발생할수 있는 결과 / 에러에 대해서 사용할 수 있어요

코드 구조에 대한 것

  1. 개념적으로 계층화 합니다 ex) ui / biz logic / external call(api) 등
  2. 관련된 내용들은 한눈에 볼수 있게 최대한 가깝게 붙여놓읍시다.
  3. 예륻들어 변수를 맨위에서 선언하고... 그거를 맨 아래서 쓴다면 너무나 햇갈리겠죠?
  4. 클린코드를 위한 종속함수는 private 으로 유지하세요
  5. 비슷한 함수들은 비슷한곳에 모여있어야합니당
  6. 기능을 아랫쪽 방향으로 합니다. 이게 뭔말이냐면, 종속함수들 예를들어 밥먹다: 밥주문, 결제, 먹기 라면 class {public 밥먹다, private 밥주문, private 결제, private 먹기} 같은 순서로 코드가 짜여있다면, 이해하기 더 쉬운 코드일 것입니다. 왜냐면 논리적 흐름을 따라가는대로 코드가 있으니 ...
  7. 최대한 작은 라인을 갖게하세요. (길면 보기 힘들어서 그런가 ... ?!)
  8. 수평정렬을 사용하지마세요. (저희는 해당사항 없음)
  9. 스페이스 를 사용하여 서로의 연관도를 밀접한지 아닌지 설정합니다. (저희는 대부분 린트로 해결 ...)
  10. 들여쓰기 규칙을 지키세요 (저희는 대부분 린트로 해결 ...)

객체, 데이터 구조

  1. 내부 구조를 숨기세요
  2. list, map 등 데이터 구조를 적극 활용하세요
  3. data면 데이터지, 데이터도 되고 비즈니스로직도 하는 엄청난 친구를 만들지마세요.
  4. 역시나 작아야합니다
  5. 역시나 단일책임원칙을 지킵니다
  6. 인스턴스 variable의 수는 적으면 적을수록 좋습니다.
  7. Base Class는 상속되는 친구들에 대해서 당연히 아무것도 몰라야합니다.
  8. 다양한 함수를 선언하는게, 인자받고 여러가지 기능하는 것보다 좋습니다 ... !
  9. static method 보다는 그냥 method 가 좋습니다. (왠만하면 객체에서 isDone 이런거 쓰라는듯)

테스트는?

  1. 하나의 테스트에서는 한가지만 검증합니다.
  2. 읽기 쉬워야합니다
  3. 빨라야합니다
  4. 독립적이어야합니다.
  5. 여러번 실행해도 동일한 결과가 나와야합니다.

이런 경우 문제가 있는 상태입니당

  1. 쉬운 로직 변경을 위해 여러군데를 연속적으로 변경해야하는 경우는 안되요.
  2. 한 군데 변경하면, 여러군데에서 에러날 가능성이 있거나 에러가 나면 안되요.
  3. 다른 곳에서 복붙한다음, 조금 수정한다는 가정아래에서 사용하기 힘들 정도의 코드는 안되요.
  4. 불필요하게 복잡하면 안되요.
  5. 불필요하게 중복되면 안되요. (사용자 체크로직 등이 함수로 안빠져있고 여기저기 퍼져있는경우등?)
  6. 코드 이해하기 어려우면 안되요.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment