[개발일지] - 160

두번째 프로젝트에서 온 요청사항 중

수정해야 하는 부분을 우선적으로 처리했고

인터페이스 전송 버튼 등 필수적인 부분도 먼저 처리 후 안내했다.

 

두번째 프로젝트는 일단 종료되었다고 선언된 상태긴 했고

요청사항들이 대부분 합의되지 않은 추가 편의기능들이 마구 오고 있는 상황이지만

첫번째 프로젝트는 실제 라이브 오픈이 일주일밖에 남지 않았기 때문에

이후 첫번쨰 프로젝트의 추가요청사항을 최우선 처리하기로 했다.

 

두번째 프로젝트에서는 공유할만한 정보는 없지만 특이한 부분은

Link를 이동할 때 주소값에 파라미터를 입력하는 방식으로 전달했었는데

?Id={!$[CurrentPage.parameters.Id](<http://currentpage.parameters.id/>)}

누군가 전달 방식을 변경해서

여기로 넘어오는 파라미터(id 값)가 변경된 상태였다.

 

그걸 모르고 여기서 전송하는 부분과 이동되는 페이지를 열심히 바꿔도 변경되지 않았는데

알고보니 이전에 설정해둔 전송될 sfdc의 레코드Id 값을

전혀 다른 개체의 Id를 덮어씌우는 방식으로 현재 페이지로 이동하기 바로 윗부분에 추가되어있었다.

 

해당 부분을 찾기 전에 이런저런 시도를 하면서 구조적으로 복습은 할 수 있었지만

주석도 없이 뜬금없는 다른 개체의 아이디를 동일 아이디에 왜 덮어씌웠는지는 의문이 들었다.

(예를 들어 Lead Id라 LId아이디를 넘겨줘야 했는데 뒤에 Account를 가져와 LId에 그대로 넣기)

 

자동화는 오늘도 작동하지 않았는데

도대체 원인이 뭔지는 모르겠지만 수동으로 작동시키니 정상 작동했다.

 

해당 부분을 오늘도 정리해서 전달했는데

해당 부분과 동일한 문제는 꾸준히 확인되고 있지만

다른 곳에서는 1%정도의 확률로 발생하는데

여기서만 높은 확률(50%이상)로 발생하고 있는 것 같다고 하시고

문제를 계속 확인하고 계신다는 답변을 주셔서 안심하고 첫번째 프로젝트 업무로 돌아갔다.

 

첫번째 프로젝트에서는 요청사항 7개가 더 들어와 있었는데

기능 구현을 우선하라고 하셨지만 요청사항의 권한 부분과 맞물린 부분이 있었기 때문에

결국은 요청사항을 먼저 진행했다.

 

대부분 큰 문제가 없는 요청사항이었거나

내가 담당하지 않는 부분이 있어서 전달했지만

심각해보이는 문제가 하나 발생했다.

 

일부 기능들만 사용할 것 같은 유저들은 Salseforce Platform License를 사용하는데

해당 사용자들은 Order, OrderItem 등 일부 개체에 대한 접근 설정자체가 불가능했다.

 

직접 만든 개체들과 기능만 사용해서 문제가 전혀 없었는데

추가 요청사항이 계속 쌓이면서 추가되었던 validation rule들에서 권한 문제가 발생해버렸다.

 

Validaion에서 Order 등을 타고 들어가서 상태를 비교하는 것으로

Rule 내부의 조건에 AND(!A,B,C) 형태로 기존 조건들 앞에 해당 프로필 사용자가 들어가게 했지만

!A가 발동했으면 B, C를 확인조차 안하는 코드와는 다르게

작동 이전의 필드 접근 권한 조회가 우선되어 버리는지 해당 필드에 엑세스 할 수 없다는 경고창이 계속 떴다.

 

그렇다고 이미 다 추가된 룰들을 제거하기에는 추가된 룰도 모두 요청사항이었기 떄문에

validation을 이리저리 바꿨지만 해당 문제를 처리할 수 있는 방법은 없었고

결국 Validation 내부에 들어가는 필드를 fomular를 사용해 가져온 다음

해당 유효성 검사 부분에 포뮬러 필드로 대체해서 문제를 해결했다.

 

경로설정 관련 내용도 나왔는데

해당 키워드를 떠올리기 힘들어서 상태값 등으로 검색했지만 마땅한 내용을 찾기 쉽지 않았다.

 

경로설정이라는 키워드로는 나도 찾기 힘들기 때문에 연상되는 단어들과 엮어야 할 것 같다.

(상태값, status, status progress, progress, 상태값 변경)

 

두번째 프로젝트 고객사에서 인터페이스 관련 문의를 하셨는데

자꾸 키가 아닌 값을 넣으려고 하셔서 왜 키를 사용해야 하는지 설명드렸는데

온라인으로 5번정도 안내를 드리고 예시와 postman 데이터와

실제 변경된 데이터와 적용 전 후 사진까지 모두 안내드렸지만

결국 유선상으로 안내를 드리고 key를 사용해 인터페이스를 해야 하는 것에 동의하셨다.

 

물론 key를 고객사 관리자들은 볼 수 없다고 하긴 하는데

그 부분은 ERP에서 필드 노출을 시켜줘야 하는게 맞다고 보고

해당 부분 떄문에 시간을 많이 소모해서 오늘도 저녁을 먹고 야근을 하기로 했다.

 

취소라는 기능 개발을 진행해야 했는데

상품이 취소되었지만 해당 제품은 돌아가야 한다는 가정이기 때문에

전달해야 하는 수량은 증가시켜야 하고

취소된 제품은 남아있으면서 업데이트, 삭제 등에도 수량에 영향이 가지 않아야 해서

trigger의 내부에도 해당 값을 조건처리해서 넣어줘야 했다.

 

점점 더 복잡해지는게

예전에 괜히 삭제 및 삭제 복구 등을 고려해서

복구 될 때는 값이 다시 줄어들게 만들었는데

해당 값도 수정되지 않게 하기 위해 insert trigger까지 관여해야 했고

수정, 삭제, 복구 등에도 안전한 취소 상태를 유지할 수 있었다.

 

하지만 해당 데이터가 사라지지 않는다는 가정 하에 작성했었기 때문에

Validation rule을 걸어주려고 했는데

취소여부를 rule 내부에 넣을 경우 변경 전에도 이미 변경하려고 하면 에러가 발생해서

취소 자체를 할 수 없는 문제가 발생했다.

 

이후 취소 한 다음에도 값이 변경되지 않는 등 이상한 일들이 너무 많아서

해결 방법을 찾던 중 validation rule을 위한 메서드가 상당히 많았기 때문에

아래와 같은 방식으로 규칙을 적용했다.

AND(
IsChanged(Status__c),  // 상태가 변경되었을 때만 적용
ISPICKVAL(Status__c, '취소'),  // 상태가 '취소'일 때만 적용
NOT(BooleanField)  // BooleanField가 False일 때만 허용
)

 

해당 방식으로는 수량 또는 비고 등을 변경하더라도 모두 적용되기 때문에

다시 update trigger 내부에 들어가 cancel 상태값이 변경되면서 취소인 경우에만 1회 적용되게 하고

취소 상태에 들어가면 취소 상태를 해제할 수 없게 만들었으며

취소 상태에 IsChanged로 추가적인 조건을 걸어 Quantity가 이전과 달라진 경우 에러를 발생시키는 조건을 추가했다.

 

해당 내용을 배포하고 나니 8시 50분쯤이었는데 추가기능과 요청사항은 끝났지만

두번쨰 프로젝트에서 추가로 요청온 부분들은 아직 하지 않아서 한구석이 찜찜하다.

 

 

(1).백준 13073번 Sums는 1부터 n개의 연속된 자연수의 합, 홀수의 합, 짝수의 합을 구하는 문제였다.

 

등차수열의 합은 간단한 공식이기 때문에

n(n+1)/2, n**2, n(n+1)로 처리해서 문제를 해결했다.

 

아래의 input만 봐도 한칸씩 증가할 경우 45도의 직각삼각형이 완성되는 것을 볼 수 있고

동일한 사이즈의 두개를 합치려면 가로 또는 세로가 +1이 되기 때문에 n(n+1)이 되고 2개의 합이니 2로 나누는 것이고

홀수의 합은 1, 3, 5, 7, 9등을 합치면 계속해서 정사각형이 되기 때문에 n*n이 되며

짝수는 2, 4, 6, 8 등으로 홀수의 합보다 1씩 크기 때문에 n을 추가한 n(n+1)이 되거나

아까 말한 삼각형이 두개라고 보면 되기 때문에 /2를 하지 않은 n(n+1)이라고 볼 수 있다.

 

const input = `4
1
11
111
1111`.split('\n').map(Number)

const result = []

for(let i = 1 ; i < input.length ; i++){
    result.push(`${(input[i] + 1) * input[i] / 2} ${input[i] * input[i]} ${input[i] * (input[i] + 1)}`)
}

console.log(result.join('\n'))