Happy Programmer

오늘은 출근 시작부터 황당했는데

엘레베이터에 개똥이 자주 발견된다는 공고를 볼 수 있었다.

발견된 곳의 CCTV를 확인해서 처벌을 하는게 아니라

이걸 전체 공지로 굳이 붙여주는 이유를 이해할 수 없었다.

분리수거장에 음식물쓰레기가 들어있는 것이나

엘레베이터 앞에 먹던 커피가 있는 것도 황당했는데

이제는 개똥이 자주 발견된다니 참 희안한 오피스텔이다.

출근하면서 근처에 있는 다른 정류장이 사라져서 그런지

사람이 너무 많아서 30명쯤 됐기 때문에 탈 수 있을지 걱정했는데

다행히 다른 버스를 타는 사람들이었고 우르르 빠져버렸다.

동일한 시간대에 출근하지만

교통 상황에 따라 앞뒤로 조금씩 차이는 있는 것 같다.

오전에는 마스터 디테일 관련 트리거들과

다른 트리거를 경유한 트리거를 위한 공용 함수로 변경 및

undelete에서 마스터 트리거에서 자식 트리거 호출 등 복잡한 코드를 작성했다.

점심은 오랬만에 햄버거를 먹고 싶다고 하시는 분이 계셔서

버거운녀석들에 가기로 했는데 안타깝게도 버거운녀석들은 사라지고 말았다.

결국 근처에 있는 바스버거에 갔는데

저번에 먹을 때 보다 가격이 15%가까이 상승한 것을 볼 수 있었다.

저번에는 바스버거에 세트로 주문했던 것 같지만

이번에는 치즈버거와 세트메뉴로 주문했는데

감자튀김도 이상한 와플프라이로 바꾸고 감자튀김 자체를 고를 수 없어서 별로였다.

치즈버거의 빵 또한 모닝빵을 사용한 것 마냥 잘린게 아니라 칼질을 좀 하고 그 내부에 재료를 넣는 방식이었는데

그래도 맛은 나쁘지 않았고 와플프라이도 튀김의 바삭함은 없었지만 나쁘지는 않았다.

감자칩과 유사한 튀긴감자는 마음껏 가져다 먹을 수 있었는데

맛은 나쁘지 않지만 너무 단단해서 몇개 먹고 말았다.

확실히 100%소고기 패티라서 그런지 패티 자체는 다른 곳 보다 더 맛있었는데

빵이 애매하고 와플프라이도 햄버거와 먹는 그 감자튀김이 아니라 어울리지 않아서 더 아쉬웠다.

4월25일에 왔을 때 찍은 사진에는 분명 감자튀김이었는데

왜 선택이 아니라 와플프라이 단일로 변경한건지는 이해가 되지 않았다.

오후에는 트리거도 신나게 잘 해결할 수 있었고

예전에도 동일한 문제가 발생했었다는 Validation 문제도 생각대로 해결할 수 있어서 기분이 좋았다.

중간중간 다른 쪽에서 에러가 발생해서 이슈를 작성하느라 시간을 좀 쓰긴 했는데

해당 부분의 문제라기보다는 타임아웃 설정이 되지 않아서 에러가 출력된 것이었고

빠르게 해당 부분을 파악해주셔서 해당 문제를 해결할 수 있었다.

내일은 이제 완성된 내용을 테스트하기 위한 시나리오를 작성하고

해당 부분들을 시연해볼 것 같은데

빠르게 해당 부분을 처리하고 다른 프로젝트의 인터페이스도 진행해야겠다.

오늘도 50분 이상 걸었다.

차고지에서 나오는 버스에는 아무도 탑승하고 있지 않아서 오늘도 편하게 갈 수 있었는데

이 시간대가 제일 편하게 갈 수 있는 시간인 것 같다.

회사에 도착하자마자 트리거를 진행하려고 하다가

플로우로 처리가 가능하면 테스트코드를 작성하지 않아도 되기 때문에

플로우로 처리하려고 시도했다.

하지만 플로우는 성능이 엄청 떨어지기 때문에

