[회고] H프로젝트(iOS) 2018.11 ~ 2019.3

작년 11월 부터 H프로젝트(iOS)를 시작했는데, 처음으로 SI를 해본 느낀 점과 생각을 정리하기 위해 회고록을 작성해 보았다.

1. 잘한 점

- RxSwift / ReactorKit

정말 적용을 할지 말지 고민을 많이 했다. 개인 프로젝트 하면서 조금 공부를 해보았지만 실제 프로젝트에 사용을 해도 괜찮을까? 라는 많은 고민이 되었다.

같이 협업하는 개발자 분도 처음에는 일정이 너무 빡빡해서 힘들지 않겠냐고 했지만, 지금 하지 않으면 못한다는 생각이 들어서 강행을 하게되었다.

처음엔 MVVM패턴으로 구조를 잡다가 중간에 ReactorKit으로 적용하게 되었다. 

아직 구조가 부족한 부분이 있고 일부는 Rx를 사용하지 않은 부분도 있었지만, 같이 협업했던 개발자분이 실력이 뛰어난 분이라 덕분에 나도 같이 많이 배울 수 있었다.

- StroyBoard / Custom View 활용

이번에 StroyBoard를 기능별로 잘 나누어서 구현한거 같다.  예전에는 나누지 않아서 버벅거리거나, 불필요하게 많이 나눠서 헷갈리는 경우가 많았는데 잘 정리를 해서 만족도가 높았다.

그리고 나는 Custom View를 만들기 보다는 Story Board 에 전부 그려 넣는 것을 선호하는데, 이번에 같이 협업한 개발자 분에게 반복되는 화면을 Custom View 로 만들어서 재활용하는 방법을 많이 배우게 되었다. 비슷한 화면의 경우에는 Super ViewController 를 만들고 상속 받아 사용하는 방법도 많이 익숙해졌다.

(이런 Custom View 활용은 유지보수하는데 굉장한 이점이 있다.)

- Enum / Extension / Structure 의 활용 

예전에는 Enum이 익숙하지 않고 잘 활용하지 않는 편이었는데, 정말 편리하다는 것을 알게되었다. 어떤 State나 Category같은 집합 데이터 경우 Enum를 활용하면 굉장한 이점이 있다.

Extension는 Protocol과 함께 더욱 더 많은 활용을 할 수 있었다. 대부분 비지니스 로직은 Protocol과 Extension에 구현을 해놓고 Reactor에서 사용하도독 구현했다. 구조적으로 아주 깔끔하고 유지보수하기도 쉬운 구조가 되었다.

또한 그동안 대부분 데이터 모델은 Class를 사용 하였는데, 일부 Value 타입 인 Structure 모델을 활용도 하였다. (다만, Realm를 사용하다 보니 대부분의 데이터 모델은 Class로 잡을 수 밖에 없었다.)

Protocol는 대부분 함수으로 된 비지니스 로직을 만들 때 활용했고, Structure는 변수를 저장하고 그 변수들을 활용할 때 (네이밍이 필요할 때) 사용하였다.

- 코드 리뷰

코드 리뷰는 Git의 Pull Request를 통해 진행되었다. 사실 처음으로 경험해본 코드 리뷰였는데 서로 얼굴 붉히는 일이 많아졌다.

이렇게 많은 실수들을 하는지 몰랐기 때문이다. (보일러 플레이트는 덤이었다.) 

서로 생각이 달라 언성이 높아지는 일도 몇번 있었고, 창피한 적도 많았지만, 그만큼 코드 품질은 높아졌다.

코드 리뷰의 성공 여부는 팀원들간의 신뢰가 중요하다는 생각이 든다. 

그리고 개인적으로 나의 코드는 읽기 쉽지만 다른 사람이 짠 코드를 이해하는 데에는 많이 노력이 필요하다는 것을 깨닫게 되었다.

이 프로젝트를 통해 성장한 점이 있다면 90%는 다 코드리뷰에서 나온 것 같다.

2. 아쉬운 점

- 기획과 커뮤니케이션을 통한 설계

원래 나는 이 프로젝트가 아닌 다른 프로젝트를 진행할 예정이어서 설계 단계일 때 이 팀에 합류하지 못했다.

기획 의도를 정확하게 이해하지 않은 상태에서 이미 정해진 기획서, 재플린을 보고 개발을 하다 보니 오해도 생기게 되고 비지니스 로직을 잘못 구현하는 경우도 많았다.

결국에 나중에 다 버그로 돌아오게 되었고, 이부분에서 많은 스트레스를 받게 되었다.

또한 기획에서 정확하게 정해지지 않은 부분들을 커뮤니케이션을 통해 풀어야 하는데, 내 생각대로 구현한 것은 큰 실수 였던 것 같다.

다음 프로젝트를 할 때에는 설계부터 꼼꼼히 생각해보고, 비지니스 로직을 먼저 짜보고, 기획과 많은 커뮤니케이션을 통해 설계를 단단하게 해야겠다는 생각이 든다.

추가로 디자인에 대해 너무 수동적으로 참여한 것이 아닌가 생각한다. 디자이너가 주는 디자인대로 만들기 보다는 iOS 에서는 좀 더 좋은 간단하고 좋은 방법은 적극적으로 제시 해봤으면 좋았을 것 같다.

