1. 변수, 함수, 클래스 명을 잘 짓자
1.1) 이름의 의도를 분명히 하기
1.2) 잘못된 정보를 적지않기
1.3) 이름에 대한 구분을 잘하기(a1, a2와 같은 변수사용x)
1.4) 발음하기 쉬운 이름 사용하기
1.5) 검색하기 쉬운 이름 사용하기
핵심 : 한 개념에 한 단어를 선택하자
2. 함수를 잘 사용하자
2.1) 함수는 작게 만들자(하나의 함수는 하나의 작업 수행)
2.2) 함수를 위에서 아래로 읽어내려갈때 이야기처럼 자연스러워야한다.
2.3) 함수의 인수를 최대한 줄이거나 없애자.
2.4) 함수의 인수에 출력 객체를 넣지 말자.
2.5) 코드의 중복을 없애자
3. 객체와 자료구조
3.1) 객체(추상화하여 사용하는 클래스)는 함수를 오픈하고 내부구조는 숨긴다.
3.2) 자료구조(구체적인 데이터 ex- 데이터 모델파일)는 함수제공 안하면서 그대로 오픈한다.
3.3) 객체를 계속해서 불편하게 드러낼바에 새로 하나 함수를 만든다.
3.4) bean객체의 구조는 잘못되었다. DTO는 자료구조로써 역할을 하는데 불필요한 get, set을 만든다. (공감)
3.5) 객체는 한 함수에서 새로운 객체타입을 적용하기에 편하지만 기존 동작에 새 동작을 추가하는 것은 어렵다.
반면에 자료구조는 기존 동작(기존 클래스 함수 a)에 새 동작(기존 클래스 함수 b)을 추가하는것은 쉬우나 새 자료구조 를 추가하는 것(기존 클래스 함수 a의 수정)은 어렵다.
4. 예외처리
4.1) 예외가 있을 코드에 try-catch-finally 부터 작성, TDD 작업을 할때는 예외가 먼저 일어나도록 작성한다. 그래야 try 문 안에 있는 내용이 명확해진다.
4.2) 미확인 예제(Runtime Exception)를 사용하자
4.3) 외부 라이브러리를 사용하는 경우 Wrapper Class를 사용하는 것이 의존성을 줄인다.
4.4) null 사용을 피하라(null 반환, null 넘김 등등) -> 예외 또는 특수 객체(ex NO_VALUE)로 처리
5. Boundary
5.1 외부 라이브러리를 사용할때 Wrapper로 감싸거나 Adapter 패턴을 사용하자
5.2 외부 라이브러리를 사용하기전 간단한 테스트코드를 작성해 보자
6. TDD
6.1 TDD의 법칙 세가지를 지키기
6.1.1 실패하는 단위테스트를 작성할때까지 실제 코드를 작성하지 않기
6.1.2 컴파일은 성공하면서 런타임에 실패하는 단위 테스트 작성
6.1.3 현재 실패하는 테스트를 통과할정도의 실제코드 작성
6.2 테스트 코드는 실제 코드 못지않게 중요하다.(테스트 코드로 인해 프로젝트가 유연하고 코드 재사용성이 올라감.)
6.3 FIRST 규칙을 따르자(테스트는 빠르게, 독립적으로, 반복가능하게, 자가검증하면서, 적시에)
댓글