[CLEAN CODE]

 " 사소한 곳에서 발휘하는 정직은 사소하지 않다" - 덴마크 속담

신은 세세함에 깃들어 있다. - 루트비히 미스 반 데어 로에

책의 서문에 적힌 글이다. 결국, 사소한 것이 중요하다는 말이다.

 Lean 의 원칙이 된 5s  를 살펴보자.

1_ 정리, 또는 조직

: 적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다.

2_ 정돈, 또는 단정함

: 물건마다 모두 제자리가 있다"라는 속담이 있다. 코드는 누구나 예상한느 위치에 있어야 한다.

3_ 청소,또는 정리

: 작업공간에서 배선이나 기름이나 부스러기 쓰레기는 치운다. 과거 이력이나 미래 바람을 기억한 주석 혹은 주석으로 처리한 코드는 제거하기 바란다.

4_ 청결, 또는 표준화

: 작업 공간을 청소하는 방식에 그룹이 동의한다. 그룹 내에서 일관적인 구현 스타일과 기법의 필요성을 책에서는 뭐라고 말할까? 표준은 어떻게 정할까?

5_ 생활화, 또는 규율

: 관례를 따르고, 자기 작품을 자주 돌아보고, 기꺼이 변경하는 규율을 뜻한다.

좋은 이름

개선 전

public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<int[]>();
    for (int[] x : theList)
        if (x[0] == 4)
            list1.add(x);
    return list1;
}

개선 후

public List<cell> getFlaggedCells() {
    List<cell> flaggedCells = new ArrayList<cell>();
    for (Cell cell : gameBoard)
        if (cell.isFlagged())
            flaggedCells.add(cell);
    return flaggedCells;
}

주석

주석을 달기전에 항상 이것만 기억하자.

"코드만으로 내가 말하고자 하는 바를 온전히 나타낼 수 없는지"

"Java Doc 과 같은 doc 문서를 만들기 위해 다는 불필요한 행위를 하는 것은 아닌지..."

단위테스트

- 세가지 법칙

첫째 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

둘째 : 컴퓨알은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

셋째 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

- 테스트당 되도록 assert 하나

클래스

클래스 이름은 해당 클래스 책임을 기술해야 한다.

단일책임원칙 ( SRP )

클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙

OCP

클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.

> 새 기능을 추가하는데는 어려움이 없고 , 그로인해 문제가 생기는 일이 없도록 기존 기능들은 독립되어야한다.

설계

단순한 설계규칙 4단계

1_ 모든 테스트를 실행한다.

> 테스트케이스를 만들고 계속 돌리면, 저절로 낮은 결합도 높은 응집력을 갖는 코드들이 나온다.

2_ 중복을 없앤다.

> 중복 == 추가 작업, 추가 위험, 불필요한 복잡도

3_ 프로그래머 의도를 표현한다.

> 좋은 이름을 선택하고, 함수와 클래스 크기를 가능한 줄여라. 또, 테스트 케이스를 꼼꼼히 작성하라. 이 모든게 의도를 표현하는데 도움이 된다.

4_ 클래스와 메서드 수를 최소로 줄인다.

> 그러나, 시스템의 크기도 작게 해야한다. 무조건적으로 클래스 함수의 수를 줄이는 것은 옳지 않다.