코딩은 기계적인 작업이 아니다.
프로그램이 정확하고 생산적으로 작동하기 위해 사려 깊은 생각과 판단을 통한 결정이 필요하다.
그렇지 않은 코드는 우연에 맡기는 프로그래밍으로 생산된 코드이다. 코드가 작동은 하지만 왜 작동하는지 설명을 못한다.
이 챕터에서는 프로그래머가 코딩 과정에서 더 적극적으로 행동하는 방법에 대한 내용이다.
행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다.
대신 의도적으로 프로그래밍을 해야한다.
지금 잘 동작하는데 괜히 건드렸다 일을 만들 필요가 있을까?
우연에 맡기는 프로그래밍을 하지 말라.
애초부터 에러를 적게 하려면 의도적으로 프로그래밍하는 것이 도움이 된다.
일반적으로 입력의 크기는 알고리즘에 영향을 준다.
입력 크기가 클수록, 알고리즘의 수행시간이 길어지거나 사용하는 메모리 양이 늘어난다.
대게 회사 일에서 정렬 루틴을 작성하는데 시간을 많이 쓰지 않는다.
왜냐면 이미 나와 있는 라이브러리에 들어있는 정렬 루틴이 여러분이 작성하는 것보다 성능이 좋을 것이다.
여러분 알고리즘의 차수를 추정하라.
입력값이 작을 경우 단순한 O(n²)가 복잡한 O(nlog(n))보다 더 좋은 성능을 내기도 한다.
여러분의 추정을 테스트하라.
가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.
입력 데이터의 규모가 작을 경우 그 데이터를 준비하는데 걸리는 시간이 알고리즘을 돌리는 시간보다 오히려 더 걸리는 일이 생기기도 한다.
프로그램이 발전해가면, 초기에 내린 결정을 다시 고려하고 코드의 일부분을 다시 작성하는 일이 점점 더 필요해진다.
이것은 지극히 자연스러운 과정이다
코드는 발전해야한다
코드는 정적인 존재가 아니다.
리팩토링 : 코드 다시 작성하기, 다시 설계하기를 총괄하는 단어 즉, 재설계
중복되었을 때
직교성이 좋지 않을 때 더 좋게 만들 수 있는 코드 설계를 발견했을 때
직교성 : 모듈간의 독립성
유효기간이 끝난 지식을 발견 했을 때
사물은 변하고 요구사항은 변경된다 코드는 지금 상황에 뒤떨이지지 않게 유지되어야 한다.
성능을 개선하기 위해서
잘 되던 코드를 변경하는 것은 고통스러운 작업이다!
하지만 리팩토링을 하지 않고 추가로 작업한다면 신경써야할 의존성이 더 많이 생기게 되고 결국 문제가 일어났을 때 고치기 위해서 훨씬 더 많은 시간을 투자해야하기 때문이다.
리팩토링이 필요한 코드를 종양
이라고 생각하면 좋다.
종양이 작을 때 수술을 하는 것이 좋지 다른 곳으로 전이될 때까지 놓아두면 더 큰 문제가 일어나기 때문에 리팩토링은 중요하다.
일찍 리팩토링하고, 자주 리팩토링해라
천천히 신중하고 조심스럽게 해야한다.
리팩토링은 손해보다 이득이 큰방향으로 가기 위함이다.
소프트웨어 엔트로피에서 배운 교훈인 "깨진 창문을 그대로 놓아두지 말라"라는 말을 명심해라.
모듈을 통제된 환경에서 철저하게 테스트하고 나면 더 넓은 환경에서 그 모듈이 어떻게 행동할 것인지 더 감을 잡을 수 있다.
소프트웨어 단위 테스트란 어떤 모듈에게 이것 저것 시켜보는 코드를 가르킨다.
일반적으로 단위 테스트는 일종의 윈위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호출한다. 그런 다음 반환된 결과들을 이미 알고 있는 값과 비교해보는 것이다.
나중에 이런 모듈들을 모아서 조립할 때도 우리에게는 개별부분이 기대대로 잘 동작할 것이라는 믿음이 있을 것이다.
다양한 종류의 테스트 케이스들과 경계 조건들에서도 모듈이 약속한 대로 기능을 잘 수행하는지 테스트한다.
테스트를 염두에 두고 설계하라.
모듈을 설계할 때는 그것이 지켜야 할 계약과 계약을 지키는지 테스트하는 코드도 함께 설계해야 한다.
단위 테스트는 찾기 편한 곳에 위치해야 한다.
테스트 코드를 쉽게 접근할 수 있게 해놓는 것은 후에 해당 코드를 사용할 지도 모르는 개발자에게 좋은 자원 2가지를 주는 것이다.
테스트는 기술적이기라기보다는 문화적인 것이다.
자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
해당 코드의 주인은 자신이 아닌 것이다.
결국 유지보수도 못할 것이고 디버깅해야 할 때가 오면 고생하게 될 것이다.
누구든 자신이 완전히 이해하지 못하는 코드를 내놓아서는 안된다.