나는 처음 프로그래밍을 배울 때, 독학 기간이 길었던터라 하나 익히는데에 (특히 포인터) 꽤나 긴 시간이 필요했고, 어떤게 좋은지 나쁜지를 대부분 경험으로써 느껴왔다.
최초 설계에 구현을 어떻게든 맞추는 일도 해보고, 설계가 존재하지 않는 run and fix 프로그래밍도 해보고, 프로토타입을 많이 만들어놓고 베스트한걸 고르기도 해봤다.
다양한 방법을 경험하던중 안좋은 습관 하나가 붙었다. 너무 바쁘게 일을 하다보니 정리의 습관이 부족해 졌단 것이다.
내가 감당하기에 힘들만큼 버겁고, 많은 일이 주어지긴했지만, 그런 것들은 결국엔 다 핑계고 조급한 맘이 문제였다.
메모의 기술에 대한 서평에서 내가 메모를 기록과 증빙의 용도로 사용한다고 얘기했지만, 사실 내 머릿속에 있는 내용을 정리하는 과정으로도 많이 사용했다.
그 중에서도 로직을 순서도로 그리는 방법은 나에게 있어 특히 효율적이었는데, UML을 몰랐고, UML이 필요하지 않았던 혼자 프로그래밍해오던 나로썬 매우 유용한 방법이었다.
어느 덧 경력도 쌓이고 일도 적응이 되자, 머릿속과 코드 만으로 로직을 이해할 수 있다고 자신했으나... 간결하게 코드를 작성해왔다고 한들, 클래스와 클래스 간의 결합도가 높아져버리면 대책없었다. 복잡도도 복잡도고, 변경이 잦은 경우 어느 선을 넘어서 복잡도가 지나치게 커지면 일관성 있는 코드를 유지하기가 힘들어졌다.
이럴때 로직을 작게 나누고 (작게 나누어지지 않는다면 결합도가 높다는 뜻이니 이 결합도를 낮추는 작업을 먼저하고), 작게 나누어진 로직에 순서도를 그렸더니 코딩이 너무 편해졌다. 순서도를 현재 로직대로 업데이트 하며 관리했더니 코드를 보지 않고도 처리 방식을 훨씬 빨리 찾고 이해할 수 있었다.
처음 프로그래밍을 배우고, 게임을 만들때의 방식을 되찾은 것이다. 어린 시절 즐겁게 프로그래밍을 처음 배웠을 때 하나 하나 알아가던 때와 같은 기분이 들어 신이 난건 덤이었다.
이런 순서도만으로 프로그램 내에 수립된 가정을 이해하긴 힘들것 같다고? 나도 그렇게 생각한다. 그래서 생각한 것이 바로 클래스 관계도다. 사실 데이터 베이스의 경우에도 ER다이어그램이라 불리는 스키마 관계도가 일반적으로 통용되고 있다.
순서도는 세부 로직별로 작성되어야 되고, 클래스 관계도는 전체적인 상관관계를 그려놓는것이 좋다. 그에 있어 기준도 명확히 기록해둔다면 해당 관계도 하나만 보고도 이해하기 쉽다.
여기서 또 중요한것이 어느정도 선까지 클래스 관계도를 디테일하게 작성할 것이냐인데... 내 생각엔 멤버 하나 하나 자세하게 나열하는 것보다는 객체와 객체간의 큰 가정(has a 관계나, is a 관계, 또는 패턴을 적용한 경우 패턴 이름 등)을 기록해둠으로써 새로운 가정이 기존 가정을 깨드리지 않도록 하는 것이 중요하다고 본다.
XP에서 강조하듯 죽은 문서는 필요 없지만, 문서화 자체가 필요없는 것은 아니다. 자신이 생각하기에 업무 능률을 높여줄 수 있는 문서화는 반드시 필요하다.
서비스에서 사실상 가장 중요한 DB작업의 경우 여러 단계의 점검 이슈 검토 작업을 거친다. 사실 처음엔 그게 굉장히 번거로웠고, 단순 반복 작업이라 느껴져 귀찮기도 했는데, 각 단계를 거치면서 사소한 실수는 많이 줄어들었다.
코드의 내용을 그대로 담는다면 중복이고 번거로운 반복 작업이 되겠지만, 클래스 관계도는 중복 조차 아니다. 요약이다. 이 얼마나 즐거운가! 우리가 싫어하는 중복이 아니란 말이다!
물론 코드 작성시마다 검토하고 수정해야 되는 번거로움 정도는 있지만, 잘 생각해보면 그 한번의 과정을 통해 잘못된 코드를 양산할 확률이 급감한다.
내가 너무 늦게 깨닳은 것인지 모르지만, 벼는 익을수록 고개를 숙이고, 프로그래머는 경력이 쌓일 수록 더 꼼꼼해져야 한다고 본다.
조금만 더 부지런해지자.
