Goals
Good
- 뭔가 어떻게든 끝내려 했다..?
- 무언가 나만의 새로운 것을 하려는 시도를 하는 중이다.
Bad
- 문서를 조금더 꼼꼼히 보지 않았던 것: 질문으로 해결하자
- 중간에 루틴이 깨진 것
- 블로그 글을 많이 쓰지 못한 것
Learns
- RawType을 받아 ViewModel의 형태로 변경해야 한다고 하자.
- RawType extension에서 공통적으로 사용할 만한 것들을 처리해둔다 (var~)
- ViewModel에서는 RawType을 받는 형태의 Protocol을 만들고, 기본 값들을 extension에서 처리해둔다.
- 실제로 ViewModel에서는 해당 RawType을 받아 View에 연관된 세부로직만을 처리한다.
- 내 문서에 실제 코드를 주석 처리 해두었다.
- 먼저 추측하기
- 이런 상황 마주치기 쉽지 않음
- App 기동 -> 즐겨찾기 sync -> 데이터 5000개로 상향됨
- 일단 데이터가 늘어나니 시간 더 걸릴 거다.
- 네트워크 호출
- 일단 데이터 크기 2배 넘어감
- 2배 이상 증가할 것임
- 2.5초 걸렸다가 5초 정도로 가지 않을까?
- 근데 11초..? 메인은 아닐 수 있음
- 파싱
- json 파싱
- 얼마안 걸릴 것이라 예상하나 개수가 많으면?
- 요즘은 디바이스가 좋아 크게 안걸릴 수도 있으나 10메가 10번보다 100메가 한번이 더 오래걸렸었음
- 왜? 한번에 더 많은 CPU와 메모리를 쓰기 때문, 즉 리소스를 한번에 많이 씀
- 이것에 따라 최적화가 달라질 수 있음
- App 내부 로직
- DB 넣기
- 2000 -> 5000개 2배 이상 시간이 걸릴 것임
- 마커 클러스터링
- 얘도 2배정도 걸릴 것임
- 근데 2배 이상으로 커질 수도 있음, 시간 복잡도에 따라.
- 프로파일링
- 단순히 CPU 타임을 기반으로 판단할 수는 없을 수 있음
- 그래도 그나마 시간 측정이 가장 빠르다.
- Product > Profile
- 빌드 새로함
- 빌드 과정에 profiling 필요한 코드 심음
- Time Profiler
- 어디서 시간 오래걸리는지?
- simulator로하면 시간 좀더 오래걸림
- 드래그 해서 선택하면 보임
- 시간 오래걸린 것부터 보면 됨
- 코어데이터는 조낸 느리다.
- 5000개를 넣으려면 5000번 호출되는 함수가 있었음
- 여기서 중복있는지 확인하고 아니면 넣는 함수
- 여기서 중복 체크 안하면 빨라지지 않을까?
- 제안 방법
- 처음에 할때는 중복체크 필요없잖아
- 일일히 중복 체크하는게 오래걸림
- 코어데이터는 key가 없음
- 즉, 처음부터 다 뒤짐. Hash가 아니라는 것.
- 5000번 들어오면 다 뒤져서 찾음
- core data는 search가 느림.
- insert는 생각보다 빠름
- 코드 수정
- 이제 문제를 어떻게 해결할 것인가?
- 클러스터링이 6초나 걸림
- 그리고 이게 main thread.. ui blocking
- 어떻게?
- 방안
- addBookmark에서 있는지 확인 어떻게 빠르게 할 것인가?
- 마커매니저 background thread?
- 프로파일링시 배운 것
- 처음부터 어렵게 코드 짜지 마라
- 굳이 background할 필요없으면 main에서 해라
- 나중에 생각해라
- 추측하는 과정, 계획하는 과정도 필요
- 프로파일링은 치명적인 부터 본다, 작게하고 큰 효과
- CPU 수치도 마찬가지다.
- 프로파일링은 꼭! 해봐야 한다.
- main thread을 묶고 있는 녀석이 있다면 background로 보낼 방법을 해봐야 한다.
- UI 적용 코드 보다가 배운 것
- shaver보고 깜짝 놀람
- 그냥 extension에 정의하고 함수 사용하는 것으로만 생각했는데,
- 그렇게 하지 않고 연산자를 정의하여 적용하는 개념으로 확장함
- 즉, 구조체에는 관련 값만 정의하고 연산자를 통해 적용하는 방식을 사용
- 놀라움.. 값을 주입하는 형태(연산자)를 통해 생각하는 방식을 개선 가능
Commitment
배운 내용
- 성과를 내려는 것보다 성장에 초점을 맞춰라.
- 글쓰고 공유 조금더 자주해라.
- 글을 쓸 때, 완벽하게 작성하려는 생각을 조금 내려놔라.
- 글의 길이를 조금 줄여라. 결국 말하고자 하는 것은 간단하다.
- 말하고자 하는 것을 고민하는 시간을 더 쏟아서 글을 짧게 쓰려는 연습을 해라.
- 크고 간간히보다, 작고 자주가 더 좋다.
- 더 많은 피드백을 받을 수 있게 작고, 읽기 쉽게 적어라.
- 구현 패턴을 읽어 코드의 표현에 드는 시간을 줄여라.
- 구조에 대한 고민은 아직 이르다.
- 디자인 패턴을 읽었다고 바로 적용하려는 시도는 오히려 위험할 수 있다. 작은 판단이 모이면 그러한 패턴으로 갈 수 있다.
- 작은 판단에 있어 더 옳은 방향으로 하려는 연습을 더 많이 해라.
- 간간히 새로운 시도를 자발적으로 해라.
방향
- 이번달에는 어찌보면 첫 스펙이라 할 수 있는 것을 처리했다.
- 코드의 흐름을 따라가는 것이 어려웠던 것 같다.
- 기본적으로 어떠한 형태들로 구현되어 있는지 파악하는 것이 오래걸렸다.
- 팀원분의 도움을 받으면 받을 수록 직관적으로 이해하는 데 도움이 되었다.
- 그랬다면 조금더 나은 코드를 넣을 수 있었을 텐데 하는 아쉬움이 있다.
- 직관적으로 이해가 가지 않는다면 바로 도움을 요청하는 것이 효율적이다.
- 내가 할 수 있는 당시의 최선의 코드를 넣는다는 마음으로 포기하지 말고 임하자.
- 루틴이 깨지면서 까지 무리해서 하지는 말자. 더 중요한 것이 있다.