지원하지 않는 기능도 지원하는 척 하면서 사용자를 기만하는 것을 즐겼고

지원하는 척 하는 기능을 작동하는 코드로 변경했으나 몇분도 지속되지 않고 플로우 자체에서

저장된 플로우 내부 설정값을 잊어버렸다면서 자꾸 재입력을 하라는 어처구니 없는 요구를 반복해서 했다.

결국 플로우를 버리고 트리거를 작성하는 것으로 넘어갔는데

확실히 내가 짜고 내가 디버깅을 제대로 할 수 있는 apex 코드가 신뢰할 수 있는 것 같다.

점심은 놀부부대찌개를 먹으러 갔는데

단품으로 옛날부대찌개 3개를 주문한다고 했음에도 불구하고

세트로 구매하면 6천원밖에 더 안비싼데 중앙에 보이는 사리와 음료까지 무료라고 거짓말을 하면서 판매했다.

하지만 실제로는 7500원이 차이나는데 직원이 금액을 모를리도 없고

왜 금액을 속여가면서 판매하는지 이해가 되지 않아서 많이 황당했다.

사리 또한 원하는 단품종 사리를 시킨 것만 못한 수준이었는데

음료를 각 2천원이라고 쳐줘도 저 접시 하나에 3500원이라는 말이기 때문에 비싸다고 생각된다.

(라면사리를 제외한 이유는 밥과 라면사리는 중앙에서 무료로 가져다 먹을 수 있기 때문)

다 같이 먹어서 재미있게 먹을 수는 있었지만

동기분과 같이 갔던 킹콩부대찌개가 훨씬 더 좋았던 것 같아서

다음에 굳이 부대찌개를 먹을 일이 있어도 여기를 고르지는 않을 것 같다.

오후에는 회의를 진행하고 트리거를 계속 진행했는데

그놈의 플로우가 뭔가 문제를 발생시킨건지 한달가까이 잘 작동하던 플로우에서

트리거와 충돌이 난 것 같았다.

트리거만 작동시키거나 플로우만 작동시키는 것은 정상 작동했는데

사실 회의 때 시연까지 했을 정도로 트리거, 플로우가 정상 작동했는데

누군가 작성한 플로우들이 우수수 작동하면서 뭔가 영향을 미친건지

update 작업을 시켰는데 필수 필드값이 빠졌다고 자꾸 우기는 에러 메세지만 출력되었다.

회사분이 봐주셨는데

처음에는 내 실수를 살짝 의심하신 것 같지만

30분이 지나고 1시간이 지나도 도저히 원인을 찾을 수 없어서

2시간 넘게 보시더니 결국 포기하셨다.

이걸 보면서 트리거 플로우 사용을 더 자제해야겠다는 생각을 하게 되었는데

트리거로 작성하고 각 트리거에 작동될 클래스를 따로 작성한 다음

그 클래스 내부에서 해당되는 작업 내부에 작동할 함수들을 따로 만들어서 넣어두면

서로 충돌이 일어날 여지도 적고 충돌이 일어나도 바로 옆 코드를 볼 수 있지만

플로우는 코드로 작성된 것도 아니기 때문에 하나하나 뜯어 보기도 쉽지 않고

수량이 쌓이면 정말 대책없는 것 같다.

오늘은 이전한 회사에서 처음으로 마지막으로 퇴근을 했는데

요즘 회고를 조금 더 신경써서 작성하다보니 수면 시간이 줄어버려서

상당히 피곤한 상태다.

그래도 오늘 점심 이후쯤까지만 해도 신나게 설계하며 시간이 잘 갔는데

누가 봐도 잘 작성한 코드고 각자 에러가 없는데

내가 작성하지 않은 코드의 원인으로 인해 충돌이 발생해서 터지는건 많이 답답하고 피곤하다.

내 코드도 누군가에게 이런 영향을 줄 수 있다는 생각을 하고

조금 더 결합도는 낮추고 응집도는 높힐 수 있게 주의하며 작성해야겠다.

