static에 대해
자주쓰이는 메서드들을static으로 처리하는 것이 좋을지 몰라서 튜터님께 질문 드리러 갔다. 내가 질문 했던 것은 이것.
public Topster getTopster(Long topsterId){
log.info("topsterId :" + topsterId +"로 topster 조회 시작");
Optional<Topster> optionalTopster = topsterRepository.findById(topsterId);
if(optionalTopster.isPresent()){
return optionalTopster.get();
}else {
log.error(NOT_EXIST_TOPSTER.getMessage());
throw new ServiceException(NOT_EXIST_TOPSTER);
}
}이렇게 다른 도메인에서도 자주 쓰이는 getEntity()메서드들은 static 메서드로 만들어서 사용하는게 좋지 않을까? 그렇게 사용하면 각 도메인에 field들이 줄어 들 수 있으니 더 편할 것이라고 생각했다.
예를 들어 LikeService에서 굳이 TopsterService를 filed값으로 가져야 할까?가 의문.튜터님께 질문을 드리러 갔는데 튜터님이 살짝 작은 한숨부터 쉬셨다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 이건 스프링의 근간을 흔드는 방식이다.
스프링에서는 Service를 Bean으로 등록해서 사용하는데, static을 사용하면 빈으로 등록을 안하니까 라이프 사이클도 문제가 생기고 몇가지 더 말씀 해주셨는데 아직 완전히 이해는 못했다. 다싣 한번 static의 장단에 대해 공부를 해야할 시간이 왔다. 그리고 static이 필요한 경우도 분명 있다고 하셨다. 바로 util클래스 같이 클래스 안의 메소드를 도구처럼 꺼내 쓸 때는 static이 좋다고 하셨다. 생각해보니까 우리 프로젝트에서도 StringHelper같은 유틸 클래스를 만들어서 사용하면 좋지 않을까 생각이 든다. 쿼리를 날릴 때 String을 좀 만져서 쿼리를 날려야하는 경우가 있다.(첫글자를 대문자로) 또 응답 받은 String을 Substring/split을 해줘야 하는데 이를 StringHelper클래스로 처리를 하는게 더 좋을까? 생각도 좀 든다.
튜터님 피드백을 받고 기술 스택을 더 추가하면 좋겠다는 말씀에 추가 기능을 구현하기로 했다.
그 중 내가 맡은 역할은 캐싱 기능 추가! 예전에도 우리가 고려했던 사항인데 이걸 캐싱으로 처리하면 될듯하다. 외부 API에 요청을 보내면 지금과 달리 실제 비즈니스에서는 비용이 청구 된다고 한다. 따라서 데이터를 캐싱하면 비용적으로도 속도 적으로도 더 좋을 것 같아서 캐싱을 하기로 했다. 우선 redis를 이용한 캐싱을 하기로 했다. redis 환경을 구축 해놓으면 refresh token도 사용이 가능해지기 때문에 프로젝트 완성도가 높아질 것 같음!
그리고 마지막으로 경남님과 프론트쪽 같이 연동을 해보다가 npm명령어가 먹히지 않는 오류가 있었다. powershell에서 npm install 명령어를 입력하고, npm install axios -> npm instal -g@vue/cli 를 하는 등 node.js를 설치했지만 npm이 왜안되는지 이유를 몰랐다. 그래서 일단 에라 모르겠다 재부팅을 했더니 바로 됐다 ㅋㅋ 우선 오늘 밤이 늦었기 때문에 경남님은 들어가셨고 프론트 서버와 우리의 백엔드 서버를 연동 시켜 보고 자야겠다.
