라이브러리 코드를 작성하는 것은 매우 신중해야 한다. 라이브러리 코드는 클라이언트 코드와는 다르게, 한번 사용되기 시작하면 그것에 의존하는 코드들이 만들어지기 때문에, 나중에 이 인터페이스를 변경하는 것은 간단한 문제가 아니다.
상대적으로 클라이언트 코드는 크게 신경쓰지 않고 작성해도 별 문제가 없지만, 라이브러리 코드는, 바로 클라이언트를 작성하는데 사용하지 말고 시간을 두고 여러번 사용하면서, 충분히 코드를 검토하기 바란다. 이것은 어떻게 보면 글쓰기의 퇴고와 비슷하다고 할 수 있다. 시간을 두고 다시 생각해보면, 그 당시에는 보이지 않던 문제가 새롭게 보일 수 있고, 완벽하다고 생각했던 디자인에 중복이 존재하거나, 불필요한 요소를 포함하고 있는 경우도 있다. 프로그래머란 족속들이 워낙 단기간에 많은 정보를 처리하는데 익숙하기 때문에, 종종 시야가 좁아지는 경우가 많은 것도 원인이 된다. 또, 라이브러리 코드는 위에서 말한 인터페이스 문제 외에도, 성능 문제에 민감할 수 있기 때문에 더욱 그렇다.
클라이언트 코드는 라이브러리 코드를 작성하는 것보다 이런 압박이 덜한 편이지만, 그래도 최대한 간결하고 깔끔한 코드를 작성하도록 노력하는 것이 좋다. 좋은 코드는 이런 작은 부분에서부터 시작한다.
상대적으로 클라이언트 코드는 크게 신경쓰지 않고 작성해도 별 문제가 없지만, 라이브러리 코드는, 바로 클라이언트를 작성하는데 사용하지 말고 시간을 두고 여러번 사용하면서, 충분히 코드를 검토하기 바란다. 이것은 어떻게 보면 글쓰기의 퇴고와 비슷하다고 할 수 있다. 시간을 두고 다시 생각해보면, 그 당시에는 보이지 않던 문제가 새롭게 보일 수 있고, 완벽하다고 생각했던 디자인에 중복이 존재하거나, 불필요한 요소를 포함하고 있는 경우도 있다. 프로그래머란 족속들이 워낙 단기간에 많은 정보를 처리하는데 익숙하기 때문에, 종종 시야가 좁아지는 경우가 많은 것도 원인이 된다. 또, 라이브러리 코드는 위에서 말한 인터페이스 문제 외에도, 성능 문제에 민감할 수 있기 때문에 더욱 그렇다.
클라이언트 코드는 라이브러리 코드를 작성하는 것보다 이런 압박이 덜한 편이지만, 그래도 최대한 간결하고 깔끔한 코드를 작성하도록 노력하는 것이 좋다. 좋은 코드는 이런 작은 부분에서부터 시작한다.