소스코드리뷰(VI) SQL 문은 문자열이다

프로그램을 짤 때 본질적인 요소와 비본질적인 요소를 구분하여 설계하면 프로그램의 유지보수가 쉽고 소스가 간결하게 된다. 간결하고 알아보기 쉬운 소스가 오류(이른바 버그)가 적어지는 것은 당연한 일이다.

에너지 효율을 높이기 위하여

수식에서 분자를 높이는 것도 하나의 방법이지만 분모를 높이는 것도 좋은 방법인 것처럼, 품질을 높이려면 입력(투입된 공수와 시험이라고나 할까) 을 높이는 것도 방법이다. 그러나 자원은 유한하므로 손실에 해당하는 프로그램 오류를 줄이는 것으로 관심을 가지게 된다.



한편 제조업에서 유명한 품질공학적 관점에서 볼때 손실(오류)를 줄이기 위해 노력하는 것보다 정상동작을 하도록 노력하는 것이 전체적인 품질을 높일수 있다는 것이 소프트웨어 개발에도 들어맞는다고 생각한다. 즉 오류를 없애기 위해서는 힘들여 시험으로 오류를 잡아내려고 하지 말고 오히려 건장한 설계(기능적 요소 + 비기능적 요소)가 동작되도록 하는 것이 더 낫다고 할 수 있다.

설계에 시간이 몰려서 설계를 뜯어 고치고 한가지 프로젝트만을 위하여 전근대적인 가내 수공업과 같은 방식으로 소프트웨어를 개발하는 습관을 벗어나야 한다.

SQL문을 자원화하라

원래의 화제로 돌아와서 SQL문은 SQL을 해석하는 데이터베이스에서는 의미있는 명령어가 되지만 프로그램 소스에서는 본질적으로 문자열에 해당한다. 문자열에 해당한다는 것은 명령어, 함수명, 변수와 달리 자원(Resource)으로 취급해도 좋다는 것을 의미한다. 화면에 표시되는 캡션 문자열, 라벨명을 소스코드에 리터럴 정의하는 것을 피하듯이 SQL문도 자원 취급하여 소스코드에서 리터럴 정의하는 것을 피해야 한다.

데이터베이스를 다루는 소스코드를 보면 한결같이
sql = "SELECT " + strField + " FROM " + strTable
sql = sql + "WHERE " + strCondition
의 유형의 문자열 조작이 조건분기와 함께 끊임없이 이어진다. 그리고 이러한 소스코드는 대개 다시는 재활용되지 않는 1회용코드일 뿐이다. 그리고 인용부호의 홍수속에서 가독성은 전혀없는 수수께끼 문장이 될 따름이다. 리뷰하는 사람도 거들떠 보지 않는다.

(선인장: 가시 사이에 바늘이 끼어 들어가도 찾기 어려울 것이다.)
Oracle 데이터베이스 해설서에 의하면 샘플 프로그램이 이런 방식으로 설명되어 있음을 최근에 발견하고서 적잖이 놀라게 되었는데, 설명하기 쉬운 예를 보고서 책임을 돌리는 것은 전문 프로그래머에게는 궁색한 핑계가 될 것이다.

자원화하는 방법은 SQL문의 원형(prototype 또는 template)을 INI파일이든 DB파일이든, 또는 XML파일이든 외부정의하는 것이다.
(예)
<key>getProject</key>
<sql>SELECT * FROM tableProject WHERE projectID=%d</sql>

그리고 소스코드에서 할 일은 특정 입력값에 대해 조건을 %d에 해당하는 치환문자열과 바꾸는 것이다.

SQL문을 자원화하면 프로젝트에서 사용되는 SQL문이 모두 망라되어 데이터베이스에 접근하는 방식을 망라할 수 있게 되고,  데이터베이스 설계와 동시에 SQL문을 정의하는 것이 가능하다. 그러면 치환문자열이 입력화면의 입력필드와 일치하는지 쉽게 확인가능하다.