1.
Holiday 서비스 어떻게 계산할꺼냐? → 내년 꺼 어떻게 들고 오냐
a.
면회 신청은 한 달 앞으로 가능한데, 12월 중순에는 1월 1일날 면회 신청을 할 수 없다.
2.
면회 신청 시 사용자 관점 편의 고려
3.
모델링할 때, 테이블 분리의 건
a.
User와 Manager
b.
Application 모델링 시 승인 여부와 reception 정보
c.
Holiday 정보와 부대별 공휴일 테이블
4.
인터셉터 추가 시 성능 고려
5.
통계 처리 관련 부분
a.
통계처리를 하는 책임이 지금 클라이언트에게 있다. 클라이언트가 updateStatistics를 호출해야 간다.
b.
이상한 책임 분배... 자동으로 되야하지 않을까?
6.
ProxyMode 사용한거 삭제... 토비의 스프링 읽다가 @SessionAttributes 사용한거 발견. 훨씬 간단한거 같다. 유지보수하는 사람이 어려울듯...
7.
시큐리티 코드에서 개선점
a.
권한이 하나 늘어날수록, 도메인이 추가될수록 인가 코드를 바꾸는 건 아닌거 같다. 이 때까지 기존에 비해서 안내 병사 권한이랑 단급 관리자 계정이 추가됬는데, 만약에 하나 더 추가되면 그 때부턴 너무 많아질거 같다.
b.
DB로 옮기는 방법이 있던데, 알아보고 그렇게 하는게 좋겠다.
c.
이렇게 되면 필터를 적절히 수정해서 Config를 하나로 만들 수 있다. 가독성을 높이자.
8.
DTO 처리와 Entity 관련된 부분
a.
DTO가 모든 레이어를 다 왔다 갔다 하고 있다. 별로 좋은 거 같지 않다. 계층별 의존성과 변경에 대한 파급력이 너무 높다.
b.
파일이랑 리팩토링한 게시판의 경우에는 JPA의 엔티티를 따와서 어느 정도 모방했는데 좋은지는 잘 모르겠다.
c.
마이바티스도 select할 때는 연관관계를 매핑할 수 있다!!
d.
ReqeustDto, Entity, ResponseDto이런 식으로
9.
mapper 인터페이스와 Optional
a.
mapper 인터페이스를 좀 단순하게
b.
지금은 매우 구체적인 상황별로 sql문이 있다. sql문이 너무 많아서 결국 이 비즈니스 로직을 다 보려면 sql문을 봐야할 정도다.
c.
후임자에게 넘겨줄 때도 그렇게 좋아보이지...
d.
후처리는 서비스단에서 최대한 하려고 하는데, api 콜하는 성능을 좀 보면서 하자
10.
테스트 추가
a.
파란불 들어오는게 피드백이 확실하더라.
b.
나중에라도 과감한 리팩토링을 할 수 있도록
11.
Exception 처리의 건 → 일일히 커스텀에서 ErrorCode를 사용하는 방향으로
a.
일단 Exception 처리를 좀 제대로
b.
Checked와 Unchecked 에러의 차이 인지하자
c.
스프링에서의 DataAcess 계층에서 던지는 DataAccessException = 런타임이다.
d.
ErrorCode를 기반으로 해서 적절한 에러를 적절한 시점에 처리
12.
JPA를 사용한 모델링
a.
과연 유지보수 할 수 있을까...
13.
REST API 설계
a.
이건 못할거 같긴 하다. 근데 이번에 HAETOS를 알게 되면서 HAETOS를 적용한 REST API를 짜면 좋을거 같다
14.
SOLID 원칙 및 디자인패턴 추가 적용하고 싶은 부분
a.
지금 면회 신청하는 부분을 고치고 싶다.
b.
게시판 다음으로 리팩토링 하고 싶은 부분이었는데 apply로직이 너무 길다.
c.
결국에 가만 보면, 사용자 정보랑 시간을 받아와서 해당 날짜에 가능한지 확인하고 결국 insert하는 로직이다.
d.
이것도 마찬가지로 게시판 처럼 리팩토링 할 수 있다.
e.
우선 User와 Application Reqeust를 받아서, User Entity, application Entity로 바꾼다.
f.
Application Service는 이를 받아서 로직을 수행한다.
g.
이 때 allowedPolicy라는 인터페이스와 isAllowed()라는 메소드를 만든다.
h.
하위로 abstract class로 BasicPolicy와 Corps Policy를 만든다.
i.
BasicPolicy는 공규에 적혀있는 것들, Corps Policy는 부대별 상이한 정책에 관한 것들이다.
j.
이 구현체들은 Command 패턴이다. 내부적으로 ConcreteCommand를 가지고 파라미터를 캡슐화한다.
k.
Basic Policy는 공휴일과 누구랑 면회하는지를 판단하는 구현체를 기본으로 가지고, Corps Policy는 부대 휴일과 사용 병사가 징계를 받았는지 등을 확인하는 구현체를 가진다.
l.
이 때 CorpsPolicy는 Basic Policy를 감쌀 수 있다. 그래서 데코레이터 패턴으로 연쇄적으로 확인 간으
m.
최종적으로 true가 나오면 해당 신청이 존재하는 신청인지 확인 후 insert
