|
델파이로 프로그램을 만들다보면 종종 TTable, TQuery같은 TDataset 객체 전체를 반복문으로 뒤져야하는 코딩을 자주 하게 된다. 델파이 매뉴얼을 보면 이 경우 대략 다음과 같은 식으로 코딩을 하라고 권한다.
var
dataset : TDataset;
bookmark : TBookmark;
tot : Double;
begin
bookmark := dataset.bookmark; // 현재 레코드 포인트 위치 보관
dataset.DisableControls; // 제일 중요한 코드
tot := 0;
dataset.First;
try
while not dataset.Eof do begin
// 레코드를 처리하는 핵심 코드 시작
tot := tot + dataset.FieldByName('somevalue').AsFloat;
// 핵심 코드 끝
dataset.Next;
end;
finally
dataset.Bookmark := bookmark; // 레코드 포인트 복원
dataset.EnableControls // 역시 중요한 코드
end;
위 코드에서 핵심 로직은 tot := tot + dataset.FieldByName('somevalue').AsFloat; 이다. 나머지 코드는 이 코드를 수행하기 위한 선후 처리 코드, 즉 변두리 코드이다. 변두리 코드라 함은 어떤 기능을 처리하기 위해서 반드시 필요는 하지만, 핵심 로직에서는 별로 중요하지 않은 코드를 말한다. 어쨋든 상당수의 델파이 개발자들이 저런 코드를 자주 작성할 것이다. 그런데, 나 역시 저런 코드를 반복적으로 작성하다가 매우 짜증나는 경험을 하였다. 종종 중요한 라인을 빼먹는다는 것이다.
예를 들어 dataset.DisableControls는 매우 중요한데도 불구하고 빼먹거나, while dataset.Eof do 식으로 not 을 빼먹거나, 마지막 .EnableControls 를 빼먹거나, bookmark 저장 로직을 빼먹거나, dataset..Next 를 빼먹어서 무한 루프에 빠지게 하는 등의 실수다. 또 귀찮아서 종종 try finally 블럭을 생략하기도 한다.
이런 실수를 하면 그 원인 찾기가 쉬울 때도 있지만, 때로는 매우 어려울 수도 있다. 대부분의 프로그램은 소스량이 장난 아니기 때문이다. 어쨌든 간에 저런 실수를 하면 쓸데없는 디버깅 때문에 시간낭비가 발생한다. 내 경험에 의하면 DisableControls와 EnableControls의 짝이 안맞아서 한참 동안 디버깅하는 개발자를 본 적도 있고, DisableControls와 EnableControls를 완전히 생략해서 낭패를 당한 개발자를 본 적도 있다. DisableControls와 EnableControls를 절대로 우습게 보면 안된다. 저거 빼먹으면 희안한 오류를 당할 수 있다. 북마크 역시 마찬가지다.
개발자로서 디버깅을 피할 수는 없지만, 가급적 디버깅 시간을 줄이면 생산성이 향상된다는 것이 개발 선배들의 주된 권고사항이기에, 저런 허접한 실수를 어떻게 하면 피할 수 있을까 고민하다 다음과 같은 방식을 만들었다.
tot := 0;
Duck(dataset).First().Execute(
procedure begin
tot := tot + dataset.FieldByName('somevalue').asFloat;
end );
Duck(dataset)은 닉 호지스가 쓴 책 내용 중에, Duck 타이핑에 영감을 받아서 만든 함수다. Duck()는 Fluent 함수 호출과 익명함수를 이용한다. Duck 함수는 북마크 보관, DisableControls, EnableControls, .Next 호출을 알아서 처리한다. Duck 함수를 만든 다음 나는 저 함수를 매우 애용하게 되었다. 코딩량도 훨씬 줄어들고 엉뚱한 실수도 줄어들고, 가장 좋은 점은, 레코드를 처리하는 핵심 로직이 확연히 드러난다는 것이다.
그런데, 나는 내가 만든 라이브러리 코드를 남한테 보여주고, 이거 괜찮지 않냐라는 질문을 즐기는 자아도취병이 있다. 그래서, 저 Duck 함수를 몇몇 다른 델파이 개발자들에게 보여줬더니, 그 반응이 참으로 희안하였다.
어떤 개발자는 형님 직이네요, 기똥 찹니다요 하는 찬사를 던지는가 하면, 어떤 개발자는 형님 저렇게 코딩하면 가독성이 떨어집니다 라면서 고개를 절래절래 흔드는 것이었다. 문제는 고개를 절래절래 흔들면서 가독성이 떨어집니다요 라는 개발자들이 꽤 있었다는 것이다.
대체 코드 가독성의 정의가 뭘까?
1. 변두리 코드 없이, 핵심만 드러나는 간략한 코드?
2. 주구리 장창 변두리 코드를 나열하더라도 델파이 매뉴얼대로 길게 작성한 코드?
3. 본인의 실력 수준에서 이해 가능한 코드?
2. 3 번째 방식이 가독성이 좋은 코드라면, 내가 델파이 강좌에서 소개한 Managed<T> 역시 가독성이 떨어지는 방식이 아닐까? 판단은 여러분의 몫이다. 어쨋든 나는 Duck(dataset) 방식이 좋다고 믿기에, 앞으로도 저 방식을 고수할 것이다. 나는 코드가 간결할수록 가독성이 좋다고 믿는다. 나는 긴 코드를 매우 싫어하는 메멘또 형 개발자이기 때문이다.
|
코드의 가독성이 좋다는 기준은 대체 뭘까? 
