[개발일지] - 491

응집도 Cohesion 좋은 코드와 좋은 설계의 시작 포인트 서로 밀접하게 연관 있는 속성(data)과 행동(method)이 함께 뭉쳐(모듈, 클래스, 함수)있는 정도

좋은 설계 - loose coupling, high cohesion 나쁜 설계 - high coupling, low cohesion

다른 클래스/모듈의 변화에 크게 영향을 받지 않는다.

함수 하나당, 한가지 일을 하도록 하자 모듈/클래스 하나당, 하나의 책임/도메인을 가지도록 하자

---

함수가 내부에 있을 필요가 없는 독립적인 기능인 경우 외부로 빼서 재사용이 가능하게 한다

key, value가 같으면 {} 내부 할당 시 이름 부여를 생략할 수 있어서 통일하는 편이 좋다. {time : totalTime} -> {time}

if문 내부에서 짧은 조건이 따로 있는 경우 early return을 사용해준다

---

응집도에 맞지 않아보이는 변수는 맞는 다른 클래스로 옮겨준다

---

매개변수로 넘겨줄 때 p 같이 무의미한 내용이 아니고 photo처럼 의미있게 사용하기

문장은 호출되는 곳으로 옮겨주기

<div> a + call(b,c) </div>

=> <div> call(a,b,c) </div>

---

for문 순회에서 절차지향인 경우 includes를 사용하는 것 처럼 메서드 존재 여부 확인하기

좋은개발자 1.툴을 잘 사용(어떤 익스텐션이 있는지 등) 2.Platform, library, api, 함수 등을 잘 아는 사람

---

아래처럼 순차적으로 적용되거나 연관된 경우 순서를 가깝게 해주기 a b c = a+ @ d

=>

a c = a+@ b d

조건문 내부 실행이 단항인 경우 삼항연산자로 대체하기

---

반복문 내부 작업이 많거나 관련이 없는 경우 for문 등을 나눠서 n번 순회하게 하고 성능이 걱정될 경우 완성된 이후 성능 개선을 진행해라

성능 < 가독성, 유지보수성

함수 호이스팅이 되기 떄문에 결과값은 return을 맨 위로 끌어서 보여주면 가독성이 올라간다.

최소값, 합 등은 Math.min, reduce 등 메서드를 사용해주면 가독성이 오른다.

---

splice(1)을 사용하면 첫번째 줄 제거

중첩 반복문으로 처리하는 것이 아니고 메서드들(map, reduce, filter, splice 등)을 사용해서 처리하기

---

데이터 조직화 Organiziong Data (높은 가독성, 유지보수성)

변해야 할 이유가 없는 값들은 let이 아니라 const를 사용해줘야 한다

두번만 사용해야 하는 등의 특정 조건이 있는 상수에 가까운 값의 경우 let 을 사용해서 값을 한번 더 계산하는 것이 아니라 상수로 두개로 쪼개서 의미있는 이름 부여로 사용하기

매개변수값을 직접 조작하지 말고 result같은 값에 적용해서 변경 후 출력하는 방식으로 해야 한다.

---

rename symbol 등을 사용해서 한번에 변수값을 변경하기

모호한 이름을 명확한 이름으로 바꾸는 것이 중요

---

set 등에서 결과값에 영향을 주지 말고 변경된 데이터만 관리하게 한 다음 해당 결과값이 필요한 시점에 해당 연산을 통해 실시간 값을 전달해주기

---

value -> 불변 참조 -> 가변

참조가 아니라 .toString 등으로 값으로 변환되게 전달

set에서 하나씩 변경할 경우 값만 바꾸는 방식이 아니라 constructor를 새로 호출해서 새로 지정된 값을 넣어 만들면 불변성이 유지될 수 있다. (set으로만 새로 변경시키고 reference를 통한 변경이 불가능해지기 때문에) a.setXX(3) => 가능 a.xx = 3 => 불가능

---

여러 곳에서 동시에 조회, 수정이 필요한 경우 값에 의한 전달이 아니라 참조값을 전달해서 사용 권장

