일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Value too long for column
- 코루틴 컨텍스트
- 티스토리챌린지
- terminal
- k8s #kubernetes #쿠버네티스
- preemption #
- 자원부족
- mp4fpsmod
- pytest
- Spring Batch
- 헥사고날아키텍처 #육각형아키텍처 #유스케이스
- PytestPluginManager
- python
- VARCHAR (1)
- JanusWebRTCServer
- tolerated
- 개성국밥
- JanusGateway
- JanusWebRTCGateway
- table not found
- PersistenceContext
- 겨울 부산
- 오블완
- kotlin
- 달인막창
- 깡돼후
- vfr video
- taint
- 코루틴 빌더
- JanusWebRTC
목록개발/Refactoring (14)
너와 나의 스토리
클래스는 반드시 명확하게 추상화하고 소수의 주어진 역할만 처리해야 한다 * 추상화: 공통의 속성이나 기능을 묶는 것(클래스 정의) 배경 메서드와 데이터가 너무 많은 클래스는 이해하기가 쉽지 않으니 잘 살펴보고 적절하게 분리하는 것이 좋다. 일부 데이터와 메서드를 따로 묶을 수 있다면 어서 분리하라는 신호다. 함께 변경되는 일이 많거나 서로 의존하는 데이터들도 분리한다. 특정 데이터나 메서드 일부를 제거해도 다른 필드나 메서드들이 논리적으로 문제가 없다면 분리할 수 있다는 뜻이다. 절차 클래스의 역할을 분리할 방법을 정한다. 분리될 역할을 담당할 클래스를 새로 만든다 원래 클래스에 남은 역할과 클래스 이름이 어울리지 않는다면 적절히 바꾼다. 원래 클래스의 생성자에서 새로운 클래스의 인스턴스를 생성하여 필드..
단순한 출력 이상의 기능이 필요해지는 순간 그 데이터를 표현하는 전용 클래스를 정의하라 -> 나중에 특별한 동작이 필요해지면 이 클래스에 추가함으로써 점점 유용해진다. 절차 변수 캡슐화 단순한 값 클래스(value class) 만들기 생성자는 기존 값을 인수로 받아서 저장(setter), 이 값을 반환하는 getter 추가 정적 검사 값 클래스의 인스턴스를 새로 만들어서 필드에 저장하도록 setter를 수정 새로 만든 클래스의 getter를 호출한 결과를 반환하도록 getter 수정 테스트 함수 이름 바꾸기 리팩터링 예시: 레코드 구조에서 데이터를 읽어 들이는 단순한 주문(Order) 클래스 Before: Order 클래스의 우선순위(priority) 필드를 단순히 string 타입으로 사용 class ..
배경 여러 함수를 한데 묶는 이유 하나는 도출 로직이 중복되는 것을 피하기 위해서다. 이 리팩터링 대신 여러 함수를 "클래스로 묶기"로 처리해도 된다. 원본 데이터가 코드 안에서 갱신될 때 → 클래스로 묶기 원본 데이터가 수정되면 일관성이 깨지는 경우 → 변환 함수 사용 변환 함수로 묶으면 가공한 데이터를 새로운 레코드에 저장 const base(aReading) = {...} const taxableCharge(aReading) = {...} ▼ function enrichReading(aReading){ const result = _.cloneDeep(original); result.baseCharge = calculateBaseCharge(result); result.taxableCharge = M..
function amountInvoiced(startDate, endDate) {...} function amountEceived(startDate, endDate) {...} function amountOverdue(startDate, endDate) {...} function amountInvoiced(aDateRange) {...} function amountEceived(aDateRange) {...} function amountOverdue(aDateRange) {...} 데이터 항목 여러 개가 여러 함수에서 몰려다니는 경우를 자주 볼 수 있다. 이런 데이터 무리를 발견하면 데이터 구조 하나로 모아주면 좋다. 데이터 뭉치를 데이터 구조로 묶었을 때 장점 데이터 사이의 관계 명확 매개변수의 수가 ..
배경 예: 대여한 지 30일이 지났는지를 기준으로 지불 기한이 넘었는지를 판단하는 간단한 함수가 있다. 이 함수의 매개변수는 지불 객체가 적절할까, 아니면 마감일이 적절할까? 지불 객체로 설정하는 경우 이 함수는 지불 객체의 인터페이스와 결합돼버린다. 대신 지불이 제공하는 여러 속성에 쉽게 접근할 수 있어서 내부 로직이 복잡해지더라도 이 함수를 호출하는 코드를 일일이 찾아서 변경할 필요가 없다. 실질적으로 함수의 캡슐화 수준이 높아지는 것 지불 객체가 적절할지 마감일이 적절할지에 대한 문제의 정답은 없다. 그래서 "함수 선언 바꾸기" 리팩터링을 진행하며 코드를 개선해 나가야 한다. 함수 선언 바꾸기: 함수명 + 매개변수 수정 절차 간단한 절차 함수 선언과 호출문들을 단번에 고칠 수 있는 간단한 상황일 때..
함수를 인라인하는 상황 상황 1: 함수 본문이 이름만큼 명확한 경우 함수를 제거 불필요한 간접 호출은 거슬릴 뿐 함수 생성해서 간접 호출하던 것을 합치는 것 예: int rating(int cost) { return moreThanFiveCost(cost) ? 2 : 1; } boolean moreThanFiveCost(int cost) { return cost > 5; } 상황 2: 잘못 추출된 함수들도 다시 인라인한다. 잘못 추출된 함수들을 원래 함수로 합친 다음, 필요하면 원하는 형태로 다시 추출하는 것 상황 3: 간접 호출을 너무 과하게 쓴 코드도 흔한 인라인 대상이다 다른 함수로 단순히 위임하기만 하는 함수들이 너무 많아서 위임 관계가 복잡하게 얽혀 있으면 인라인 해버린다. 절차 다형 메서드(p..