"확장에 열려있는 구조로 개발하세요."
마치 객체지향 방법론에 나오는 멋진 말 같지만 그런 거 아닙니다.
SI에서 개발은 최소한의 수정만을 필요로 하는 방법으로 개발해야 합니다. 기능이 하나 바뀌었다고 파일이 6개나 바뀌면 절대 안됩니다.
가능하면 파일 1개, 아니면 2개 정도만 바뀌는 게 최고예요. 3개 이상은 위험 신호입니다.
운이 좋으면 뷰(.JSP) 파일만 바꿀 수도 있습니다. 이렇게 하기 위해서는 처음에 쿼리를 짤 때 당장 사용하지 않는 컬럼도 일단 가져오는 지혜가 필요해요. JSP는 JIT 빌드(Just In Time - 변경이 감지되면 다시 빌드)를 하므로 배포할 때 전체 소스 코드 빌드를 하지 않아 최상의 선택이 되죠.
다만 쿼리문에 select * 는 안됩니다. 감사에서 걸려요.
대부분은 쿼리(SQL.xml) 파일이 바뀌게 됩니다. 비즈니스 로직이 쿼리에 들어있는 경우가 많거든요.
SQL 파일조차도 바꾸기 싫다면 저장 프로시져(Stored Procedure) 를 사용하면 됩니다. 프로시져는 데이터베이스에 저장된 거라서 자바의 빌드와는 아무 상관도 없이 WAS 재시작도 없이 기능을 변경할 수 있습니다.
비즈니스 로직이 자바의 서비스 혹은 컨트롤러 레벨에 들어있는 경우가 있습니다. 쿼리의 결과에 따라 프로그램 처리가 달라지는 분기도 생기기 때문이지요. 이때 운이 없으면 3개 이상의 파일을 수정해야 합니다.
가능한 파일이 적게 바뀌는 구조를 유지하기 위해서는 특정 값을 담기 위한 클래스 (DTO, VO) 를 만들어서는 안 됩니다. Map과 List는 어떤 값이든 담을 수 있는 객체이고, 이걸 단순하게 이용만 한다면 굳이 여러 파일을 고칠 필요가 없어집니다.
Map과 List를 남용하는 것의 단점으로는 코드만 봐서는 파라미터의 이름과 타입이 뭔지 아무도 모른다는 점입니다. 심지어는 만든 사람조차도요.
하지만 걱정하지 않으셔도 됩니다. 신뢰성은 잘 모르겠지만, 여하튼 프로젝트가 끝난 시점에서는 프로그램 명세서도 있고 ERD 도 있습니다. 실제로 작동하는 코드도 있지요.