6장. 코딩하는 동안 해야 할 일들
소제목
- 우연에 맡기는 프로그래밍
- 알고리즘의 속도
- 리팩터링
- 테스트하기 쉬운 코드
- 사악한 마법사
리팩터링 하는 방법과 코딩을 어떻게 하는지에 대해 설명하는 장이고, 정말 많은 도움이 되는 설명들이었다.
31. 우연에 맡기는 프로그래밍
왜 프로그램이 이렇게 동작하는지 설명할 수 없다면, 이 프로그램은 내 프로그램이 아니다. 지금은 이렇게 작동하지만 다른 환경에서는 다르게 동작할 수도 있다. 언제나 내 제어 안에 있는 코드를 작성하려고 노력해야 한다. 우리는 모두 우연에 맡기는 코딩을 하지 않는다고 생각할 수도 있으나, 항상 그렇게 하기는 어렵다.
의도적으로 프로그래밍 하는 방법
- 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다.
- 맹목적으로 코딩하지 말라.
- 계획을 세우고 그것을 바탕으로 진행하라.
- 신뢰할 수 있는 것에만 기대라.
- 문서로 남겨라.
- 코드 뿐 아니라 우리의 계획도 테스트하라.
- 우선 순위를 정하라.
- 과거의 노예가 되지 말라.
이번 장을 읽으면서 조금 다를 수도 있으나 코드 컴플리트에서 읽었던 컴파일을 해서 결과를 확인하지 말고, 코드를 완전히 이해한 후 컴파일 하라는 이야기가 떠올랐다. 습관적으로 일단 실행시켜보고, 문제를 확인했었는데 코드를 더 살펴보는 시간을 가져야겠다.
32. 알고리즘의 속도
알고리즘의 속도는 O(빅 오 표기법)를 사용해 표기하는 것이 일반적이고 꽤 괜찮은 방법이다.
우리가 실무에서 고려해야 할 것은, 좋은 속도를 가진 알고리즘을 만들어 도입하는 것과 작은 입력에서만 괜찮은 속도를 가진 알고리즘을 사용하는 것이다. 좋은 속도를 가진 알고리즘이 항상 좋지는 않다는 것을 명심해야 한다. 단순히 10개의 입력에서의 작업을 처리하는 루틴이라면 작성하기 쉬운 알고리즘ㅇ르 택하는 것이 더 효율적일 수 있다.
33. 리팩터링
리팩터링을 해야할 때
- 중복이 있을 때
- 직교성이 좋지 않을 때
- 해당 내용이 너무 구식일 때
- 성능을 개선 해야 할 때
리팩터링 해야 하는 것을 두려워하지 말고, 지금 당장 시작해라. 만약 시간이 부족하다면 리스트에 적고 하나씩 지워가자. 코드는 항상 변해야 한다. 요구사항이 수정될 수도 있고, 버그가 발견될 수도 있다. 그 때를 대비해서 유지보수가 쉬운 코드를 작성해야 한다.
34. 테스트하기 쉬운 코드
여기서 TDD 이야기가 또 나온다. 코드를 작성하기 전에 테스트 코드를 먼저 작성하면 요구사항에 더 가까운 소프트웨어를 만들 수 있다.
35. 사악한 마법사
우리는 많은 도구들을 사용한다. 자동 빌드 도구와 자동으로 개발 환경을 만들어주는 도구 등 여러가지 마법사를 사용하는데, 이를 사용하지 않고 우리가 직접 소프트웨어를 작성할 수 있는 힘을 길러야, 마법사보다 더 좋은 성능을 갖는 소프트웨어를 만들 수 있을 것이다.
