[개발일지] - 678

연차는 3일밖에 안썼지만 9일이나 쉬어서 그런지 업무가 많이 쌓인 것 같은 기분이었다.

 

오자마자 잔뜩 쌓인 알림과 DM 그리고 메일을 확인하면서

누적된 요청사항들을 하나씩 정리하고 있었는데

실시간으로 S사에서 요청사항 및 우선순위를 정리해서 요청했다.

 

그와 거의 동시에 어드민분이 오셔서 추가 전달사항을 알려주시고

요청사항을 같이 확인했는데 그 중 황당하게도 갑자기 다 고장나서 확인해보니 상태값이 없는게 많다는 일이 있었다.

 

무슨 소린지 확인해보니 다우오피스쪽에서 멋대로(?) 상태값들을 늘려놨는데

SFDC PickList에는 해당 값들이 존재하지 않기 때문에 이상한 값들이 넘어와서 에러가 발생했던 문제였다.

 

해당 상태값들을 개발서버에 추가해야 한다는 내용은 기록만 해두고

바로 다른 내용들을 확인하는데 이상하게도 다우오피스 처리쪽 로직은 로그가 쌓이지 않아서 확인이 안됐다고 하는데

실제로 코드를 보니 대부분 주석처리가 되어있었다.

 

일단 다우오피스 상태 변경 안됨 관련 추가 문제의 경우에는

활성화 후 테스트까지 진행했던 기록이 있음에도 불구하고 비활성 상태라 다시 활성화 처리해줬고

공란 기재시 승인되는 문제가 발생했다고 하는데

페이지 레이아웃에서만 필수값이고 실제는 필수값이 아니라서 누구든 수정은 할 수 있었다는 내용을 전달했다.

 

사실 이 부분은 조금 애매한게 이미 수천건의 예전 데이터가 공란으로 되어있는데

이 부분들을 채우지 않고 그냥 필수값 지정을 해버릴 경우

다른 레코드와 연결돼서 수정이 되는 경우 에러가 발생할 수 밖에 없는데

그런 문제 떄문에 페이지 레이아웃에서만 필수값으로 지정된 것이 아닌가 의심됐고

해당 내용에 대해 고객사에 전달하니 내부 논의가 필요하다는 답변이 넘어왔다.

 

템플릿 관련 수정 요청사항들 중 바로 처리 가능한 부분은 수정 후 전달했지만

조금 당황스럽게도 조건에 따라 추가 여부를 결정해달라는 부분이 있는데

이건 내부 패키지인 Document Template에서 제공하지 않는 기능이기 때문에

내가 개인적으로 어떻게 처리할 수는 없는 문제였고

대신 해당 line에 값을 넣어두고 null인 경우 공란으로 넘어갈 수 있다고 했지만

그 부분에 대해서도 이유는 모르겠지만 논의가 필요하다는 답변이 넘어왔다.

 

실제로 다른 노출되는 필드 중 일부는 공란으로 보이는 것들이 종종 목격되는데

어떤 차이가 있는지는 모르겠지만 요청사항대로 처리하는게 가장 좋을 것 같아서 넘어갔다.

 

샘플 제품과 주문 제품을 연결해달라는 요청도 들었는데

SAP에서 마음대로 변경하고 쪼개고 지우고 난리 법석인 판매 주문 제품인데

이걸 계약(?) 초반에 샘플에서 설정한 값과 매칭이 될리가 없는데 이걸 해달라고 하신거라

불가능한 이유에 대해서 여러가지 예시를 들어서 전달드렸는데

꼭 필요한 기능이기 때문에 이 부분에 대해서는 유선상 논의가 필요하다고 답변이 넘어왔다.

 

반려 시 상태 변경에 대해서 SFDC 상태값도 변경해달라는 요청도 받았는데

사실 수정 자체는 그냥 다우오피스 상태가 변경될 떄 트리거를 통해 처리해도 되겠지만

단순히 그렇게 넘어갈 수 있는 문제가 아니고

다우오피스에서 반려 이후 어떻게 프로세스가 진행되느냐에 따라서

SFDC에서 다시 상태값을 변경할 수 있게 기존 확인 규칙을 수정해야 하는건지

아니면 id 또는 다우오피스 문서 번호 등이 새로 넘어오게 되는건지

로직에 큰 영향을 줄 수 있는 변화가 있어 보였기 때문에 이 부분은 내가 유선상 논의를 요청했다.

 

문서번호 기입 시 안내 메일이 가지 않는 문제가 있다고 하는데

막상 에러가 났다고 하는 것으로 추정되는 내용들에 관리자를 넣어두고

관리자가 대상자로 잘 메일이 수신된 것을 확인할 수 있었는데

결국 의심되는 것은 사용자의 메일이 Invalid 또는 스팸, 기타메세지함 등의 문제로 추정된다고 답변했다.

 

전체 요청사항과 추가 문의에 대해 정리해서 답변했고

L사 마이그레이션 데이터 관련 문의가 들어왔는데

누락될 리가 없는데 누락된 것 같은데 누락이 맞는지 확인을 해달라는 내용이라서

결국 마이그레이션 이전 데이터들을 다 뒤져봐야 했는데

한참 수백만건이라 수십개의 파일로 쪼개져서 잘 열리지도 않는 것들과 씨름하다가

RecordTypeId를 통해서 특정할 수 있다는걸 생각해내고

해당 내용을 찾아서 필드값들을 비교해보니

고객사측에서 그냥 연결된 것들을 다 날려버렸고

오픈인 4월 1일이 아닌 4월 중순에 비슷한 것들을 생성해둔 기록을 볼 수 있었다.

 

S사 추가 로직 확인과 실제 필수 값들에 대한 문의 답변과

전송 상태일 때 판매가 생성되지 않는 에러에 대해서 로직을 확인해보고

상태값들이 추가되었기 때문에 해당 버튼에 연계된 Flow 내부에서 하드코딩으로 비교하던 것이 있었기 때문에

고객사에 세부 변경 규칙에 대해 다시 문의한 다음 요청받은 내용일 때만 버튼이 작동하게 수정했다.

 

 

(1).백준 9243번 파일 완전 삭제는 n번 덮어씌워서 자료를 지우려는 시도를 할 때

제대로 처리했는지를 묻는 문제였지만

실제 조건이 너무 말도 안되게 그냥 0, 1만 교체하는 것이라 반복 시도는 아무 의미 없어 보였는데

일단 요청사항대로 짝수인 경우 동일한 값이 나오는지 비교 해줬고

홀수 횟수인 경우 다른 값들만 있는지 비교하는 방식으로 해결했다.

 

이진법인 경우 처리 방식이 여러개 있었던 것 같은데

다음에는 이진법 처리 기호를 사용해서 한번 풀어봐야겠다.

const input = `20
0001100011001010
0001000011000100`.split('\n')

let result = 'Deletion succeeded'
if(input[0] % 2){
    for(let i = 0 ; i < input[1].length ; i++){
        if(input[1][i] == input[2][i]){
            result = 'Deletion failed'
            break
        }
    }
}
else{
    for(let i = 0 ; i < input[1].length ; i++){
        if(input[1][i] != input[2][i]){
            result = 'Deletion failed'
            break
        }
    }
}

console.log(result)