퇴근은 결국 7시가 넘어서 할 수 밖에 없었는데

퇴근 시간이 더 늦어져도 5시 40분의 쾌적한 버스환경과는 다르게 서서 퇴근해야 했고

버스 대기시간도 길어서 더더욱 피곤했다.

거기다 자리가 안좋은게

이전한 후 늦게까지 근무한적이 없어서 몰랐는데

저녁시간대가 되면 태양이 정면에 나타나기 때문에

햇빛 때문에 모니터가 잘 보이지 않으며 눈에 부담이 많이 간다.

내일부터는 되도록 5시 40분 이전에 퇴근할 수 있도록 해야겠다.

오늘도 30분 이상 걸었다.

트리거 플로우를 진행했으나 관련 필드 레코드 업데이트가 있음에도 불구하고

__r로 연관된 플로우를 생성하면 1~2분 정도 정상 작동하다가 플로우 자체가 터져버렸다.

기능이 터지는게 아니라 플로우 내부에 입력된 값을 지 멋대로 날려버리고 빨간줄이 뜨며 유효하지 않은 값이라고 하는데

이럴거면 왜 연관된 레코드 업데이트를 만들었는지 이해가 되지 않았다.

해당 문제를 해결하기 위해 2시간 가량 시간을 소비하다가 포기하고 트리거로 넘어갔다.

트리거로 대체하기위해서 코드를 작성했는데

해당 트리거가 insert, update, delete까지 순차적으로 모두 완료되었는데

insert를 하는 부분과 플로우 처리가 동작을 하던 도중 갑자기 충돌이 일어난 것 처럼 터져버리더니

그 뒤로는 "업데이트"를 하는데 필수 필드를 넣지 않았다면서 억지로 에러를 발생시켰다.

업데이트에 왜 필수 필드가 있는지도 모르겠고

업데이트 DML 요청 직전에 debug를 찍어도 모든 값이 제대로 들어있는데

도대체 왜 이러는지 모르겠다.

플로우가 아닌 다른 경로로 insert를 할 경우 무난하게 트리거가 작동하고

insert 내부 update dml을 주석처리해도 플로우가 무난하게 작동하였으며

그 전 이미 insert, update, delete 트리거가 모두 정상적으로 처리되었는데

갑자기 before insert가 터지는 이유도 모르겠고

after로 변경해도 터져서 포기하고 퇴근했다.

(1).백준 21185번 Some Sum은 지정된 갯수의 랜덤한 연속된 숫자의 합이 홀수인지 짝수인지를 구해야 하는 문제였다.

4개가 되면 그 이상으로는 의미가 없기 때문에 4개까지만 카운팅하는 배열을 만든 다음

초과되는 부분은 4로 나눠서 처리했다.

const input = 2
const result = ['Either', 'Odd', 'Either', 'Even']
console.log(result[(input-1)%4])

어제 진행하려는 트리거를 진행해야 하는 이유는 아래의 4가지 처리 과정의 문제가 있는데

1.출고요청시 해당 제품 출고요청됨 상태로 변경 ( 상태 = 포뮬러, 갯수로 처리)

2.출고 취소시 해당 제품 출고요청됨 취소

3.출고 완료됨 삭제시?

4.제품 일정 갯수 배송 희망시?

1번의 상태 직접 변경 불가, 2~3번의 삭제시 어떤 기준을 세우는지

특히 출고 완료된 출고 관련 레코드를 지울 경우 해당 차일드 레코드도 지워지는데

해당 레코드들이 삭제된 후 트리거가 자동 발동해서 미배송 상태로 가는게 맞는지

아니면 출고완료 상태가 되면 삭제가 금지되는지?

출고처리를 위해서는 계약 갯수와 배송요청됨 갯수가 일치해야 하는데

일일히 해당 수치를 추가하며 진행해야 하는지? 아니면 그냥 완료처리에 필요한 값을 넣는지

특히 세개의 빌더 중 2개는 갯수 선택 미지원이기 때문에 더 좋은 기능인 갯수 입력으로 가기가 애매한 상황이었다.

