프레임워크가 정해 둔 자리

공공 프로젝트라 eGovFramework 를 처음 썼다. 받아서 열어 보니 폴더 구조가 이미 정해져 있었다. 어디에 무엇을 두는지가 문서가 아니라 구조로 정해져 있었다.

Open Table of contents

폴더와 이름이 정해져 있었다

화면을 받는 것과 업무를 처리하는 것과 데이터를 다루는 것이 각각 다른 폴더에 있었다. 클래스 이름도 Controller 와 Service 와 DAO 로 끝나게 돼 있어서 이름만 보면 역할이 보였다. 새 파일을 만들 때 어디에 둘지 고민할 것이 없었다.

정해진 자리에 두면 위치를 알려 주는 설정을 따로 쓰지 않아도 됐다. 설정이 줄어든 만큼 설정이 틀려서 나는 문제도 줄었다. 규약이 설정을 대신하고 있었다.

호출은 Controller 에서 Service 로 그리고 DAO 로만 흐르고 반대는 없었다. 방향이 한쪽이라 순환 참조가 생길 자리가 없었다. 어디서 무엇을 부르는지 따라가기도 쉬웠다.

Service 에 할 일이 없을 때 건너뛰고 Controller 에서 바로 부르고 싶은 유혹이 있었다. 그때는 편한데 나중에 조건이 붙으면 그 조건이 여기저기 흩어진다. 할 일이 없어도 자리를 만들어 두니 나중에 거기 넣게 됐다.

어느 구현을 쓸지가 코드가 아니라 Spring 설정 XML 에 적혀 있었다. 구현을 바꿀 때 부르는 쪽을 안 고쳐도 됐다. 시험할 때 데이터베이스 없이 가짜 구현으로 바꿔 끼우는 것도 됐다.

대신 흐름이 코드만 봐서는 안 보인다는 단점이 있었다. 무엇이 연결되는지 알려면 설정을 열어야 한다. 이름 규칙이 그 단점을 상당히 메워 줬다.

혼자 만드는 작은 것이면 규약이 번거롭게 느껴진다. 사람이 여럿이고 파일이 수백 개가 되면 이야기가 달라진다. 새로 온 사람이 파일 위치를 묻지 않아도 됐다.

정해진 자리가 있으면 논의할 것이 줄어든다. 어디에 둘지를 매번 정하지 않으니 그만큼 다른 것에 시간을 쓴다. 규약의 값은 규칙 하나하나가 아니라 그것이 없앤 결정의 개수에 있었다.