2주짜리 팀 프로젝트를 진행하며

지난 2주동안 백엔드 2명, 웹프론트엔드 1명, iOS 1명이 포함한 팀으로 Todo App 개발을 했다.
난 iOS 개발을 맡았고, 이건 지난 2주간 느낀 것들과 앞으로의 방향을 정리한 글이다.

1. 요구사항 분석을 더 철저히 하기

초반에 요구사항을 분석하는 과정에 시간을 많이 들이지 않았다. 그래서인지 내가 필요한 데이터를 백엔드 팀에게 요구하는 과정에서 미스 커뮤니케이션이 많이 발생했다. 나도 뭐가 필요할지 모르는 상태에서 그냥 개발을 시작하니, 나중에 백엔드에서 넘겨주는 데이터의 필드값 등이 일관성없이 넘어와 당황스러웠고, 넘겨주는 값과 받는 값의 격차를 줄이는 시간이 필요해 개발에 딜레이가 많이 있었다.
이런식의 협업은 나나 백엔드 팀원들 모두 처음이라 함께 일하기 위해서는 어떤 것들을 미리 정해야하는지 몰라서 더 어려웠던 것 같다.
앞으로는 초반에 요구사항 분석을 더 세분화하고 철저히 해서, 시작부터 백엔드와 어떤 값들을 어떤 이름으로 넘겨받을지 정해야겠다.

▪️여러 프로젝트를 계속 하다보니 요구사항을 분석하고 이슈를 나누는 데에 어느정도 익숙해졌다. 언제까지 얼마나 진척이 될 지 가늠할 수 있게 된 것 같다.
요구사항 분석은 당연히 철저히 해야만 하고, 어디에서 어느때쯤에 서버와 통신이 이루어져야 할지도 이제는 눈에 그려진다. 어떤 데이터가 오가야 할지 정리하고, 그걸 기반으로 서버 개발자와 이야기한다. 어떤 이름으로 넘겨받을지보다 중요한 건 어떤 타입인지, 안 들어가도 되는 값인지이다. 프로젝트를 여러번 반복 할 수록 서버 개발자와 커뮤니케이션 하는 데에도 요령이 생긴 듯 하다. 하하.

- 2020.6.29

2. Mock API를 만들어서 쓰자

프로젝트 초중반에는 화면을 만들고, 기본적인 동작들을 구현했다. 그런 과정들이 어느정도 마무리되고 서버와 통신을 할 시점에, 다행히도 우리팀 백엔드들이 배포를 해줘서 실제 서버와 계속 통신하며 개발을 할 수 있었다.
헌데 얘기를 들어보니, 데모 바로 전날 배포가 된 팀도 있었다.
다음번 프로젝트를 진행할때도 내 개발 속도와 서버 개발속도가 맞아서 실서버로 통신하며 개발할 수 있다는 보장이 없다. 그러니 Mock API를 만들고 그것을 사용하는 구조로 만드는 것이 백엔드의 개발 속도에 상관없이 iOS를 개발할 수 있으므로 속편할 것 같다.. 그러려면 당연히 앞서 말했던 요구사항 분석을 철저히 하고 사용하는 값에 대한 명확한 명세가 나와야만 가능할 것이다.

▪️ 이 글을 쓸 당시는 mocky.io 같은 도구를 이용해 가짜 api를 만들어 쓰자는 말이었는데, 그렇게 하면 mocky에 의존성이 생기게 되고 실 서버 엔드포인트와 mocky 엔드포인트를 각각 관리해야 한다. 또한 json 데이터를 수정하고 싶은 경우에는 또 엔드포인트를 만들어야하는 번거로움이 생기게 된다. mock api를 만드는 것 보다, 프로젝트 내에 stub으로 json 파일을 만들어놓는 것이 변경에도 용이할 뿐만 아니라 mocky에 의존성도 줄일 수 있어 mock api가 아닌 stub data를 만들어 쓰는게 나을 것 같다.
- 2020.6.29

3. 설계는 생각보다 더 중요하다

프로젝트가 중후반에 접어들면서 새로운 기능들이 계속해서 추가됐다. 데모 날짜는 다가오는데, 구현하지 못한 기능들이 있어 리팩토링이나 구조에 대해 신경을 쓰기보다는 이미 만들어놓은 구조에 새로운 기능들을 계속해서 추가하는 식으로 작업이 이루어졌다.
그러다보니 처음에 설계를 잘 해놓고 각 객체들의 책임과 역할을 명확히 분리해놔야 이후에 기능을 변경, 확장하거나 추가할 때 보다 덜 복잡하게 할 수 있을 것 같다는 생각이 들었다.
기간 중반을 지날 무렵 코드에 대한 피드백을 받았다. 리팩토링을 하려고 했으나.. 구조에 대해 신경쓰면 기능 구현을 완성하지 못할 것 같고.. 기능 구현을 하자니 코드가 너무 더러웠다.
결국 명확한 역할과 책임을 가진 코드들을 분리해내지 못하고 기능구현에 초점을 맞춰 프로젝트를 마무리했다.
.
솔직히 아직까지 어떤 구조가 좋은 구조인지, 그리고 그렇게 짜려면 어떻게 해야할지 잘 모르겠다. 그래서인지 프로젝트 하나를 마무리 했어도 뭔가 성장했고 잘하고 있다는 느낌을 받기가 어렵다. 좋은 구조에 대한 갈망이 있으나 시간은 없어 아쉽다.

▪️이 글을 쓰고 2달이 지났다. 그동안 대략 4번의 프로젝트를 더 진행했다.
2개월은 성장하기에(혹은 익숙해지기에) 충분한 시간인 것 같다.(갑자기?ㅎㅎ) 이때는 프로토콜이나 상속, 익스텐션을 활용한 추상화 하는 것이 너무 어렵게만 느껴졌었다. 그렇지만 지금은 어떻게하면 뷰를 하나만 만들어놓고 재사용 할 수 있을지, 어떻게 하면 반복되는 코드를 줄일 수 있을지에 대해 조금 더 익숙..해진 것 같다.
개발하는 도중에 요구사항이 변경되거나 한 적은 아직 없어서 지금 짜는게 변경에 용이한 구조가 맞는지 확신은 없으나, 프로토콜이나 상속으로 추상화를 하게 되면 이후에 새롭게 추가되는 부분에 대해서만 작성하면 되는 형태이니까 나름 괜찮게 한것도 같다. 이것도 두달 뒤에 보면 또 다르려나?
좋은 구조가 뭔지 잘 몰랐었는데, 지금은 조금 알 것 같다. 변화와 재사용에 용이한 구조. (중복을 제거해) 각각 자기가 맡은 책임을 다 하는 구조.
일단은 여기까지..
-2020.6.29

오늘 서점에 가서 조영호님의 오브젝트를 구매했다. 첫번째 챕터 시작부분에, 소프트웨어 설계에 중점을 두려면 이론이 아닌 실무에 초점을 맞추는 것이 효과적이라 했다. 그말인 즉슨 계속해서 코드를 짜면서 배워야(느껴야)한다는 거겠지.
지난 화요일 티타임때 JK가 잘 모르겠으면 뭘 나누려하지말고 일단 뷰컨트롤러에 다 때려넣어보라고 했다.. 그 이후에 공통적인 역할을 하는 놈들을 묶고, 중복을 제거하는 식으로 나눠보던가 해야겠다