TIL_210824

1. Facts(사실, 객관)

- 회사 상담신청에 따른 실적 처리 개발하기

2. Feelings(느낌, 주관)

-  회사 홈페이지에서 상담신청에 따라 해당 신청을 안내한 파트가 실적을 가져가도록 되어있는데, 하나의 파트가 전부 가져도록 하드코딩 되어있었습니다. 그래서 다른파트에서,, 우리가 안내한 고객들은 우리실적으로 db에 넣어줘!라는 요청이 왔습니다. 순간 이번 뿐만이 아니라 A,B,C 등 여러 파트가 요청해 올 것이라는 예감이 들었습니다. 따라서, 기존 코드를 유지보수하기 좋은 방향으로 수정해야함을 느꼈고 여러 전략들을 생각해봤습니다. 결론적으로 서비스로직 자체의 분기가 아니므로 DB를 활용해보기로 했습니다. 그렇다면, DB에서 어떤 부분이 가장 유의미한 차이가 있을까? 고민해보니 판매채널 칼럼이 가장 중요했습니다. 다른 칼럼은 어떤 값이 들어가더라도 판매채널이 구분되면 됩니다. 따라서, 새로운 파트가 요청할때마다 로직은 그대로 냅두고 DB 공통테이블에 원하는 판매채널을 등록해주면 해당 판매채널이 DB에 저장되도록 하였습니다. 

 

3. Findings (배운 점)

- 테이블 칼럼을 계층형으로 만들어 시-구 지역선택 및 그룹사-계열사 선택의 방법을 배웠다. 단순 2계층이라 단순하게 쿼리를 호출 할 수 있었다. 계층형으로 구성되는 데이터가 앞으로 계속 생긴다면 해당 테이블에 추가 할 것이고, 만약 3계층 이상 조회가 필요하다면 CONNECT BY 쿼리문도 고려할 수 있다.

 

나아가, 비슷한 유형의 데이터를 DB에 넣는 것이 아니라 ENUM에 저장하고, 스트림 전략을 사용하면 DB를 건드릴 일이 없기 때문에 좀 더 가볍게 처리할 수 있다.  하지만 시-구만큼 변경이 없는 데이터가 있을 수 있을까? 그 기준은 개발자의 몫이다..?

 

디자인패턴 중, 전략패턴을 공부하면서 상속대신 조합을 사용하라는 의미를 알 수 있었다. 이 내용은 effective java에서 봤던 내용인데 다시한번 정리를 하고 싶다. 이번 코드 개선에서 해당 패턴을 고려해보았는데, 로그인 리팩토링 할 때 다양한 로그인 방식을 분기하는 부분에서 적용할 예정이다. 

4. Affirmation (자기 선언)

나는 요청사항을 하드코딩으로 케이스를 나누는 것이 아니라 컴포넌트 단위로 구성하여 유지보수를 고려할 줄 아는 개발자다