해당 프로젝트는 화면 기획서를 토대로 진행했다.
간단한 게시판이었지만 검색조건 만드는 것과 페이징처리, 파일업로드 다운로드 등
그 속에 세세한 기능 구현을 해야했음.
리뷰 할 때 중요하게 봤던 것들
1. 코드컨벤션(변수명명규칙, 들여쓰기의 제한 등)
2. 자바언어의 사용 그 자체 (static과 instance 영역의 구분과 사용법, 싱글턴패턴, 깊은복사 얕은복사 등)
3. 레거시 기술들의 사용 방법 (JDBC의 자원 사용과 해제에 대해)
4. 유효성 검사를 백과 프론트에서 모두 구현하도록
5. 자바 표준의 주석으로 주석정리
사용기술
언어: java11, mariaDB sql, javascript
웹앱 서버: tomcat9
웹앱 라이브러리: Servlet&JSP
IDE: 인텔리제이
1. ERD구성
2. 계층 구성
model1 아키텍처로 구성하기로 했던 과제 였지만 처음 게시글 등록 화면을 구성할 때
어마어마하게 길어져서 고쳐야 할 부분과 코드를 다시 이해하려면 한참 찾다 보니까 이거는 아니다 싶었다.
따라서 분리해야겠다 마음먹었고 결국 분리했는데 역할과 의미를 명확하게 가지고 분리해야한다고 느꼈다.
- 등록의 과정과 로직
jsp로 view영역에서 바로 service로 전송
service에서 입력값들을 전부 DTO에 넣고 repository에게 넘긴다. --여기까지 JSP
repository에서 DTO의 값을 정리해서 DAO로 넣어준다. -- 여기서부터는 Java class
DAO는 DB에게서 얻고 받은걸 db로 넣는다.
이렇게 분리한 이유 : DAO는 DB와의 교류로 완전하게 그 어떤 클래스와도 관련이 없고 오직 repository에 의해서만 사용 되기를 원했다.
그리고 DTO는 view 까지 Data를 옮김으로 서비스로직에 맞춰 데이터를 구성하기에 DAO와 약간의 정합성이 맞지 않기 때문에 DAO가 DTO를 사용하지 않게끔 구성했음.
service는 view 영역에서 과도한 로직 코드가 발생되기에 이를 분리하려고 했다.
피드백:
DAO에 넣어주고 꺼내는 것도 DTO를 이용하는 것이 좋겠다는 피드백을 받았고 java의 자료형 들로 데이터를 반환하다보니 의미가 모호해지는 trade off가 있었다.
repository의 역할이 모호하다. 즉 모호한 역할까지 분리해서 과하게 분리했다.
repository 영역은 없어도 되겠다 하셨음.
3.실행 후 화면
4. 피드백 받고 전체적으로 수정해야 할 부분
유효성 테스트나 방어 코드 작성할 시에
1. .equals() 의 규칙을 어떻게 할 것 인가 생각하고 확인하는 코드 작성
2. "" 빈 문자열을 확인할 때 " " 안에 빈문자열이 여러개 들었을때는 어떻게 할 것 인지? - replaceAll() 등의 메소드로 공백을 다 제거한 후 유효성 검사
3. totalcount 와 같은 변수명 규칙을 실수로 어긴 경우 << totalCount 를 찾아도 없기에 시간 잡아 먹을 수 있음..
5. 느낀점
- JDBC사용으로 느낀점은 어쩔 수 없는 중복 코드가 많아지고 길어진다는 점.
또한 동적인 sql문을 적용 시킬 때 문법적 오류를 찾아내는데 시간을 잡아먹는다.
- model1 아키텍처 사용과 과도한 분리를 통해 얻은 내용으로는 model1 아키텍처는 유지보수성이 심하게 떨어지고 과도한 분리를 해서 얻은 내용은 구조가 복잡해지면서 흐름에 대한 이해를 해친다. 적당하게 심플한 것이 좋다.
- 코드 리뷰를 통해 느낀점:
- java언어의 기본 라이브러리를 잘 사용하고 효율적인 코드작성을 위해 알고리즘 공부해야한다.
- 항상 다양한 사용자들의 의외의 상황을 대비한 방어코드를 작성해야한다.