마스터 디테일 두개를 하나에 엮은 경우 자식 삭제 불가능하지만

마스터 디테일을 통해 롤업 기능이 가능하다고 해서 롤업에 대해 학습했다.

설계를 2시간 가량 진행한 다음 1시간 가량 회의 끝에 방향을 잡았지만

내용을 적용시키려고 보니 다른 데이터와 같이 있어서 마스터 디테일을 추가할 수 없었다.

(이미 부모 객체와 연결된 상태였고 자식이 두가지 타입에서 룩업관계였기 때문에 분리하지 않으면 마스터 두개가 불가능)

Validation rull을 설정했을 때 전체 페이지에서 한번에 수정하고 넘어가는 경우

현 재고와 수정 재고가 충돌하는 경우가 있는데 해당 부분도 이론적으로 해결할 수 있었고(내일 진행 예정)

9단계에 걸쳐 설계한 부분이 마스터-디테일을 생성할 수 없어 삐끗했지만

초코칩쿠키 하나를 먹고 금방 기운을 차린 다음 해당 부분을 트리거 플로우로 대체하는 설계로 대체했다.

내일은 실제 구현을 하고 오후에 회의를 진행할 예정이다.

(1).백준 11368번 A Serious Reading Problem은 문제의 설명만 보면 조합 같은데

테스트케이스를 보면 거듭제곱 횟수가 출력되는 모습을 볼 수 있었고

테스트케이스에 따라 거듭제곱을 시도하니 해결할 수 있었다.

const input = `4 2 2 2
4 3 2 2
0 0 0 0`.split('\n')

const result = []

for(let i = 0 ; i < input.length-1 ; i++){
    const [a,b,c,d] = input[i].split(' ').map(Number)
    result.push(((a**b)**c)**d)    
}
console.log(result.join('\n'))

결정이 필요한 부분들을 질문하면서 시연하려고 준비를 하고 있었는데

해당 부분을 진행하던 도중 미사용이라는 이름만 우수수 출력되는 걸 볼 수 있었다.

해당 문제는 flow에 필수적인 데이터인 Id만 쿼리해와서 에러를 제거하느라 발생했는데

Name 필드도 사용자 선택 부분에서 필요하다는 것을 잊어서 생긴 문제였다.

그런줄알고 확인했으나 어제 잘 작동하는 모습을 보고 종료했다는 것을 있었던 것이었고

들어가보니 이미 잘 처리했었다.

충격적이게도 문제가 자꾸 해결되지 않아 인스펙터로 쿼리해보니

해당 데이터들을 누가 사용자명을 다 미사용으로 바꿔서 생긴 문제였고

다른 계열로 조회하니 정상적으로 이름이 출력되었다.

질문지를 정리한 다음 시연 확인까지 하고 질문을 드렸고

아래와 같은 결론이 나왔다.

1.요청 3개 중 2개는 처리 1개는 문의

2.레코드 이동은 사용자가 이해하기 어려우니 화면 명을 명확하게 하기

(세부 내용은 보안에 걸릴 수 있어서 생략했다)

현재고를 넘겨주기 위해서는 상당히 어려울 것이라고 생각헀는데

필드를 만들고 해당 부분에 값을 넘겨주며 넘어가다보니

관련 필드를 이미 생성해뒀고 값도 이미 다 넣어뒀던 것을 발견할 수 있었다.

결국 해당 필드를 삭제하고 해당 값을 찾아 정리하고

팀에 다시 해당 필드를 삭제했음을 안내하고 필드 추가부분을 마무리하고 인터페이스에 들어갔다.

기존 프로그램들에서 처리하던 현재고 부분을 확인하고

필드 3개를 인터페이스로 넘기는 작업을 처리한 다음 메일로 답신을 보냈다.

레코드 이동 페이지 레이아웃의 수정이 필요했는데

값 입력만으로는 페이지를 바꾸기 애매한 감이 있었고

라디오로 선택이 가능하게 변경해봤지만

해당 값으로 결정이 제대로 진행되지 않아 원복시키고

