파견을 나가서 받은 코드를 열어 보니 JSP 하나에 전부 들어 있었다.
DB 연결
쿼리
계산
표 그리기JDBC 연결과 조회와 계산과 출력이 <% %> 스크립틀릿 안에 같이 있었다. 앞서 본 적 있는 모양인데 그때는 계층이 있는데 안 쓰고 있었고 여기는 계층 자체가 없었다.
Table of contents
Open Table of contents
방식을 바꿀 수 없었다
그쪽에는 계층을 나누는 틀이 없었고 새로 넣을 상황도 아니었다. 몇 달짜리 일정에 나 혼자 들어간 자리였다. 전체를 바꾸자고 하면 그 논의만으로 기간이 지나간다.
파견은 그 회사 방식을 따르는 자리이고 방식을 바꾸는 것은 내 범위가 아니었다. 내가 못 끝낼 일은 시작하지 않는 편이 나았다. 대신 내가 만드는 것에서 할 수 있는 것을 했다.
내가 만드는 것만 나눴다
새로 만드는 화면에서는 조회를 DAO 로 뺐다. JSP 에는 받아서 보여 주는 것만 남겼다. 기존 화면은 그대로 두고 새로 만드는 것만 두 파일로 나눈 것이다.
계층이라고 부를 만한 것은 아니고 조회만 분리한 정도였다. 그것만으로도 무엇이 어디 있는지 찾기가 쉬워졌다. 전에는 JSP 를 하나씩 열어 봐야 SELECT 를 찾았는데 이제 DAO 만 보면 됐다.
그쪽 관례를 따른 이름과 위치
DAO 클래스 이름과 패키지 위치는 내 습관이 아니라 그쪽 방식에 맞췄다. 나눈 것은 내 판단이지만 이름과 위치는 관례로 한 것이다.
내가 나가면 다른 사람이 이 코드를 본다. 나만 아는 규칙으로 두면 그 사람이 매번 찾아야 하고 고치지도 못한다. 관례 안에서 나누면 이어받을 수 있다.
같은 쿼리가 여러 화면에 흩어져 있는 것도 발견했지만 합치지는 않았다. 합치면 그 화면들을 전부 확인해야 하는데 파견 기간 안에 그 범위를 감당할 수 없었다. 내가 못 끝낼 일은 시작하지 않는다는 것이 여기서도 같았다.
마무리 — 넘기는 것이 내 몫이었다
합치지 않는 대신 적어 뒀다.
같은 조회가 세 화면에 있고 조건이 다름
어느 것이 맞는지 확인 필요
board_list.jsp
notice_list.jsp
faq_list.jsp인계 문서에 넣었다. 내가 할 수 있는 것은 하고 못 하는 것은 적어서 넘기는 것이 내 몫이었다. 적지 않으면 아무도 모른다.
인계할 것은 셋으로 나눴다.
① 내가 만든 것 — 어떻게 돌아가나
② 내가 발견한 것 — 문제가 있는데 안 고침
③ 내가 못 한 것 — 시작 안 함특히 두 번째가 중요해 보였다. 안 적으면 다음 사람이 같은 것을 다시 발견하느라 같은 시간을 쓴다. 발견에 든 시간을 넘기는 셈이었다. 발견한 것에는 같은 쿼리가 흩어진 자리와 Connection 을 close() 하지 않는 자리를 적었다. ResultSet 과 Statement 도 마찬가지였고 그것이 쌓이면 풀이 마른다.
다만 어떻게 고쳐야 하는지는 조심해서 적었다. 세 화면에 같은 조회가 있고 조건이 다르다는 것은 사실이고 합쳐야 한다는 것은 내 판단이다. 둘을 나눠 적었고 판단만 적으면 다음 사람이 확인할 방법이 없다.
그리고 짧게 적었다. 길면 안 읽힌다. 항목마다 몇 줄로 하고 각 항목에 파일 위치를 붙이니 찾는 시간이 없어진다.
정리
JSP안에JDBC까지 들어 있는 코드베이스를 만날 수 있다- 방식을 바꾸는 것이 내 범위가 아닐 때가 있다
- 내가 못 끝낼 일은 시작하지 않는다
- 내가 만드는 것만이라도 나눠서 만든다
DAO로 조회만 빼도 찾기가 쉬워진다- 이름과 위치는 그쪽 관례를 따른다. 나가면 다른 사람이 본다
- 적어서 넘긴다 — 만든 것과 발견한 것과 못 한 것
- 발견한 것을 안 적으면 다음 사람이 같은 시간을 다시 쓴다
- 사실과 판단을 나누고 파일 위치를 붙인다