1.
김동준
Account Book 리펙토링 과정.
개발 : 2021/11
리펙토링 : 2022/05

2.
https://github.com/rising-jun/ios-account-book
기존의 구조

3.
https://github.com/rising-jun/ios-account-book
ListViewModel코드
1. fbReadModel의 변수명과 클래스명이 줄여져 있기에 가독성이 떨어짐.
2. ListViewModel과 FirebaseReadModel의 결합이 강하다.
- ListViewModel이 FirebaseReadModel의 구체타입을 소유.
문제점

4.
FirebaseReadRepository 코드
1. FirebaseReadRepository로 이름 변경. ( 가독성 )
2. Class -> Struct로 변경. ( 성능 향상 )
3. Delegate에서 Completion 클로져로 변경, FirebaseError 생성. ( 처리부분 가독성 개선, 에러 처리 개선 )
4. Firebase에서 가계부 정보를 읽어오는 동작 추상화. ( 의존성 낮춤, 테스트 용이 )
개선
1. FirebaseReadModel 개선하기.
https://github.com/rising-jun/ios-account-book/blob/main/AccountBook/
fi
rebase_model/FirebaseReadRepository.swift

5.
ListViewModel코드
1. 구체타입이 아닌 FirebaseReadable 추상타입을 생성 시 주입받도록 변경.
2. 상속되지 않을 class이기에
fi
nal을 선언 ( 성능향상 )
개선
2. ViewModel 개선하기.
https://github.com/rising-jun/ios-account-book/blob/main/AccountBook/account/list/ListViewModel.swift

6.
DependencyInjector 코드
1. 의존성 주입만 하는 싱글톤 클래스를 생성.
2. 의존성주입이 필요한 ViewController는 모두 DependencySetable 프로토콜을 채택.
3. ViewController가 자신의 의존성을 요청하면, 그에 해당하는 의존성을 주입함.
4. 테스트가 필요하다 생각한 class(struct)가 있다면 해당 동작을 추상화하여 결합도를 낮춤.
개선
3. 의존성 주입.
https://github.com/rising-jun/ios-account-book/blob/main/AccountBook/dependency/DependencyInjector.swift

7.
ListViewController 코드
1. ViewController가 생성 될 때 DependencyInjector에게 의존성을 요청하여 주입받음.
개선
3. 의존성 주입.
https://github.com/rising-jun/ios-account-book/blob/main/AccountBook/account/list/ListViewController.swift
DependencyInjector 코드

8.
WriteViewModel 코드
WriteViewModel에서 작성 금액의 정규식을 확인하고 있음.
- SOLID 단임책임원칙
문제점

9.
RegularExpression 코드
1. RegularExpression struct를 생성하여 해당 로직 분리.
- 추후 RegularExpression에 기능이 추가되여도 ( 아이디, 비밀번호 형식 )
WriteViewModel은 WriteExpressionCheckable 추상타입을 갖기에, 해당 추상타입의 메소드 외 ExpressionCheck메소드들은 사용 불가.
- WriteExpressionCheckable로 추상화 하였기에 의존성 주입 가능 ( 유지보수, 테스트 용이 )
개선
WriteViewModel 코드
https://github.com/rising-jun/ios-account-book/blob/main/AccountBook/account/record_account/write/RegularExpression.swift

10.
1. 명확하지 않은( 줄여쓴 ) 변수명, 메소드명, 클래스명 변경. ( 가독성 )
2.
fi
nal, private 선언하기. ( 성능 개선 - Dynamic Dispatch )
3. 중복 import 지우기. ( 불필요한 코드 제거 )
4. 강제추출 모두 옵셔널 바인딩으로 개선. ( 안정성 향상 )
5. Delegate 사용 부분 weak 선언. ( 메모리 안정성 향상 )
문제점 - 개선
https://github.com/rising-jun/ios-account-book/pull/31

11.
1. Firebase Database에 읽고 쓰는 로직 모두 서브쓰레드에서 실행하도록 변경. ( 기존 메인쓰레드에서 작업 )
문제점 - 개선
https://github.com/rising-jun/ios-account-book/pull/31

12.
1. switch문으로 값을 직접 비교하는 로직.
2. 0 ,1 ,2 등 값을 직접 활용하는 로직.
개선해야 할 점

13.
1. 사용자 로그인 기능
2. 카테고리 추가기능
3. 지도에 사용관련 어노테이션 업데이트
추가 사항
추가해야 하는 기능.

14.
1. 가계부앱 정보도 캐시처리를 해야할까?
1. 한다면 디스크 캐시를 해야할까? 메모리 캐시를 해야할까? 둘 다 해야 할 까?
2. 캐시 삭제주기는 언제로 설정 해야 할 까?
3. 시간이 지나면 일괄 삭제를 해야할까? 데이터에 우선순위를 두어 낮은 순위부터 삭제 해야 할 까?
4. 우선순위를 두어 삭제한다면, 데이터 관리 키를 우선순위 큐에 담았다 일괄 삭제하는 편이 좋을 까?
2. 사용자 정보를 UserDefault에 저장해 둔 후,
1. 얼마 주기로 로그아웃 해야 할 까?
추가 사항
기능적인 고민.
1. 어떤 로직을 테스트 해야 할 까?
2. 테스트 하지 않는 코드는 강한 결합도 괜찮을까?
코드 작성에 대한 고민