31. 우연에 맡기는 프로그래밍
우리는 우연에 맡기는 프로그래밍, 곧 행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다. 대신 의도적으로 프로그래밍(programming deliberately)해야 한다. p273
왜 코드가 잘 돌아가지 않게 되었는지 모르는 까닭은, 코드가 처음부터 왜 잘 돌아가는지도 몰랐기 때문이다. p274
우연적 구현은 단순히 코드가 지금 작성된 방식이 그렇기 때문에 생기는 일들을 가리킨다. 결국에는 문서화되지 않은 에러나 입력값이 특정한 조건에서만 돌아가는 경우와 마주치게 된다. p274
지금 당장 작동하는 것이 사실은 제대로 동작하는 것이 아니라 우연에 의해 동작하는 것일 수도 있다. 우연을 만들기 위해 여러 가지 시도를 한 후 그 시도의 흔적을 남겨둘 수도 있는데, 이런 시도의 흔적들은 결국 코드를 느리게 만들거나 추후 발생할 버그의 원인이 된다. 당장 잘 돌아가는 것 같아 보이는 코드가 모두 제대로 된 코드는 아니다.
우연에 의존하지 않기 위해서, 모듈화나 문서화를 잘 하는 것이 도움이 된다. 다른 사람이 짠 함수를 호출할 때는 문서화된 동작에만 의존한다. 의존할 수 없는 경우가 생긴다면, 이를 추측한 내용을 문서로 남겨라.
의도적으로 프로그래밍하기
- 자기가 무슨 일을 하는지 항상 알고 있어야 한다.
- 완전히 이해하지 못한 것을 사용하려고 시도하지 말라.
- 계획을 우선 세우고 행동하라.
- 신뢰할 수 있는 것에만 기대고, 우연이나 가정에 의존하지 마라. 신뢰할 수 있는 것이 무엇인지 모르겠다면 최악의 상황을 가정해라.
- 가정은 문서로 남겨라.
- 노력을 기울일 대상의 우선순위를 정해라.
- 과거의 노예가 되지 마라. 기존의 코드가 적절하지 않게 되는 순간이 오면 그 코드는 교체 가능하다. 언제나 리팩터링할 자세가 되어 있어야 한다.
32. 알고리즘의 속도
가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘인 것은 아니다. 입력 데이터의 개수가 몇 개인지에 따라 최적화가 의미없어질 수도 있다. 알고리즘을 개선하기 전에 그 알고리즘이 정말로 병목인지를 생각해 봐야 한다.
33. 리팩터링
코딩은 건물을 짓는 일보다는 정원 일을 하는 것과 더 비슷하다. 처음에 심은 식물이 나중에는 죽어서 치워 줘야 할 수도 있고 나무의 가지를 쳐야 할 수도 있다. 코딩에서 이런 작업을 리팩터링이라고 부른다. 코드를 다시 작성하고, 다시 작업하고, 다시 설계하는 작업이다.
아래 문제를 가진 코드는 리팩터링이 필요하다.
- 중복
- 직교성이 좋지 않은 설계
- 유효기간이 끝난 지식
- 성능
일찍 리팩터링하고, 자주 리팩터링하라. Tip47, p294
리팩터링할 것들의 명단을 만들고, 일정에 리팩터링 기간을 넣어 두어야 한다.
리팩터링은 다시 설계하는 것이다. 따라서 원래의 코드에서 오히려 버그를 만들 수도 있다. 아래를 명심해서 리팩터링을 진행하는 것이 좋다.
- 리팩터링을 할 때 새로운 기능을 넣어선 안된다.
- 리팩터링 전에 테스트를 작성해 두고, 가능한 자주 테스트를 돌려 본다.
- 단계를 작게 나누어 신중히 작업한다. 단계가 끝날 때마다 테스트를 돌린다.
35. 사악한 마법사
자신을 위해 만들어진 코드를 정말로 이해하지 못하는 한, 그는 자기 자신을 속이는 것이다. p314