- 테스트에 대한 무지

개인적으로 난 유닛 테스트에 대해 회의적이었다. 우리가 의료 장비 S/W 나 금융 S/W를 만든다면 그 로직의 완벽함을 1순위로 해야하지만,

현재 진행중인 프로젝트는 앱의 완벽함보다는 얼마나 빨리 만들수 있느냐가 중요했기 때문이다.

즉 일단 빨리 앱을 뽑아내고 사용자 테스트를 통해 보완하는 것이 더 나을 것이라고 생각했었다.

하지만 이번 프로젝트를 다시 생각해볼 때, 일정을 쪼개서라도 테스트 코드를 작성하는 것이 좋았을 것이란 생각이 든다.

첫 빌드가 나오고 버그 리포트가 쌓이면서 내 코드에 대한 자신감이 많이 떨어지기 시작했다. 

(버그가 나오는 것은 당연한 일이지만 심리적으로 타격이 왔다.)

나에게 있어 테스트 코드는 내 코드에 자신감을 얻기 위해 꼭 필요하다는 것을 깨닫게 되었다.

요즘 테스트 코드에 대한 세미나와 글들을 보고 나니 테스트 코드를 작성하면 자연적으로 로직이 모듈화가 되고 구현하는 방법이 많이 좋아진다는 것을 알게되었다.

또한 ReactorKit는 테스트 를 쉽게 할 수 있게 해주고, 전수열님이 친절하게 세미나도 해주셨으니 다음에는 꼭 테스트 코드를 통해 개발을 해야겠다는 생각이 든다.

- RxSwift / ReactorKit 활용도

MVVM를 어떻게 설계할까 헤매던 중에 해답을 찾게 해준 ReactorKit 덕분에 구조를 짜는데 어려움은 없었다.

그러나 복잡한 화면을 만들때에는 이런 기능이 분명 Rx에도 있을거 같은데.. 하면서도 못 찾아서 Reactor없이 옛날 스타일로 구현한 화면도 있었다. 

(가끔 State 관리가 어려운 부분이 있었다.)

또한 오픈라이브러리를 사용할 때 delegate / datasource 부분을 Rx로 바꾸는 것이 어려워 포기하고 옛날 스타일로 구현한 것도 많았다.

물론 100% Rx 로 구현할 필요는 없지만, 좀 더 가독성이 좋고 품질 좋은 코드를 작성하기 위해 계속해서 공부를 해야겠다.

- Guard 실수 / Extension 실수

이번 개발을 하면서 가장 기억에 남는 실수이다.

예전에는 if else 문을 자주 사용했는데, guard 문이 더 효율적이라는 것을 알게 되면서 guard 문을 사용했는데... 문제는 guard문의 경우 else 일땐 return를 시킨다는 것이다.

따라서 이어지는 코드가 실행되지 않는다는 것을 잊고 기본적이지만 큰 실수를 한 경우가 있었다.

Extension를 남용하다가 특정 일부분만 수정을 하려고 했는데 상관이 없던 부분도 같이 수정이 되어서 오류가 생기는 경우가 있었다..

Extension을 잘 사용하면 좋은 코드를 만들수 있지만.. 이러한 실수가 나지 않도록 조심해야 한다. (Where 를 사용하면 특정 Class만 사용하도록 강제할수 있다.)

- 배포 자동화

배포를 할 떄 우리는 3개의 버전의 배포가 필요했다. 매번 Xcode로 아카이브하고, 앱스토어에 올리고.. 기다리고... 

이러한 삽집을 방지하기 위해 다음에는 Fastlane를 사용해 볼 생각이다.

빌드라고 앱스토어에 올리는 것은 어렵지 않을거 같아서 조만간 적용할 것 같다.

3. 기타

- 모듈화

오픈 라이브러리를 사용할 때 cocoapod 를 사용 했는데, 우리 회사에서 만드는 앱도 특정 공통적인 부분은 라이브러리로 뽑아 내면 좋을 것 같다는 생각이 들었다.

하지만 결국 시간이 있을 때 가능할 것 같은데.. cocoapod에 등록하는 방법도 한번 시도를 해봐야겠다.

- 일정

이번 프로젝트는 외주이다 보니 일정에 굉장히 민감할 수 밖에 없었다. 일정을 예상해서 측정하는 일은 참 어려운 일이라는 것을 많이 깨닫게 되었다.

일정을 못 마추면 야근, 주말 작업을 하게 되고, 그러면 능률이 떨어지면서 코드 품질이 떨어지고, 안 좋은 코드에서 작업을 해야하니 더욱더 안좋은 코드들이 나오기 시작했다.

일정을 조금 널널하게 잡아줬으면 하지만.. 그건 불가능 할테니 일정을 효율적으로 쓰는 방법을 생각해봐야겠다.

개인적으로 중간중간 회사에 허락을 맡아 재택근무를 3번 정도 했었는데 만족도가 높았다. 다른 방해없이 집이나 카페에서 자기 일을 하면 되니 더 효율적이었던거 같다.

그리고 이동시간을 줄이고 그 시간을 활용할 수 있다는 것이 너무나 매리트로 다가왔다.

재택근무를 할 수 있도록 회사에 더 요청을 해봤는데.. 아직까지는 회사에서는 회의적으로 생각하는 것 같아 아쉽다.