" 사소한 곳에서 발휘하는 정직은 사소하지 않다" - 덴마크 속담
신은 세세함에 깃들어 있다. - 루트비히 미스 반 데어 로에
책의 서문에 적힌 글이다. 결국, 사소한 것이 중요하다는 말이다.
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_ 클래스와 메서드 수를 최소로 줄인다.
> 그러나, 시스템의 크기도 작게 해야한다. 무조건적으로 클래스 함수의 수를 줄이는 것은 옳지 않다.
'Etc > 독서' 카테고리의 다른 글
[니체] 지성에 대하여 (3) | 2015.08.13 |
---|---|
[니체] 사랑에 대하여 (2) | 2015.08.11 |
[니체] 인간에 대하여 (0) | 2015.08.10 |
[니체] 세상에 대하여 (0) | 2015.08.09 |
[니체] 친구에 대하여 (0) | 2015.08.09 |