복합적인 복잡성

가끔 이런 상황이 발생한다. 하드웨어 디자이너가 하드웨어를 정말 복잡하게 만든다. 그러면 복잡한 어셈블리 언어가 쓰일 수밖에 없다. 그러면 프로그래밍 언어와 컴파일러도 정말 복잡해진다. 그래서 프로그래머인 여러분이 손을 대야 할 즈음이면 천재적인 설계와 테스트 없이는 버그 없는 코드를 쓸 희망은 이미 사라진 후다. 그런데 설계가 완벽에 못 미친다면 음…, 당연히 아주 많은 버그가 발생한다.

이는 다른 프로그래머의 관점을 이해하는 문제이기도 하다. 자신에게 단순한 것이 다른 사람에게는 복잡할 수도 있다.

여러분이 쓴 코드에 대해 아무것도 모르는 다른 사람의 관점을 이해하고 싶다면 지금껏 한 번도 사용해본 적 없는 라이브러리에 관한 설명을 찾아서 읽어보라.

그리고 한 번도 읽어본 적 없는 코드도 찾아서 읽어보라. 단순히 각 줄을 이해하려고 하지 말고 프로그램 전체가 어떤 역할을 하는지, 그 프로그램을 수정해야 한다면 어떻게 할 수 있을지 생각해보라. 여러분이 쓴 코드를 읽게 될 다른 사람도 바로 그와 같은 경험을 할 것이다. 다른 사람의 코드가 아주 복잡해야만 답답함을 느끼는 건 아님을 알겠는가?

간혹 아주 간단한 내용도 오해하는 일이 있기 마련이다. 그 또한 주의해야 할 부분이다. 어떤 프로그래머의 설명이 앞뒤가 맞지 않는다면 어느 지점에선가 그가 잘못 이해한 것일 수 있다. 물론 말하는 주제가 엄청나게 복잡해서 애초에 완벽하게 이해하려면 그 분야의 박사학위가 필요했을 수도 있다.