일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- tableView
- 리펙터링
- MVVM
- RxCocoa
- 리팩토링
- SWIFT
- swift documentation
- UICollectionView
- 애니메이션
- Xcode
- swiftUI
- Observable
- rxswift
- ribs
- Refactoring
- uiscrollview
- 스위프트
- ios
- combine
- Human interface guide
- Clean Code
- 클린 코드
- map
- HIG
- UITextView
- clean architecture
- Protocol
- collectionview
- 리펙토링
- uitableview
- Today
- Total
목록ios (1095)
김종권의 iOS 앱 개발 알아가기
* 냄새와 휴리스틱: 파틴 파울러의 "Refactoring"에서 "코드 냄새"를 표현하여 주의해야하는 코드 사항들에 대해 나열한 것에 더하여 저자 로버트 C.마틴의 생각을 더한 것 이름 서술적인 이름을 사용할 것 소프트웨어가 진화할 경우 의미도 변하므로 선택한 이름이 적합한지, 성급하지 않고 신중하게 고를 것 로버트 C마틴에 의하면, 소프트웨어 가독성의 90%는 이름이 결정 주석을 통해 추가 설명을 하려고 하기전에, 먼저 서술적인 이름으로 코드를 구성하는 방향으로 구현하면 다 읽지 않아도 유추하기가 쉬워져서, 코드 생산성에도 긍정적인 영향을 부여 RIGHT - 서술적인 이름으로 인해 함수의 이름만 보고도 내용을 예측할수 있는 형태 private let ballCountToStrike = 10 privat..
* 냄새와 휴리스틱: 파틴 파울러의 "Refactoring"에서 "코드 냄새"를 표현하여 주의해야하는 코드 사항들에 대해 나열한 것에 더하여 저자 로버트 C.마틴의 생각을 더한 것 일반 이름과 기능이 일치하는 함수 이름만으로 분명하지 않은 함수를 사용하면 매번 문서를 뒤적여야 하므로 처음부터 함수 이름과 기능을 확인할 것 WRONG - 5초인지, 5주인지, 5일인지 알 수 없는 상태이므로 더욱 애매한 함수 let newDate = date.add(5) RIGHT - 함수의 이름이 명확한 경우 let newDate1 = date.addDaysTo(5) 역할 분담에 대한 의존성을 제대로 할 것 ex) 임직원들의 report를 만드는데, page가 지정된 크기 pageSize만큼 커지면 페이지를 초기화 시키는..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/Vzpgt/btrmgDWLIW3/xOmYrs0VSDKG1EjhxOhAyk/img.png)
* 냄새와 휴리스틱: 파틴 파울러의 "Refactoring"에서 "코드 냄새"를 표현하여 주의해야하는 코드 사항들에 대해 나열한 것에 더하여 저자 로버트 C.마틴의 생각을 더한 것 주석 쓸모없는 주석 주석은 빨리 낡으므로 쓸모 없어진 주석은 `의식`하여 재빨리 없애야 코드를 그릇된 방향으로 이끌지 않게하므로 주의 중복된 주석 코드 내용과 중복되는 주석 내용을 피할 것 WRONG - 코드 내용과 중복되는 주석 i += 1 // i 증가 WRONG - 메소드 시그니처만 달랑 기술하는 주석 (parameter의 내용만으로 충분히 의미가 표출되지만, 불필요한 주석) /** (summary 부분) > Description 부분 - Parameters: - sellRequest: Sell을 하기위해 필요한 리퀘스트..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/0O8Er/btrmcMlPhgt/OAmkPALKfSR9NmbI5ybHM0/img.png)
* 알아야하는 기본 지식 - 테스트 코드를 작성해야 하는 이유 - 클린 코드 (창발성) - DIP(Dependency Inversion Principle) 설계 전에 필요한 프레임워크 설치 RxSwift RxCocoa ViewModel을 testable되도록 만드는 이유 viewModel에는 UI 인풋에 따라 UseCase를 통해 비즈니스 로직을 실행 viewModel은 어떤값을 UI에 넘겨주어야하는지 정보를 담고 있는 컴포넌트 UI의 인풋부터 시작하여, 비즈니스 로직과 아웃풋까지 동시에 모두 테스트할 수 있는 컴포넌트는 ViewModel ViewModel을 testable하게 구현하는 아이디어 ex) LoginVM (로그인 ViewModel)을 만드는 예시 LoginVM 프로토콜을 만들어서 테스트할 때..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/8p9Xq/btrl4LU6Zzl/WFkqExamDkQMwyIaPMyOPK/img.png)
1. Timer 구현하기 - UIDatePicker 개념, Timer로 구현 방법 2. Timer 구현하기 - DispatchSourceTimer로 구현 방법 (Background에서도 동작) 3. Timer 구현하기 - CircularProgressBar UI 구현(CAShapeLayer 사용), DispatchSourceTimer와 Timer로 타이머 구현 방법 아이디어 첫 번째 화면에서 UIDatePicker를 통해 시간을 선택하고 확인을 누르면 먼저 DispatchSourceTimer로 만든 모듈이 동작 확인 버튼을 눌렀을때 다음 화면에서 직접 만든 CircularTimerView에 타이머 관련된 정보를 표출 첫 번째 화면 SettinTimerVC는 글을 2. Timer 구현하기 - Dispatc..
* 창발성: 불시에 솟아나는 특성 4가지의 규칙을 따라서 창발성을 촉진하는 방법 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지 모든 테스트를 실행 중복을 제거 프로그래머 의도를 표현 클래스와 메소드 수를 최소화 1. 모든 테스트를 실행하라 설계는 의도한대로 돌아가는 시스템을 내놓아야 하는데, 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한대로 돌아가는지 간단한 방법이 없다면, 소용없는 설계 모든 테스트 케이스를 항상 통과하는 시스템은 검증된 시스템이며, 검증되지 않은 시스템은 절대 출시하면 안되는것을 주의 테스트가 가능한 시스템을 만들려고 애쓸 경우, 동시에 설계 품질이 높아지는 효과도 존재 테스트가 가능한 시스템 - 크기가 작고 목적 하나만 수행하는 클래스 테스트가 가능한 시스..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/6z1ag/btrl1Kav3d6/UjSrDlajMy4DKK5P8PjPf0/img.gif)
1. Timer 구현하기 - UIDatePicker 개념, Timer로 구현 방법 2. Timer 구현하기 - DispatchSourceTimer로 구현 방법 (Background에서도 동작) 3. Timer 구현하기 - CircularProgressBar UI 구현(CAShapeLayer 사용), DispatchSourceTimer와 Timer로 구현 방법 UIDatePicker UI UIDatePicker UI 개념: https://ios-development.tistory.com/773 UI 코드 import UIKit class ViewController: UIViewController { lazy var countDownDatePicker: UIDatePicker = { let picker = ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bwKs9o/btrlTjeuJfI/TNirkc4TU54E3hiDdbvQ70/img.png)
시스템을 만드는 것 도시를 만드는 것과 동일한 것이며, 도시를 세운다고 했을때 혼자서 도시를 만들기는 불가능하지만 각 수도 관리 팀, 전력 관리 팀, 교통 관리 팀들이 적절한 추상화와 모듈화에 의해서 효율적으로 돌아가는 방식 소프트웨어 팀도 시스템 수준에서도 깨끗함을 유지하는 방법이 중요 시스템 제작과 시스템 사용을 분리할 것 생성(Construction)과 사용(Use)의 차이 시스템 생성: 의존성을 연결하는 준비 과정 시스템 사용: 준비 과정 이후에 이어지는 런타임 로직 시스템 생성과 시스템 사용을 분리하는 대표적인 방법 - DI(Dependency Injection) 시스템 제작과 세스템 사용을 분리해야하는 근본적인 이유: "관심사"를 분리함으로서 SRP원칙을 준수하기 위함 1) 생성과 사용 분리 ..