1편 - TLDR 개발 일지 - 앱 소개
2편 - TLDR 개발 일지 - 기획
서론
이전에는 설계에 대한 포스팅을 따로 하지 않았습니다.
설계의 중요성을 크게 생각하지 않아서 테스트 미흡, 지저분한 코드 등 문제점이 많았습니다.
이번 포스팅에서는 디자인 패턴, 구현 방법 등 설계에 대한 내용을 다룹니다.
디자인패턴
이번 TLDR에서는 MVVM을 사용했습니다.
(MVVM에 대한 내용은 MVVM with iOS 에서 확인해 주세요.)
MVVM을 사용한 이유는 두 가지 입니다.
1. View 로직과 Business 로직 분리
MVVM은 View와 ViewModel로 View 로직과 Business 로직을 분리할 수 있습니다.
그래서 View가 없어도 비즈니스 로직을 테스트할 수 있어요.
이게 제일 좋았던 점이었어요.
카멜레온 프로젝트를 구현할 때는 View가 있어야 비즈니스 로직을 수행할 수 있었습니다.
이번 TLDR에서는 View 구현을 완성하지 않아도 로직을 테스트할 수 있어서 너무 편했어요.
왜 여러 사람이 협업할 때 MVVM이 거의 필수라는 말이 나왔는지 알 거 같더라고요.
2. 테스트가 쉬움
1번과 연계되는 내용인데요. MVVM은 테스트가 쉽습니다.
View가 없어도 ViewModel의 함수를 호출해서 로직을 테스트할 수 있습니다.
TLDR의 기능 중 하나인 원본 텍스트를 요약하는 기능을 예로 들어보겠습니다.
View와 비즈니스 로직이 분리가 되지 않았다면,
텍스트 입력 - 버튼 클릭 - 요약으로 동작해서 TextView와 버튼을 구현해야 요약 로직을 수행할 수 있는데요.
로직을 분리한 덕분에
이 메서드를 호출하기만 하면 요약 결과를 확인할 수 있습니다.
아주 간편하죠?
만약 View와 비즈니스 로직 담당자가 다르다면 비즈니스 로직 담당자가 View를 재촉하지 않아도 될 거에요 ㅎㅎ
로그 작성
로그 작성에 대한 고민도 해보았습니다.
이전까지는 코드에 print 문을 직접 작성해서 로그를 출력했습니다.
간단 확인, 에러 출력을 포함한 모든 출력을 구현했어요.
그러다보니 디버그 모드, 릴리즈 모드로 나눠서 출력하기 어려웠고 로그가 나와도 파악하기 힘들 때가 있었습니다.
이번에는 Logger 클래스를 구현해서 debug, info, error 역할로 나눴습니다.
디버그 코드만 보여드릴게요.
line과 함수 이름, 파일 이름을 출력하고 객체의 값 확인 등이 필요하다면 object를 전달하면 됩니다.
맨 앞에는 로그 종류와 날짜, 시간을 출력하도록 했습니다.
로그창을 보면
이렇게 나와요.
어떤 역할의 로그이고, 언제, 어디에서 출력이 됐는지 명확히 알 수 있습니다.
마무리
서론은 거창했는데, 내용은 부실한 거 같네요 ㅎㅎ;
분명 고민은 오래 했는데 적고 보니 뭔가 적은 거 같아요 ㅋㅋ
그래도 오늘 작성한 내용 덕분에 훨씬 수월하게 프로젝트를 진행할 수 있었습니다.
다음에도 코드를 작성하기 전에 설계하는 습관을 길러야겠습니다.
감사합니다!
아직은 초보 개발자입니다.
더 효율적인 코드 훈수 환영합니다!
공감과 댓글 부탁드립니다.
swift, iOS, iOS 개발, 아이폰, 앱 개발, 개발, 코딩