본문 바로가기
반응형

분류 전체보기714

TIL_211210 1. Facts(사실, 객관) - 필터 CONTORLLER 리팩토링 - 필터 화면 조회 방식 개선 - 일시불 결제 오류부분 수정 - 프로젝트 AccountHistory 저장 오류 2. Feelings(느낌, 주관) 필터점검 요일과 배정기사님이 자동으로 매칭되지만, 언제든지 바뀔 수 있고 결국 고객과 상담후에 결정되기 때문에 마이페이지의 조회 정보를 고객이 오해하는 일이 생겼다. 따라서 날짜를 가리고 언제든지 변경이 될 수 있다는 문구를 추가했다. 이 과정에서 그동안 만들어졌던 코드를 리팩토링 했다. 수십개의 변수를 가진 VO로 DB조회를 하는데, 그 VO 안에는 막상 고객고유식별키밖에 없다. 따라서 조회조건에 따라, 또 반환조건에 따라 단순 문자열로 조회하거나 새로운 클래스를 만들어 불필요한 정보를 담지.. 2021. 12. 10.
TIL_211209 1. Facts(사실, 객관) - 일시불 환불 자동화 로직 완성(화면과 예외처리 추가 필요) - 프로젝트 BaseEntity로 자동 시간 생성, 수정 설정하기 2. Feelings(느낌, 주관) 일시불 환불 자동화코드를 완성했습니다. 내부 ERP 시스템 프로시져 실행, 프로젝트 내부 로그기록 남기기 및 새로운 환불 테이블 추가, 배송상태 취소완료로 만들기, 내부 ERP시스템에서 주문요청상태 주문취소로 만들고 상담결과 취소하기, 마지막으로 알림톡 전송하기의 과정을 거쳤습니다. 엄청나게 많은 과정을 하나하나씩 확인하고 만드느라 생각보다 시간이 오래 걸렸습니다. 최종적으로 실제 회계팀에서 어떻게 환불처리를 하는지 프로세스를 보고 코드에서 추가작업이 필요한지 확인해야합니다. 또한, 환불 취소 JSP 화면을 만들.. 2021. 12. 9.
TIL_211208 1. Facts(사실, 객관) - 일시불 환불 자동화 코드작성 2. Feelings(느낌, 주관) 일시불 환불 자동화를 본격적으로 시작했습니다. 내부 시스템은 프로시저로 정보 저장하기, 알림톡 메세지 전송 만들기, 기취소건 재요청 시, 에러메세지 만들기, 홈페이지 데이터에 저장하기를 했습니다. 단순히 홈페이지에서 환불만 하고 끝나면 굉장히 쉽게 코드를 만들 수 있지만 기간시스템에도 연동을 해야 하니 생각보다 고려해야할 사항이 너무 많았습니다. 추가적으로 배송정보 취소완료로 변경, 취소완료 화면 개발, 환불로그 테이블 생성, 승인결과에 환불결과 삽입 등의 과정이 있습니다. 단순히 결제취소 하나를 추가로 구현한다고 생각해서 만만하게 봤는데, 세세하게 살펴보니 고려해야할 사항이 너무 많았고 생각날때마다 기록하.. 2021. 12. 8.
TIL_211206 1. Facts(사실, 객관) - 일시불 결제 자동화 누락 부분 개선 - 프로젝트 스터디 서비스 테스트 개선 2. Feelings(느낌, 주관) 일시불 결제 자동화에서 누락된 부분을 찾고 개선했습니다. 단순히 홈페이지에서 일시불 결제가 되는 것이 아니라 내부 ERP와 연동되기 때문에 굉장히 까다로운 부분들이 많았습니다. 따라서 현업들이 진행하는 모든 ERP 시스템 과정의 DB 결과와 내가 자동화 한 DB결과를 비교했습니다. 비교 결과 수납처리가 완료되어야 정상이지만 완료되지 않았다는 사실을 발견했고, 자세히 보니 프로시져를 실행시켜야했는데 그 부분을 누락했었습니다. 그래서 다시 프로시져 실행부분을 확인하고 추가하여 정상적으로 자동화에 성공했습니다. 어떤 방법이든 돈과 관련된 부분이라 더욱 더 다양하게, .. 2021. 12. 7.
TIL_211205 1. Facts(사실, 객관) - 프로젝트 계정 서비스 테스트 개선 2. Feelings(느낌, 주관) 계정 생성 서비스 테스트를 개선했습니다. 기존에는 계정 조회 관련 서비스 테스트가 제대로 되지 않았던 부분들이 있었고 코드가 변경되면서 수정된 부분이 있었는데 반영했습니다. 특히, 업로드 사진이 있는 경우와 없는경우 테스트를 개선했습니다. 파일업로드의 경우 관련 dto를 만들어서 반환하도록 했습니다. 그전에는 기존에 도메인을 그냥 리턴했지만, 안전하게 처리하기 위해서입니다. 3. Findings (배운 점) 2021. 12. 6.
TIL_211203 1. Facts(사실, 객관) - 일시불 및 환불 나이스페이 구동방식 분석 - 프로젝트 계정관련 서비스 테스트 개선 완료 2. Feelings(느낌, 주관) 나이스페이 일시불 결제와 환불 API 문서 및 코드를 분석했습니다. 나이스페이 일시불 결제와 환불 프로세스의 큰 차이점은 결제의 경우 인증요청과 승인요청까지 총 2번이 있다는 것입니다. 인증요청은 고객이 입력한 값과 상점정보에 관여하고, 이후에 실제로 결제승인을 위한 요청을 합니다. 중간에 오류로 인해 취소가 될 수 있는데, 각 경우에 취소되었다는 API를 전송해서 환불을 받을 수 있어야 합니다. 환불 요청은 승인요청 1개만 있으며, 이전에 결제시 가지고 있던 정보로 요청을 합니다. 따라서, 승인요청 시 각 과정 결과값을 로그테이블에 남겨두어야 환불.. 2021. 12. 4.
TIL_211202 1. Facts(사실, 객관) - 토이프로젝트 파일업로드 테스트코드 작성 - 할인 설정 조직 선택 화면 설계 변경 2. Feelings(느낌, 주관) 일반적으로 Controller에서 POST 요청은 appilcation/json을 Content-Type으로 해서 Body에 내용을 담아 요청합니다. 하지만, 첨부파일의 경우 multipart/form-data Content-Type을 설정해서 보내는데, Body에 내용을 담지 않는다. 따라서, 계정 생성시, 이미지를 첨부하는 요청의 경우 어떻게 테스트해야할지 굉장히 난감하였습니다. 그러던 와중에, MockMultipartFile을 알게되었고 해당 방식으로 테스트를 진행하 수 있었다. 또한 응답body에서 또다른 객체 안에 있는 데이터를 어떻게 검색해야하나.. 2021. 12. 3.
TIL_211201 1. Facts(사실, 객관) - 주문 접수 자동화 (3/3) 완료 - code complete 4주차 스터디 2. Feelings(느낌, 주관) 크게 3부분으로 나누어졌던 주문 등록 과정을 모두 완성했습니다. 각 구간별로 테스트를 해보았고, 오류가 나는 데이터나 NULL값이 들어가는 경우 확인하여 수정했습니다. 사실, 기존에 있는 프로젝트에서 기능을 추가하는데 어려움이 있는데, 기존의 방식을 따라야 하고 비지니스를 분석해야 하기 때문입니다. 또한 결제 정보들의 많은 구분코드들이 들어가기 때문에 바로바로 값을 넣기가 쉽지 않았습니다. 하지만 정상적으로 완료 테스트를 거쳤고, 남은 기간에 걸쳐서 다시한번 테스트하고 확인하려고 합니다. 코드컴플리트2 스터디를 했습니다. 어떻게 변수명을 만들것인가?를 중심으로.. 2021. 12. 1.
TIL_211130 1. Facts(사실, 객관) - 주문 접수 자동화 (2/3) 완료 - 구글태그 스크립트추가 - 폐가전 제품 회수 내용 삭제 2. Feelings(느낌, 주관) 주문접수 자동화의 두번째를 완성했습니다. 먼저, 첫번째 과정을 다시한번 테스트하면서 중간에 데이터의 유실이나 잘못 넣은 것은 없는지 확인했습니다. 가끔 테스트를 하면서 당일에는 보이지 않던 것들이 여러번 반복하다보면 보이는 경우들이 있기 때문입니다. 또, 구글 태그 스크립트를 추가했는데, 홈페이지 유입을 데이터화해서 고객서비스에 대응하기 위해 현업에서 이용한다고 합니다. 단순하게 모든 페이지의 head와 body에 코드를 추가해서 끝냈습니다. 서비스팀에서 주문결제 시, 폐가전 제품 회수선택 여부를 빼달라는 요청을 했습니다. 문의하는 손님이 있는데.. 2021. 12. 1.
반응형