물경력 확정인 회사특징을 보고
나는 어떻게 살아 왔나 하면서 그냥 리플 다는 식으로 써봤습니다.
폐쇠망이다.
-> 이건 비즈니스가 그렇다면 어쩔 수 없으므로 절싫중떠 한다.
실제로 탈출함.
VO를쓰고있으며 1개의VO를 여러 api의 요청,응답으로 돌려 쓰고있다.
-> VO를 쓰긴 한데 개인적으로는 대표적인 클래스명 하에 inner class로 관리한다
ex) StudentVO 안에 inner class 로 StudentInsertRequest 를 둔다던지
Map이 빠르다고 VO조차 안쓴다.
-> Map을 안 쓰진 않는데 개인적으로는 외부API 호출결과 받아올 때 정도, 그것도 문서화가 잘 되어 있는 외부API면 VO 쓰는듯
프로시저를 사용한다.
-> 있으면 웬만하면 걷어내고 자바 로직으로 이관
전자정부 프레임워크를 사용한다.
-> 안씀. 쓰면 탈출하자.
jsp와 제이쿼리를 사용한다.
-> 관리자 화면단은 타임리프로 변경했고, 제이쿼리는 뭐 타임리프 쓸거면 굳이 편한 도구 냅두고 다른 거 쓸 이유는 없어서 계속 제이쿼리 씀
jsp조차안쓰고 웹스퀘어,넥사크로 이런걸사용한다.
-> 안씀. 개발자 처음 시작할 때부터 이거 쓰는 회사는 요행히 비켜감.
모든메서드에서 예외던진다.
-> 이거는 할 말이 많긴 한데..ㅋㅋ
@ControllerAdvice가 있는 경우, 때에 따라선 메소드에서 예외를 그냥 던져야 하는 때가 있음.
언제는 레거시 코드 하나가 계속 응답 정상, 근데 결과값은 안 내려줌 해서 보니까 오류가 나고 있었고, 그냥 catch Exception 에 정상 응답만 찍도록 되어 있는 걸 봤음.
이런 건 예외 "처리" 라고 하지 않음. 예외 "방치" 임.
따라서 개발자라면 어떤 때 예외를 던져야 하고 어떤 때 예외를 잡아서 "처리" 해야 하는지 알아야 한다고 봄.
서비스단은 매퍼호출용일뿐 로직은 컨트롤러에서처리한다.
-> 진짜 많이 본 형태인데, 심한 경우는 아예 "서비스" 라는 클래스가 없는 경우도 있음.
이 경우 일단 서비스 클래스 만든 후 로직을 통으로 옮기고, 추후 기능별로 리팩토링함.
AI가 생겨서 이 부분은 편해졌음.
컨트롤러에 if ,else문이 덕지덕지되어있다
-> 내가 만드는 소스의 컨트롤러의 로직은 길어봐야 5줄 이내로 끝나고 대부분 1줄임. swagger나 파라미터 받는 부분이 길긴 하다.
위와같은 쌍팔년도 개발문화를 중요시하며 이래야 속도가 빠르다며 고집피우고 오히려 디버깅에서 삽질하게된다.
-> 위와 같이 리팩토링하고, 내가 옳다는 아집은 항상 버리려고 노력중
잘 살아왔는지, 아니면 “저새끼도 보니까 물경력이네” 인지 잘 모르겠네요.
옛날코드를 보고 살아서 그런지 서비스단 코드가 절차지향적으로 짜지는 것 같기는 한데..
