거의 5년 넘게 유지 보수를 해 오던 소스가 있습니다.
정리를 하는 차원에서 관련 소스를 죽 보다 보니까 재미있는 현상을 하나 발견했습니다.
윈도우 탐색기에서 파일 하나하나의 "수정한 날짜"를 보았는데요,
유지 보수에 애를 먹였던 소스일수록 이 수정한 날짜가 최신이라는 것입니다(당연한 얘기이지만).
대략적인 퍼센트를 따져 보자면
초기에 만들어 놓고 작동 방식에 아무런 이상이 없는 신경을 쓰지 않아도 되는 모듈이 약 90% 정도이고
나머지 10%의 소스를 가지고 계속해서 수정 작업을 거치면서 유지 보수를 하고 그랬습니다.
그리고 더욱 재미있는 것은
코딩에 들어 가기 이전에 인터페이스를 만드는데 시간을 많이 들이고 고민을 많이 한 모듈일 수록
그러한 수정 작업이 상대적으로 적다는 것입니다.
하고자 하는 말은?
인터페이스에 대해서 고민을 많이 하자.
그런 의미에서 심도 있는 프로그래밍 설계 방식에 대한 더 큰 공부가 필요할 듯 합니다.
공부하는 입장에서 "왜 언어의 문법이 이렇게 생겨 먹었나"가 아닌
언어 디자이너 입장에서 "왜 이렇게 디자인했을까"를 고민하다 보면
해답을 스스로 찾을 수 있을 것입니다.
좋은 글 잘 읽었습니다 ^^
저는 학부 때 왜 설계에 관련된 과목을 듣나~ 하고 투덜대던 때가 있었습니다.
UML이런게 쓸모없어 보였거든요 -_-;
근데 .. 요새 좀 큰 프로젝트를 진행하면서 느끼는게 .. (길길님에 비하면 아무것도 아니지만요 ^^;)
길길님 말씀처럼 설계가 잘 안되면 유지보수는 말할것도 없이
진행하다가 초기화되는(-_-) 사태가 벌어질 수 있다는 것이었습니다.
그래서 ... 대학원 들어와서 설계에 대해서 다시 고민하고 고민하고 그럽니다 -ㅁ-;
결론은 .. 배울 때 이걸 왜 배우는지 실감을 하면서 잘 배워놓자 입니다 ㅋㅋ
아직까지 저도 초기화(?)는 종종 합니다. 지금까지 해 보지 않았던 새로운 분야를 하게 되면, 일단 구현하려고 하는 것이 현실적으로 구현이 가능하냐 그렇지 않느냐를 먼저 확인을 합니다. 막코딩으로 되나 안되나를 먼저 따져 보면서 전체의 틀도 잡습니다. 그 다음에 가서야 본격적인 설계 잡업에 들어 갑니다.
하나의 예를 들어 보죠. 혹시 이 부분의 구현이 어렵지는 않을까, 내 컴퓨터에서는 되는데 다른 컴퓨터에서는 작동하지 않을 가능성이 있을까, OS 가 달라지면 어떨까, 네트워크 환경이 달라 지면 어떨까, .... 일단 예외의 가능성이 있다고 판단되면 일단 interface로만 설계해 놓고 override로 작성해야 할 함수들을 나열해 봅니다. virtual method가 많아 지면 많이 질수록 전체 framework를 이해하는데(혹은 남에게 설명하는데) 어려움이 있지만, virtual method가 적을 수록 다양한 환경에 적응시키지 못할 수도 있는 단점이 존재합니다. 결국에 가서 왜 OOP 언어가 virtual 구조(function pointer)을 지원하게끔 발전이 되어 왔는지를 알게 되죠. 뭐랄까, 수학시간에 fourier transfom을 공부할 때에는 무슨 소리인지 이해하기가 어려운데, 음악 재생기 equalizer를 만들 때가 되어서야 이해하게 된다고나 할까요? "필요성"을 느끼게 되면 그간 배워 온 것들에 대한 근본 원인을 경험할 수 있습니다.
현업에서 오래 뛰다 보면 왜 그러한 개발 방법론이 나오게 되었는가를 자연스럽게 느끼게 될 것입니다. 프로그래밍 언어의 패러다임이 imperative 언어의 영역에서 object orinted 영역으로 넘어 가게 되었는지도 스스로 터득하게 되구요. 소프트웨어 공학, 디자인 패턴, 개발 방법론, 이런 것 배워 두면 좋습니다. 배울 때는 모르지만 나중에 가면 결국 알게 됩니다. 이해가 아닌 느낌으로 .
매체와 매체를 이어주는 통로, 인터페이스의 중요성을 현대인들의 빡빡한 현실에 묻혀버리는것같아 너무 안타깝습니다.
기획의 단계가 권장사항이 아니라 필수사항이라는것을 인식하지못하는것같습니다.
좋은 글에 감사드립니다. ^^