문제가 여러 군데 퍼져있을수록 수정하기가 어렵다. 비슷한 로직을 파라미터화해서 빼내지 않고, 여기저기에 약간씩 변경해서 그냥 집어넣어둔 경우, 변경 사항이 생기면 그걸 일일이 찾아다니며 수정해야 한다. 그나마 그 프로그램을 짠 사람이라면 모르겠지만, 유지 보수를 하는 사람에게는 악몽이다.
이것은 OOP의 문제점이 아닐까... 가상 함수를 이용하는 경우, 로직이 분산되는 것은 어쩔 수 없는 일 아닌가...
2 입력 데이터를 검증하자.
어서트 등을 이용해서 입력 데이터를 반드시 검증해야 한다. 입력 데이터가 잘못된 것인지 모르고, 다른 곳을 헤메는 것만큼 바보 짓도 없다. Debugging Applications에도 나왔듯이 같이 일하는 동료가 화를 낼 정도로 어서트 떡칠을 해라.
3 캡슐화를 하자.
캡슐화를 잘 하면, 그 모듈을 가져다쓰는 사람이 신경쓸 일이 적어진다. 또한 어떤 문제가 발생했을 때 그 문제를 고립(isolation)시키는 일이 쉬워진다.
4 Copy & Paste는 만악의 근원이다.
위에서도 언급한 문제다.
5 정적 배열을 남용하지 말자.
예를 들어 라이브러리 짜는 사람이 귀찮아서 몇십메가씩 되는 배열을 정적으로 잡아서 쓴다면, 그 라이브러리를 가져다 쓰는 클라이언트 프로그램은 필요하지 않은 경우에도 몇십메가의 메모리를 기본으로 깔고 들어가게 된다.
6 래퍼를 너무 좋아하지 말자.
다른 사람이 만든 소스를 가져다쓸 때, 무조건 래퍼부터 작성하는 사람이 있다. 개인차는 있겠으나, 사용이 비교적 간단하다면 래퍼 없이 바로 가져다쓰는 것이 코드를 간단하게 만드는 데 도움이 된다.
7 필요없어진 함수나 변수 등은 삭제하자.
언젠가 쓸모있지 않을까...라는 생각에 남겨두면 프로그램의 크기를 불리고, 이해를 어렵게 만들 뿐이다.
8 전역 변수 사용을 삼가하자.
특히나 코드의 흐름과 관련이 있는 값(예를 들어 C 런타임의 errno)을 전역 변수로 만들지 마라.
9 너무 큰/작은 클래스를 만들지 말자.
이런 경우, 저런 경우를 다 고려해서 클래스를 만들다 보면 클래스 크기가 매우 커져버린다. 이런 클래스는 분석하기가 어렵다. 반대로 어떤 데이터를 모델링해야 하는데, 10가지 속성이 있다고 하자. 이것을 하나의 클래스에다 집어넣지 않고, 상속을 이용해 1개층에 하나씩 변수를 두는 경우, 10개의 클래스가 생긴다. 이런 방식도 코드를 이해하는데 도움을 주지 못한다.
이것은 OOP의 문제점이 아닐까... 가상 함수를 이용하는 경우, 로직이 분산되는 것은 어쩔 수 없는 일 아닌가... 