개발자로 살아가면서 적은 시간이 주어지고 해당 시간 안에 개발을 완료해야 하는 상황이 종종 찾아온다. 그럴 때마다 좋은 코드를 짜기 위한 노력은 코드를 일단 동작하도록 만든다는 생각보다 우선순위가 뒤처지게 된다. 이러한 코드는 당장의 문제를 제기하지 않는다. 서비스가
작게만들어라저자는 함수를 만들 때 가능하면 짧게 만들라고 조언한다. 함수를 이해하기 쉽게 하고 의도를 분명히 하고 프로그램 내부를 직관적으로 파악하려면 어떻게 해야 하는가? 저자는 매우 단순한 해결책을 제시한다. 함수 코드를 가능한 한 작게 만드는 것이다. 2개의 함수
오늘 구현한 기능은 시간이 지나면서 변하게 될 수 있다. 오늘 작성한 코드는 앞으로 유지보수할 코드의 품질에 지대한 영향을 미칠 수 있다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준
오류 코드를 사용하게 되면 논리가 오류 처리 코드와 섞이게 되어 코드가 복잡해진다. 차라리 예외를 사용하는 것이 낮다.try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. 그러므로 예외가 발생할 코드를 짤 때는 try-cat
모듈을 짜고 보니 짜임새가 엉망이고 알아먹기 어렵다. 지저분한 모듈이라는 사실을 자각한다. 그래서 자신에게 이렇게 말한다. “이런!주석을 달아야겠다!” 아니다! 코드를 정리해야 한다.다음 코드 예제 두 개를 살펴보자.다음 코드는 어떤가?코드로도 대다수의 의도를 표현할
첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.테스트 코드는 작성만 하면 괜