티스토리 뷰

22년 코드스쿼드를 수료하고, 여러회사의 채용과제를 하였습니다.

과제가 끝나면 "회사에서 내주는 채용과제 안에서 내가 어떤것을 보여주길 원할까?"는 생각으로 과제를 복기하였습니다.

채용과제는 얼마나 비용을 절약하며 만들 수 있나?를 확인하는 시험이라 생각하기에 이를 예를 들어보겠습니다.

 

성능적으로 빠르다 (효율적이다)는 비용을 절약하는 앱이 충족하는 조건들 중 하나라고 생각합니다. ( 성능이 전부가 아님. )

- 얼마나 빠르고 효율적으로 개발할 수 있을까?

- 얼마만큼 읽기 쉽게 개발할 수 있을까?

- 부가적인 것들 ( 추가구현 + 테스트 ) or 사용 기술스택(채점비율이 높을 수 있음)

HIG, 인터넷 속도, 에러처리 등

 

보통 채용과제에서 무한스크롤을 보여주는 이미지Cell을 구현해야 하는 경우가 많습니다.

"이미지 주소를 네트워킹에 요청한 후 응답으로 받은 Data를 UIImage로 변환하여 보여준다."

결과물은 당장 잘 확인할 수 있습니다.

 

- 얼마나 빠르고 효율적으로 개발할 수 있을까?

문제

1. 네트워크 환경에 따라 속도가 느릴 수 있다.

2. 사용자의 데이터 사용이 많아질 수 있다.

3. 아이폰 성능에 따라 앱이 버벅일 수 있다.(반응이 느릴 수 있다.)

 

캐시처리하기!

문제 1, 2 : 디스크 + 메모리캐시를 활용하여 사용자가 2번째 확인하는 이미지들에 대해서는 엄청 빠르게 다시 노출할 수 있습니다.

다만 첫번째 이미지를 로딩할 시에는 어쩔 수 없이 네트워크, 디스크, 메모리 비용을 사용해야 합니다.

문제 3 : Data를 이미지로 변환하는 작업을 BackgroundThread에게 부탁한다. (Diffable DataSource 활용)

 

+ 쓰레드는 필요한 작업만 하도록 해준다.

사용자가 스크롤을 너무 빠르게 내려, 위의 Contents들을 보여줄 필요가 없을 경우, 응답한 데이터를 받는 작업을 취소한다. ( Task 관리 )

 

 

- 얼마만큼 읽기 쉽게 개발할 수 있을까?

이는 유지보수 측면과 관련이 있습니다.

사내 프로젝트 내부 구조에 테스트를 위한 + 추상화가 아주 잘 나누어진 MVVM패턴이 있습니다.

ViewModelType이 있고, ViewModel 실객체는 이를 채택하고 있습니다.

ViewModelType에는 ViewModelBinding, ViewModelInput, ViewModelOutput 3가지 추상타입을 채택하고 있습니다.

View에 어떠한 데이터 하나를 추가하기 위해서는 위의 파일들을 모두 읽어봐야 하며, 추가하고 싶은 내용을 프로토콜에 추가, 실객체에 추가 하기.. 를 하다보면 결국 아무 추상화도 하지 않는 ViewModel에 비해 많은 시간을 사용하게 됩니다.

ViewModel을 이렇게까지 추상화한 이유에는 "테스트가 용이하기 때문"이라고 생각하는데 (ViewModel의 구현내용이 통째로 변할 일은 거의 없을거라 예상하기에), 해당 구조를 채택하고 테스트코드도 붙어있지 않습니다. 

그렇기에 해당 구조로 작성된 코드는 유지보수에 오랜시간이 걸림으로 생산성이 떨어지는 구조라고 생각합니다.

* 해당 구조의 의도대로 테스트를 잘 하고 있다면 좋을 수 있다 생각합니다. 

 


- 부가적인 것들 ( 추가구현 + 테스트 ) or 사용 기술스택(채점비율이 높을 수 있음)

저는 부가적인 것들은 위의 두가지 구현이 끝나면 여유시간에 하였습니다.

또 개인적인 취향이지만 기술스택은 왠만하면 ThirdPartyLibrary를 사용하지 않는 편입니다.

예를 들어 RxSwift 사용을 권하는 과제가 있을 때,

1. RxSwift가 없으면 해당 기술을 구현할 수 없는 사람.

2. RxSwift를 모르지만 이를 사용하지 않고 해당 기술을 구현할 수 있는 사람.

에서 2번의 경우가 더 기초가 탄탄한 사람이라 생각하기 때문입니다.. ( 개인적인 생각입니다. )

 

현재 재직중인 회사에서는 어떠한 ThirdPartyLibrary를 사용하지 않고 구현하였습니다.

그렇기에 높은 점수를 받을 수 있었다고 들었습니다. 

 

나머지는 기초 잘 지키기 (메모리 순환참조 주의 - weak 잘 활용하기), HIG에서 명시하듯 버튼크기 44이상.. 등등

 

이러한 방식들이 비용을 절약하는 앱 만드는 기초적인 방법이라 생각합니다.

캐시처리, 쓰레드 Task 관리(경쟁상태 예방 포함)에는 CS지식이 필요하고,

유지보수하기 좋은 코드를 위해서는 클린코드(좋은코드 작성하는 방법)에 대해 항상 공부하고 고민할 필요가 있습니다.

마지막은 HIG와 스위프트의 신기술들(WWDC 시청)을 끊임없이 공부할 필요가 있다 생각합니다.

 

감사합니다.

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2024/11   »
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
글 보관함