소스코드란 복잡해 질 수 밖에 없는 것인가?

이 시점에서 왜 이런 함수 혹은 객체를 불러들였는지 바로 이해가 되지 않을 때를 말합니다.

이런 상황이 실제 코딩을 한 사람도 나중에 다시 보면 같은 생각을 할 것 같습니다.
결론은 주석으로서 왜 그렇게 처리 했나를 명시하는게 맞다 생각이 드는군요

암튼 다른 사람 소스 보는게 더 힘든건 사실 입니다. ^.^

코드의 일부분만을 본다면 좋은 코드를 판단하는 기준이 프로그래머들 사이에서도 어느 정도 일치하리라 생각합니다.

하지만 코드 수준을 넘어서 아키텍처 관점에서 본다면 여기에는 사람의 혼,정신,스타일,철학,가치,개념 이런것들이 들어간다고 생각해요.

그래서 객체를 선택하고 정의하는 기준이 사람마다 다 다르기 때문이 아닐까요?

이 간극을 좁히기 위해서 패턴 (언어)가 존재하는게 아닐까 생각합니다.

코드가 복잡하다는 것을 저는 2가지로 나눠서 생각합니다.

1. 코드가 꼬여있고 의존성이 많다.
코드가 얽혀서 한군데를 손보거나 기능을 추가하려면 여기저기를 손대야한다.
복잡하다는 표현보다는 꼬여있다나 얽혀있다가 정확한 표현같습니다.

2. 스타일이 낯설고 내가 모르는 기교가 사용되서 복잡해보인다.
예를 들어 코드를 만드는 매크로를 사용해서 기능을 추가햐아할때
매크로를 이해하려고 뜯어보면 무지 복잡해보입니다.
하지만 일단 이해하고나면 아 이래서 그랬구나 이게 이래서 필요했구나하고
그담부턴 쉽습니다. 기존 코드를 수정하거나 기능 추가하는 것도 간편합니다.
패턴을 적용하거나 객체로 관리되는 코드들을 보면 소스를 이해하기는 어렵지만
이해하고나면 관리도 쉽고 문제도 적은데 그런게 2번에 해당합니다.

1번만 피하면 복잡해보이는 코드라도 좋은 코드라고 생각합니다.

정말, 사람의 스타일이나 먼저 익힌 언어나 라이브러리에 따라... 많은 차이가 있는 거 같더군요.
저는 얼마 전에 C++를 배우고 계속 공부하면서 MFC도 동시에 공부하고 지금 프로그램을 수정하는 중입니다. STL은 거의 모르고 있다고 봐야 되구요.

그런데 제가 지금 맡은 프로젝트를 진행하시던 분이 MFC보다 STL을 많이 쓰시는 분이다 보니(그리고 Win32API를.... 윽.) 왜 이렇게 했을까 하는 생각이 많이 들조. 근데 그 스타일이라던가 늘 사용하시던 STL을 쓰시는 것을 어떻게 할 수는 없겠조. MFC 를 주로 쓰는 것 하고 STL을 주로 쓰고 MFC를 필요에 따라 쓰는 경우 스타일이 많이 달라 지더군요.

이건... 기존 작성자가 어떤 생각을 가지고 어떤 철학으로 어떤 도구를 사용해서 작성했는지를 보려고 노력하지 않으면 그런 생각이 들 수 밖에 없는 거 같습니다. 도대체 왜 이런 거야... 뭐 어쩔 수 없조. 앞으론 프로젝트를 제가 이어서 진행해야 하니 STL을 주로 하고 MFC를 어쩔 수 없을 때만 쓰거나 Win32API로 완성해 버리는 스타일을 이해하려고 노력하는 수 밖에요. 처음엔 그렇게 하고 나중엔 가능하다면 MFC를 주로 쓰는 스타일로 가야 겠조 제가. 동작과 로직에 문제가 없다면요.

뭐.. 그냥 지나가다가 쓰고 갑니다. 출근하려면 이제 자야 겠네요. 여기서 더 시간을 보내다가는... 내일 출근 못할 듯.