repository pattern을 사용?? class 내부에 Map을 생성해주고 customerRepository.registerCustomer(data.Id) 형태로 조회

인스턴스 내부에서 map class같은 무거운 내용에 접근하는 것이 아니라 인스턴스를 호출할 때 repository를 미리 호출해서 값을 전달하는 방식을 추천

const order = new Order(data.number, customerRepository.registerCustomer(data.customerId);

---

9.81 같은 아무 의미도 없어 보이는 값을 즉각 사용하는게 아니라 const STANDARD_GRAVITY = 9.81로 의미를 부여하고 해당 상수를 넣어 가독성을 올려줘야 한다.

 

 

리팩토링 스터디에 참여해서 위 내용과 같은 정리를 했고

요청에 따라 외화가 원화로 변경되어 들어올 때는 세금을 계산하지 않는 로직을 적용해야 했는데

세금 계산 공식에서 통화가 KRW인 경우 1, 아닌 경우 0을 곱하도록 해서 세금을 없애줄 수 있었다.

 

어제 답변하지 않았던 총 합계 금액 불일치에 대해서 정리한 내용과

세금 처리된 내용에 대해 고객사에 전달해준 다음 중간에 질문이 들어와서 해당 내용을 답변했다.

 

샘플 → 주문 → 주문 제품 → X개체 형태로 연결되고 있는데

X개체의 특정 필드값을 샘플에서 확인하고 싶다는 이상한 요구사항이었다.

 

Document에서는 처리가 불가능하기 때문에 넘어가려고 했는데

이론적으로 생각해보면 x개체의 제품이 업데이트 될 때 X 개체의 값을 샘플에 업데이트 하는 방식으로

트리거를 걸면 가능하긴 하지만 비효율적인 방식이 떠올랐고

일단 방법은 찾았기 때문에 고객사에게 선택하게 하시는게 좋을 것 같다고 마무리했다.

 

SAP 인터페이스는 또 에러가 발생했지만

자연스럽게 로그를 확인하고 발송 테스트를 하니 500 서버에러라서 바로 고객사에 전달했고

특정 기준일의 before date 관리 부분에 대해서 고객사에서 처리 방법을 골라주셨는데

변경x, 적당히 납득가게 변경, 철저하게 변경 3가지 선택지를 드렸지만

그냥 철저하게 변경하는 방식만 제시하려다가 선택지를 드리니 오히려 2번을 골라주셨고

3번의 경우 10시간은 걸릴 것 같지만 2번은 1시간이면 해결할 수 있는 방법이라 바로 처리했다.

 

Case 생성 조회 관련 문의가 들어왔는데

간단히 권한 문제인데 일반 유저도 볼 수 있게 OwnerId를 어떻게 전달해드릴지 문의했고

편하게 관리할 수 있도록 사용자 정의 설정으로 넣어서 처리했지만

개발서버에서는 등록이 됐는데 운영에는 되지 않았고

DML에서 처리하려고 이런저런 방법을 사용했지만 할당 규칙 문제가 있었다.

 

한참 헤메다가 할당 규칙 최하단 조건을 추가해서

true = true, 사용자 재할당 없음으로 처리하니 정상 처리됐는데

조금 더 명확하게 알 수 있으면 좋겠다는 생각도 들고

이런 숨은 기능들이 개발자와 어드민 사이에 소통이 없으면 복구가 어려울 수 있곘다는 생각도 들었다.

 

다른 회사 추가 인터페이스 관련 필드를 추가하다가 마무리하고 병문안을 출발했다.

 

 

(1).백준 28691번 정보보호학부 동아리 소개는 해당하는 동아리 키를 적으면 이름을 출력해야 하는 문제였는데

map에 담아준다음 해당 글자를 넣어 출력하는 방식으로 해결했다.

const input = `W`
const map = {'M' : 'MatKor', 'W' : 'WiCys', 'C' : 'CyKor', 'A' : 'AlKor', '$' : '$clear'}

console.log(map[input])