찐빵이의 개발일기

주석 부적절한 정보 쓸모없는 주석 중복된 주석 성의 없는 주석 주석 처리된 코드 함수 너무 많은 인수 출력 인수 플래그 인수 (boolean) 아무도 호출하지 않은 죽은 함수 - 삭제해야 한다. 이름 서술적이지 않은 이름 표준 명명법 사용 안 하는 경우 명확하지 않은 경우 테스트 불충분한 테스트 모호한 테스트 느린 테스트

클래스 내 작성 순서 static public 상수 static private 변수 private instance 변수 public 함수 공개 변수가 필요한 경우는 거의 없다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 클래스 크기 줄이는 방법 단일 책임원칙(Single Responsibility Principle) 클래스가 책임지어야 하는건 단 하나뿐이다. 소수의 큰 클래스보다 많은 작은 단위의 클래스로 이뤄진 시스템이 더 바람직하다. 클래스 이름에 해당 클래스의 역할을 명확하게 기술한다. 높은 응집도(Cohesion) 응집도가 높다: 클래스에 속한 메서드와 변수가 서로 의존한다. 논리적인 단위로 묶인다. 낮은 결합도 각 시스템 요소가 다른 요소로..

깨끗한 테스트 규칙은 다음 다섯 가지 규칙을 따른다. 빠르게(Fast) 테스트는 빨라야 한다. 테스트가 느리면 자주 돌리기 힘들기 때문이다. 테스트를 마음껏 하지 못하면 문제를 찾는데 느려지고 코드 품질이 망가진다. 독립적으로(Independent) 테스트는 서로 의존하면 안된다. 하나의 테스트가 실패하면 나머지도 잇달아 실패하기 때문이다. 이럴 경우 실패의 원인을 파악하기 어려워진다. 반복 가능하게(Repeatable) 테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA 환경, 네트워크가 연결되지 않은 노트북 등... 환경을 타지 않아야 한다. 자가 검증하는(Self Validating) 테스트는 bool값으로 결과를 내야 한다. 스스로 성공과 실패를 자동적으로 판단해야 테스트 결과 확인이..

함수를 만들 때 고민해야 하는 것 의도를 분명히 표현하는가? 어떤 속성을 부여해야 읽는 사람이 직관적으로 파악할 수 있을까? 1. 최대한 작게 만들자 함수가 작을수록 이해하기 쉽다. 그럼 얼마나 작아야 할까? 조건문이 들어가는 블록은 한 줄이어야 한다. 함수에서 중첩 구조를 지양하자. 들여 쓰기 수준은 1단이나 2단을 넘지 않는 게 좋다. 또한 함수를 구성할 때 추상화 수준이 높은 단계부터 낮은 단계로 내려가면서 배치해야 한다. 2. 한 가지만 하자 함수를 만드는 이유는 큰 개념을 추상화 수준에서 여러 단계로 작게 나눠서 수행하려는 것인데, 하나의 함수 안에서 여러 단계를 처리하면 복잡해진다. 함수가 한 가지 작업만 하는지 판단하는 방법 함수 내 추상화 수준이 동일한 단계만 수행한다면 그 함수는 한 가지..

1. 의도가 분명하다. 개발자는 변수, 함수, 클래스의 존재 이유, 수행 기능, 사용 방법을 모두 답할 수 있어야 한다. 클래스 이름: 명사나 명사구가 적합하다. 동사는 사용하지 않는다. 메서드: 동사나 동사구가 적합하다. 2. 그릇된 정보가 없다. 일관성이 떨어지는 표기법을 이름으로 사용하면 안 된다. 진짜 끔찍한 예시 int a = l; if(O == 1) { a = O1; } else { l = 01; } 1과 l, 0과 O의 생김새가 비슷해서 헷갈리게 된다. 이런 코드는 생산성을 저하시킨다. 3. 의미 있게 구분된다. 컴파일러를 통과하려는 생각만 가지고 코드를 구현하는 게 아니라, 읽기 쉬운 코드를 구현하자. a, the, Info, Data와 같은 불용어를 추가한 이름은 아무런 정보도 제공하지 ..