17장. 냄새와 휴리스틱 (2)

https://rachelslab.tistory.com/83

17장. 냄새와 휴리스틱 (1)

 

26. 정확하라

코드에서 무언가를 결정할 때는 항상 "확신"이 있어야한다. 

이번에 한 번 성공했다고, 이제 됐어! 라고 생각하는 것은 금지해야할 행동이다 ❌ (매일 이런 충동을 느낀다...)

결정을 내리는 타당한 근거아 있어야 하며, 예외 처리를 할 방안도 가지고 있어야 한다.

코드에서의 모호함 또는 부정확함은 언제나 제거 대상이라는 사실을 명심하자

 

28. 조건을 캡슐화하라.

조건 자체를 캡슐화하자.

as-is)

if(timer.hasExpired() && !timer.isRecurrent())

to-be)

if(shouldBeDeleted(timer))

 

29. 부정보단 긍정으로

if(!isConnected)

보다는

if(isConnected)

긍정문이 이해하기 더 쉽다

 

30. 함수는 한 가지 기능만 한다

이 예제는 한 가지 기능만 한다라는 것의 진수를 보여주기에 가져와봤다.

public void pay(){
  for (Employee e : employees) {
    if (e.isPayDay()) {
      Money pay = e.calculatePay();
      e.deliverPay(pay);
    }
  }
}

pay( ) 함수는 세 가지 일을 수행하고 있다.

 

(1) 직원 목록 루프 돌리기

(2) 각 직원의 월급일을 확인하고

(3) 월급일인 직원에게 월급을 지급한다.

 

 

 

 

 

 

이 함수는 각각 기능별로 나눠볼 수 있다.

public void pay() {
  for (Employee e : employee)
    payIfNecessary(e);
}

private void payIfNecessary(Employee e) {
  if(e.isPayday())
    calculateAndDeliverPay(e);
}

private void calculateAndDeliverPay(Employee e) {
  Money pay = e.calculatePay();
  e.deliverPay(pay);
}

 

32. 일관성을 유지하라

코드 구조에 일관성이 있다면, 다른 이들도 이 일관성을 유지하려고 할 것이다.

일관성이 없다면, 건드려도 된다고 생각한다. 🙅🏻‍♂️

 

33. 경계 조건을 캡슐화하라

경계조건은 한 곳에서 별도로 처리하는 곳이 좋다.

여기 저기에서 동일한 조건이 사용된다면, 변수로 캡슐화하자

 

35. 설정 정보는 최상위 단계에 둔다.

 

## 이름

1. 서술적인 이름 사용

소프트웨어의 가독성 90%는 이름이 정한다는 사실을 잊지 말자

무엇을 하는 함수인지 이름을 통해 알 수 있다면, 가독성이 좋은 것이다.

 

2. 적절한 추상화 수준에서 이름을 선택하라.

작업 대상인 클래스나 함수가 위치하는 추상화 수준을 반영하는 이름을 작명해야 한다. (쉽지는 않다..)

 

3. 가능하다면 표준 명명법을 사용하라

팀마다 특정 프로젝트에 적용할 표준을 나름대로 고안한다.

코드는 이 언어에 속하는 언어를 써야 한다. 즉, 프로젝트에 유효한 의미가 담긴 이름을 많이 사용할 수록 서로 코드를 이해하기 쉬워진다.

 

4. 명확한 이름

이름은 함수나 변수의 목적을 밝혀야 한다.

 

5. 긴 범위는 긴 이름을 사용하라

 

6. 인코딩을 피하라

 

7. 이름으로 부수효과를 설명한다.

 

## 테스트

1. 불충분한 테스트

"테스트 케이스 이 정도면 충분하지 않을까?" 어림도 없는 소리!

잠재적 위험을 가지고 있는 소스들도 모조리 테스트해서 "통과"를 내 눈으로 반드시 확인할 것

 

2. 커버리지 도구를 사용하라

커버리지 도구는 테스트가 빠뜨리는 공백을 알려준다.

(IDE를 활용하자)

 

3. 사소한 테스트를 건너뛰지 마라.

 

4. 무사한 테스트는 모호함을 뜻한다.

불분명한 요구사항이 프로그램 돌아가는 방식을 확신하기 어렵게 만들기도 한다.

이럴 때는 테스트 케이스를 주석처리하거나 @Ignore를 붙여서 표시한다.

 

5. 경계 조건을 테스트하라.

 

6. 버그 주변은 더욱 철저히 테스트하라.

버그는 서로 모이는 경향이 있다.(훠이훠이..🐞)

박멸을 위해 철저하게 테스트하자

 

7. 실패 패턴을 살펴라.

테스트 케이스를 최대한 꼼꼼히 짜면, 패턴을 발견할 수도 있을 것이다.

그러면, 대처가 빨라진다.

 

8. 테스트 커버리지 패턴을 살펴라

 

9. 테스트는 빨라야 한다.

느린 테스트는 실행하지 않게 한다. 일정이 한시라도 촉박한 상황에서는 건너뛰게 하는 요인이 된다.

.