대신에 섹션을 추가해 헤더 느낌을 추가해줬다.

판매 주문을 기준으로 판매 주문 제품들 각각의 배송처리를 진행할 때

모든 배송이 완료되면 각자 기록하다가

판매 주문의 모든 판매 주문 제품이 완료되는 경우 처리를 시작해야 한다고 생각했는데

알고보니 그냥 각각의 배송처리가 배송완료가 되는 순간 진행하는 방식이라고 하셨다.

사실 그건 그냥 인터페이스 처리시 자동으로 되는 부분이라 내가 건드릴 부분은 없었다.

객체의 필드들을 확인하며 트리거 구조까지 짠 다음 최종적으로 확인을 받았는데

만들지 않고 조금 더 자세하게 짜기 위해 질문을 해서 참 다행이었다.

계획한 일은 줄어들었지만 추가로 일이 더 쏟아졌는데

간단하게 조회 상태의 필드들을 추가 및 정리하라는 것부터

당장 필요없는 알림대상자가 정해지면 배송 완료시 대상자에게 알림이 가는 기능추가를 받았고

설계를 하는 동안 판매 주문 객체에서 배송요청됨, 배송완료 두가지 필드를 확인해버렸는데

해당 필드를 처리해주지 않으면 기존 주문에서 마구잡이로 중복해서 배송요청이 가능하기 때문에

배송요청을 처리해줘야 한다는 문제를 발견했다.

사실 그것만 따지면 조금 귀찮지만 빌더 3개와 플로우 하나만 바꾸면 되는 간단한 문제지만

배송을 하기 전 배송요청을 삭제하면 해당 아이템들을 다시 배송요청 안됨 상태로 변경해야 하고

그걸 위해서는 다시 트리거를 작성해야 했으며

조회시 출고요청이 없는 부분도 출고요청을 하도록 변경해야 했다.

생각해보면 트리거 연관 빌더로 작업할 경우 플로우에서 배송요청 처리가 가능하지만

다른 빌더에서는 플로우가 없어서 처리가 불가능하기 때문에 배송요청 또한 트리거로 해야 했다.

결론적으로 배송요청됨 필드를 통해 기존 출고요청 할 수 있는 데이터를 가져오게 3개의 빌더를 수정하고

배송요청품목 추가시 연관 판매주문품목의 배송처리됨을 처리하고

배송요청품목이 삭제될 경우 연관 판매주문품목의 배송처리됨을 취소해야 하지만

해당 배송요청이 완료된 상태에서 삭제될 경우는 미정인 상태이다.

정리하면 아래의 세가지 작업을 진행하면 되는 상황이다.

조회시 출고요청이 false인 값만 가져오기(builder 3개 처리)

출고요청품목 추가시 트리거 발동 및 OrderItem의 출고요청 필드 true로 변경

출고요청품목 삭제시 트리거 발동 및 OrderItem의 출고요청 필드 false로 변경

builder 부분을 모두 처리하고 트리거를 생성만 한 상태에서

이전에 해당 부분의 다른 기능용 트리거를 만든게 2주밖에 되지 않았지만 많이 수준이 낮아 보여서

결국 리팩토링을 진행하니 퇴근시간이 되어서 내일 트리거를 마무리하기로 했다.

(1).백준 8658번 Liczba는 약수가 아닌 가장 작은 수와 가장 큰 수를 출력해야 하는 문제였다.

보통은 소수구하기 느낌으로 진행하는데 이번에는 가장 작은 숫자부터 지정 숫자보다 작은 숫자까지 순회하며

나머지가 생기는 시점까지 진행하고 해당 i값을 min으로 저장하고

순서를 역순으로 진행해 나머지가 생긴 시점에 i를 max로 지정해 문제를 해결했다.

const input = 5

let min, max

for(let i = 2 ; i < input ; i++){
    if(input % i){
        min = i
        break
    }
}

for(let i = input-1 ; i > 1 ; i--){
    if(input % i){
        max = i
        break
    }
}

console.log(min, max)