남의 코드를 폄하 하는건 좋은게 아니지만.. 그럼에도

1. DTO 대신 Map으로 데이터 주고받기

2. 하드코딩 관리

위의 두 가지 방식은 도저히 이해하기가 어렵습니다. 첫 번째는 Controller 단에서 데이터를 전부 Map으로 받고, 이를 그대로 Service 로직에 던지는 방식입니다.

단순히 관리해야 할 클래스 수가 줄어든다는 이유만으로는 납득하기 어렵습니다. Map<String, Object>로 받으면 처음부터 만든 개발자가 아닌 이상 대체 어떤 데이터가 넘어오는지 바로 파악하기 힘들 뿐더러, 특정 값의 누락 여부조차 확인하기 어렵습니다.

실제로 API를 호출하는 쪽에서는 해당 값을 보내지 않고 있는데, 백엔드 코드에서는 단순히 null로 받아 로직에서 제외만 해둔 상황이었습니다. API 명세서를 수정하면서 불필요한 값을 찾아내느라 한참이 걸렸네요.

두 번째는 하드코딩 관리입니다. 예를 들어 setType("01")과 같은 방식으로 코드를 관리하는 경우입니다.

이 "01"이 대체 무엇을 의미하는지 알 수가 없습니다. 그나마 주석이라도 있으면 다행이지만, 주석이 없으면 코드 여기저기를 뒤져보거나 프론트엔드 단의 로직까지 확인해야 합니다. (심지어 테이블에서 별도로 공통 코드를 관리하지도 않더군요.) 또한 delYN이라는 필드명에도 불구하고 Y/N 이외의 값을 넣을 거라면 명칭을 왜 이렇게 지었는지 의문입니다.

저는 이런 방식보다는 Enum 클래스로 관리하는 것이 타입 안정성 면에서나 코드 관리 효율 면에서 훨씬 뛰어나다고 생각합니다.

제가 시니어 급으로 코드를 엄청 잘 짜는 것도 아니고 히스토리를 다 아는 것도 아니지만, 그럼에도 이런 방식은 유지보수 측면에서 너무 비효율적이라는 생각이 듭니다.