일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- MVVM
- 리펙터링
- HIG
- 클린 코드
- clean architecture
- UICollectionView
- rxswift
- SWIFT
- tableView
- Protocol
- ios
- uiscrollview
- combine
- Clean Code
- collectionview
- RxCocoa
- Xcode
- Human interface guide
- Observable
- 애니메이션
- swiftUI
- UITextView
- ribs
- uitableview
- map
- 리팩토링
- 리펙토링
- swift documentation
- 스위프트
- Refactoring
- Today
- Total
목록리펙토링 (45)
김종권의 iOS 앱 개발 알아가기
조건부 로직을 다형성으로 바꾸기 조건부 로직이 복잡해지면 수정하기가 굉장히 어려워지므로, 더 높은 수준의 개념인 다형성을 사용하여 조건들을 분리하는 방법 switch 문 안의 case가 여러개 있을 때 case별로 클래스를 하나씩 만들어서 공통 switch 로직의 중복을 제거하는 것이 목표 특히 switch case로 나누어진 분기 부분들에서 조건부 로직을 자신만의 방식으로 처리하도록 구성할 때, 다형성을 사용하여 각 클래스에서 처리하도록하면 SRP(Single Responsibility Principle) 원칙도 지키는 효과 조건부 로직을 다형성으로 바꾸기 예시 리펙토링 전) 사용자가 맥주를 고르고 이 맥주의 가격을 측정하는 프로그램 맥주의 종류는 enum으로 정의된 상태 각 맥주의 가격이 각각 다름 ..
중첩 조건문을 보호 구문으로 바꾸기 중첩 조건문이 많이 들어있는 케이스는 코딩을 하다보면 흔하게 발생하는데, 중첩이 되는 순간 깊이가 깊어지면서 읽기가 어려운 코드가 됨 if와 else 구문이 있을 때, if절과 else절은 똑같은 무게를 두어서 코드를 읽는 이에게 양 갈래가 똑같이 중요하다는 암시적인 의미를 전달하는데, 짧은 중첩 조건문이 있을땐 보호 구문으로 바꾸는게 좋음 swift의 guard와 같은 보호 구문으로 변경하면, 이건 이 함수의 핵심이 아니고, 이 일이 일어나면 무언가 조치를 취한 후 함수에서 빠져나온다는 의미를 전달예제 swift에만 있는 guard문 키워드가 탄생한 이유 보호구문 리펙토링의 핵심은 함수 내부의 의도를 부각하는 것 중첩 조건문을 보호구문으로 변경하기 예제 리펙토링 전)..
조건문 통합하기 비교하는 조건이 다르지만 그 결과로 수행하는 동작들에 대해서 조건부 코드를 나누지 말고 하나로 통합하는 것 리펙토링 전) struct Employee { let salary: Int let month: Int let isPartTime: Bool } let employee1 = Employee(salary: 3, month: 12, isPartTime: false) // Refactoring 전 func returnSome() -> Int { if employee1.salary > 2 { return 0 } if employee1.month > 5 { return 0 } if employee1.isPartTime { return 0 } return 1 } 리펙토링 후) func someC..
조건문 분해하기 조건문에서 중요한 것 조건문에서 무슨 일이 일어나는지 이야기해주지만 '왜'가 들어나는 코드가 필요 조건문들을 함수로 만들어서 조건의 의도가 분명하게 들어나도록 수정이 필요 // '어떻게'만 나타난 조건문 - 조건문이 길어지게되면, 조거문 안에 블록문에서 일어나는 이유를 파악하기가 힘듦 if 20 < jake.age && jake.plan.summerStart < jake.plan.reservationDate { charge = basePrice * 2 } else { charge = basePrice } // '왜'의 의미가 있는 있는 조건문 - 조건문을 추상화하여, 조건문 안에 charge = basePrice * 2의 이유를 파악하기 쉬움 if adult() && summer() { ..
값을 참조로 바꾸기 개념 데이터를 공유해야하는 상황에서는 모델을 참조 타입으로 변경 데이터를 공유해야할때, 만약 값 타입을 사용하고 있다면 그 데이터를 변경하면 그 데이터의 모든 복제본을 찾아서 빠짐없이 갱신해주는 번거로움이 존재 갱신해주다가 만약 하나라도 놓치면 데이터의 일관성이 깨져버리는 현상이 발생 값을 참조로 바꾸게 되면 *엔티티(Entity) 하나당 객체도 단 하나만 존재하며, 이런 객체들을 한데 모아 놓고 클라이언트 코드(사용하는 쪽의 코드)들이 접근을 관리해주는 일종의 저장소가 필요 엔터티(Entity): 식별 가능한 개체 ex) 고객이라는 Entity에는 이름, 나이, 주소와 같은 Attribute를 갖음 값을 참조로 바꾸기 리펙토링 해보기 ex) Order 모델 안에 Customer가 있..
참조를 값으로 바꾸기 참조 타입 vs 값 타입 참조로 데이터를 다룰 땐 객체는 그대로 둔 채 그 객체의 속성만 변경 값으로 데이터를 다룰 땐 새로운 속성을 담은 새로운 객체로 초기화하며 영향력은 복사된 곳에서만 고려됨 참조 타입의 데이터 구조를 사용하면 이 데이터가 다른곳에 건네줄때 이 값이 마음대로 바뀔수 있음 값 타입은 불변이기 때문에 불변 데이터를 같은 프로그램 외부에 건네줘도 나중에 그 값이 나 몰래 바뀌거나 내부에 영향을 주지 않는 다는 것을 확신할 수 있음 값 타입은 불변이므로 동시성 프로그래밍과 분산 시스템에도 유리 값을 복재해서 이곳저곳에서 사용해도 서로 간의 참조를 관리하지 않아도 되므로 유용 swift언어에서는 struct라는 값 타입이 있고, 보통 데이터 구조를 표현할때 struct를..
파생 변수를 질의 함수로 바꾸기 파생(Derived) 변수: 사용하는쪽에서 관심 밖의 변수들에도 영향을 주는 것 질의(Query) 함수: 사용하는쪽에서 관심 대상인 변수에만 영향을 주는 것 (단순 get, set) 파생 변수를 질의 함수로 바꾸기 리펙토링: 가변 데이터의 유효 범위를 줄이는 것 가변 데이터가 많아지면 한 쪽 코드에서 수정한 값이 연쇄 효과를 일으켜 다른 쪽 코드에 영향을 주어, 원인을 찾기 어려운 문제를 야기하므로 가변 데이터의 유효 범위를 줄이는 리펙토링이 필요 파생 변수를 질의 함수로 리펙토링 예시) Price에서 구조는 매우 안좋은 구조 discountedTotal의 정보를 변경하기 위해 setDiscountedTotal(number:)를 호출했더니 의도치 않게 안에서 discoun..
필드 이름 바꾸기 필드 이름을 변경하려고 할 때 이 필드가 여러곳에서 사용되고 있는 경우 변경 방법은 캡슐화를 통해 리펙토링 필드 이름 바꾸기에서 생각하는 포인트 변경하려는 필드가 여러곳에서 사용되고 있는 경우, 어떻게 바꿀것인가? 데이터 구조가 불변성으로 표현되면 좋은 이유? 필드 이름 바꾸기 예시 아래에서 name 필드를 title로 변경하고 싶은 경우? 이 값은 여러곳에서 사용되고 있기 때문에 쉽게 바꾸기 힘든 상황 name을 단순히 title로 변경하고난 후 빌드에러나는 곳을 찾아서 일괄 변경할 수 있지만 일괄 수정하다가 실수를 유발할 수 있음 (swift에서 일반적으로 데이터 모델은 struct를 사용하지만, 불변성의 중요성을 깨닫기 위해 class로 선언) class MyData { var n..