일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 | 31 |
- UITextView
- 애니메이션
- SWIFT
- ribs
- combine
- MVVM
- UICollectionView
- ios
- 클린 코드
- Xcode
- Human interface guide
- Clean Code
- 리펙토링
- uitableview
- Refactoring
- collectionview
- 리팩토링
- map
- 스위프트
- swift documentation
- 리펙터링
- rxswift
- uiscrollview
- tableView
- RxCocoa
- clean architecture
- Protocol
- HIG
- swiftUI
- Observable
- Today
- Total
목록리팩토링 (18)
김종권의 iOS 앱 개발 알아가기
cf) 파생과 질의 구분하기 파생(Derived) 변수: 사용하는쪽에서 관심 밖의 변수들에도 영향을 주는 것 질의(Query) 함수: 사용하는쪽에서 관심 대상인 변수에만 영향을 주는 것 (단순 get, set) 매개변수를 질의 함수로 바꾸기 함수의 동작에 변화를 주는 요인은 함수의 매개변수 즉, 함수의 동작에 변화를 주는 요인을 구성할 때 짧으면 짧을수록 이해하기가 쉬운 형태의 함수 함수가 스스로 쉽게 결정할 수 있는 값을 매개변수로 건네는 것도 일종의 중복이므로, 이 결정은 함수안에서 결정하게하여 더욱 간결한 함수형태로 변경이 필요 ex) 함수를 사용하는 쪽에서 person, person.name을 넘기는데, 중복코드가 발생 let person = Person(age: 1, name: "jake") l..
Assertion 추가하기 특정 조건이 참일 때만 동작하도록 하는 코드 영역이 있는데, 이러한 기능을 development 타겟에만 적용시켜서, 사전에 개발할 때 실수를 방지하도록 하는 기능 이러한 가정이 코드에 항상 명시적으로 기술되어 있지 않거나 이런 명시적인 것을 못보고 개발을 할 때 실수를 막기 위하여 assertion을 넣는 것 assertion 추가 시 주의사항 assertion 실패는 시스템의 다른 부분에 영향을 주지 않아야함 development 타겟에만 적용시켜 운영에서는 영향을 주지 않도록 해야함 assertion은 개발자가 실수를 할만한 곳이나 버그를 잡은 후에도 assertion을 넣으면 다른 개발자가 실수할 확률을 줄어주기 때문에 좋은 코드 Assertion 리펙토링하기 swift..
조건부 로직을 다형성으로 바꾸기 조건부 로직이 복잡해지면 수정하기가 굉장히 어려워지므로, 더 높은 수준의 개념인 다형성을 사용하여 조건들을 분리하는 방법 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를..