[개발일지] - 657

요청사항 관련해서 또 공식문서를 봐야 했는데

고객사나 고객 협력사가 아니라 왜 우리쪽에서 다우오피스 공식문서를 보면서

다우오피스 api를 확인해야 하는지는 계속 의문이긴 하지만 일단 요청 필드를 찾아서 문의했다.

 

문서번호 관련 추가 로직은 생성했지만

callback 관련 프로세스 등 생성한지 8~9개월이 된 코드라 다시 로직 확인이 필요했고

생성된 로직에 맞는 필드를 운영, 개발서버에 추가해준 다음

기존에 고객사측에서 임의로 만든 필드를 제거했다.

 

고객사측에서 새로 담당으로 들어오신분이 필드 api명칭까지 마구 변경하고 계시고

마음에 들지 않으면 상태값 등 순서 변경이나 삭제까지 하셔서

다른 로직들에서 마구 에러가 발생해서 문의가 어드민쪽으로 들어왔다가

추적해보니 기존 상태값을 띄워쓰기를 하거나 삭제한 부분 때문에(api를..) 발생한 것으로

나와 협의된 것인지 문의하러 오셔서 알게 됐다.

 

요청사항도 특이하고 까다로운게 너무 많은데

샘플쪽에 모든 정보가 모이게 해야 한다는 의견 같지만

출고 프로세스의 경우 여러가지 판매주문에서 제품들을 대충 소량씩이라도 모을 수 있고

모인제품들을 출고하고 납품하는 프로세스인데

100개의 제품이 있는 샘플 개체에서 만든 주문 중

단 하나의 판매 제품을 여러개의 판매에서 가져온 출고가 진행된 경우

이걸 출고가 진행됐다고 해야 하는지 아니면 출고 대기인건지 아니면 상태 미변경인건지도 의문이고

하나가 납품 됐다고 납품 처리를 해야 하는건지

아니면 다른 모든 제품이 납품 되는 시점에 납품 처리를 해야 하는건지

딱 하나라도 단종 등의 이슈로 납품이 되지 않으면 평생 납품처리가 안되는건지 이해도 잘 안되고

샘플에 처리를 하려면 결국 실시간으로 하기 위해 트리거로 체크해줘야 하고

하위 제품들마다 상태값 변경 후 최종적으로 다 패스가 되면 납품으로 변경해야 할 것 같은데

이런식으로 하위 제품 하나마다 상위로 넘어갔다 하위 전체 체크로 가면 그 부분 시스템 부하도 클 것 같았다.

 

특이사항들에 대해 정리해서 문의했지만 오후 반차신지 자리비움상태셨고

샘플 관련 필드 수정과 추가된 필드 및 로직을 나중에 매뉴얼 작성용 메모 노트에 추가해둔 다음 마무리했다.

 

 

(1).백준 16032번 Income Inequality는 평균의 함정에 대한 문제로

평균보다 적은 값을 가진 수치가 몇개인지를 묻는 문제였다.

 

여기서 특이한건 '이하'기 때문에 평균과 같으면 전체가 포함되는 구조였는데

평균의 함정으로 평균보다 낮은 사람이 많다고 하면서 미만이 아닌 이하를 사용해서

오히려 정말로 평등하게 평균이 잡혀버리면 모두가 평균 '이하'가 되어 높은 수치가 나오는게 답답했다.

 

어쨌거나 총 합과 개수를 구해줬는데 

사실 length를 사용하면 count를 적을 필요는 없긴 하고

평균의 경우에도 각각의 filter 내부에서 연산되지 않게 미리 연산하는게 좋아보이긴 했는데

의식의 흐름대로 풀다보니 저렇게 되어버렸다.

const input = `7
15 15 15 15 15 15 15
4
10 20 30 60
10
1 1 1 1 1 1 1 1 1 100
7
90 90 90 90 90 90 10
7
2 7 1 8 2 8 4
0`.split('\n').map(el => el.split(' ').map(Number))

const result = []

for(let i = 1; i < input.length ; i+=2){
    let count = 0
    let total = 0
    for(let j = 0 ; j < input[i].length ; j++){
        count++
        total += input[i][j]
    }
    result.push(input[i].filter(el => el <= (total / count)).length)
}

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