클린코드 ?

📕1장 깨끗한 코드

코드 해독시간이 길어짐에 따라 팀 생산성 저하 → 더 나쁜 코드 양산 → 결국 재설계 (실제 경험 있음) 르블랑의 법칙 : 나중은 결코 오지 않는다. 일정 / 요청사항 수정 등 핑계 x . 좋은코드 사수를 위해 정보 및 예상시간은 우리가 적극적으로 제공하자. 좋은코드를 짜는것이 결국 시간을 줄인다.

어떻게 좋은코드를 작성할까?

• 비야네 스트롭스트룹

  • 논리는 간단해야한다.
  • 의존성을 최대한 줄여야 유지보수가 쉬워진다.
  • 철저한 오류처리
  • 네이밍은 일관성있게 짜자
  • 성능 최적화 / 메모리 누수
  • 목적은 정확하게, 한가지에 집중하는 코드를 작성하자.

• 그래디 부치

  • 가독성 중시, 설계자의 의도를 숨기지 않고 직접적으로 짜라.

• 데이브 토마스

  • 다른사람도 고치기 쉬운 코드가 되어야 한다.
  • 테스트 케이스가 있는 코드
  • 큰 코드보다 작은 코드가 좋다.

• 론 제프리스

  • 중복과 높은 표현력
  • 한 기능만 수행하기
  • 초반부터 간단한 추상화 고려

보이스카우트 규칙

시간이 지나도 깨끗한 코드를 유지해라.

⇒ 깨끗한 코드를 짜기 위한 방법은 반복적으로 나오고 있다. 중복을 피하고, 남이 봐도 직관적인 코드를 짜야하며 최대한 작은 단위로 코드를 설계하여 의존성을 줄이도록 하자!

📗 2장 의미있는 이름

• 의도를 분명히 밝혀라

  • 주석이 필요할 정도의 네이밍이라면 의도를 제대로 표현하지 못한것이다.

• 그릇된 정보를 피해라.

  • 일관성이 떨어지는 표기법 === 그릇된 정보

• 의미있게 구분해라

  • 동일한 범위 내 다른 두개념 등 연속된 숫자로 명명하지 말자. info / data 는 의미가 불분명하며 중복이 되기 쉬우므로, 비슷한 개념이 있다면 더 명확한 이름으로 짓도록 하자.

  const internshipList = [...internData , internData]
  const handleInternship = useCallback((e) => {
   return internshipList.find((el)=> el.paymentPerMonth === e )
  },[internshipList]}
  
  vs
  
  const internshipPaymentList = [...internPaymentData , internPaymentData]
  const findInternWorkingSpecificDays = useCallback((PAY) => {
   return internshipList.find((intern)=> intern.workDaysPerWeek === WORK_DAYS_PER_WEEK )
  },[internshipList]}
  

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

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

  • 여러곳에서 사용하는 단순 숫자, 알파벳일 경우 검색하기 쉬운 변수/상수 이름을 짓는것이 바람직하다.

  <span>$10</span>
  
  vs
  
  const PAYMENT_PER_HOUR = 10
  <span>${PAYMENT_PER_HOUR}</span>

• 인코딩을 피해라

  • 헝가리식 표기법 : 컴퓨터 프로그래밍에서 변수 및 함수의 이름 인자 앞에 데이터 타입을 명시하는 코딩 규칙
  • 멤버 변수 접두어 : 클래스 및 함수는 접두어가 필요 없을 정도로 작게 짜야 한다.
  • 인터페이스 : ShapeFactoryImp vs IShapeFactoryImp

• 클래스 / 객체 이름 : 명사가 적합

• 메소드 이름 : 동사가 적합

• 한 개념에 한 단어를 사용해라

  • 똑같은 기능을 하는 메소드 ( fetch / retrieve / get )를 각기 다른단어로, 다른곳에서 쓰게 된다면 찾기 힘들 뿐 아니라 일관성이 달라 다른 타입이라고 생각 할 수 있다. ex) getAddress 를 썼다면 다른곳에서도 fetchUserProfile 이 아니라, getUserProfile 이런식으로 통일해서 만들어야 한다.

• 다른 개념에는 같은언어를 사용하지 않는다.

  • 일관성을 고려하기 위해 다른 목적에 있는 메소드에도 같은이름을 붙인다면 말장난에 불과하다. 비슷하지만 맥락이 다르다면 다른 단어를 쓰는게 맞다. ex) addNumber / addName ⇒ appendNumber / insertName

• 문제영역에서 가져온 이름을 사용하라

  • 적절한 프로그래머 용어가 없다면 문제영역에서 가져온다.

• 의미있는 맥락을 추가해라

  • 변수 / 메소드만 봤을때 어떠한 영역의 일부인지 알아채기 어려울 수 있으니 의미가 분명하도록 변수명을 짓도록 한다. ex )

  // 전체적인 맥락을 살펴볼때 주소에 관련된 변수라는 것이 연상되지만, 각각 하나로만 보면 한번에 유추하기 어렵다.
  name, street, houseNumber, city, state, zipcode;
  
  // 변수 및 메소드앞에 정확한 의미를 넣어주면 하나씩 보더라도 이해가 간다.
  addrName, addrStreet, addrHouseNumber, addrCity, addrState, addrZipcode;

• 불필요한 맥락을 없애라

  • 의미가 분명하다면 짧은이름이 좋다. 이름에는 불필요한 맥락을 추가하지 않는다.

📘 3장 함수

1. 작게 만들어라
   1. if / while 문 안에 들어가는 블록은 한줄이 적당하다.
2. 한가지만 해라
3. 함수 당 추상화 수준은 하나로
   1. 위에서 아래로 내려가기 규칙 : 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
4. 서술적인 이름을 사용하라.
   1. 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행하면 깨끗한 코드이다.
   2. 같은 일관성 내, 길고 서술적인 이름 > 짧고 어려운 이름
5. 함수 인수 : 이상적인 인수 개수는 0개. 3개이상은 가능한 피하는게 좋다. 1.
6. 부수효과를 일으키지 마라