이번 회고는, 지난 하반기 동안 제가 나름 잘했다고 생각되는 것들과 아쉬운 것들을 정리해 보는 식으로 작성해 보려 합니다.
잘한 것
PR 상세히 쓰기
이전까지는, 아무리 큰 규모의 코드를 작성 하더라도, 어디까지나 큰 프로젝트의 일부분을 제가 구현하는 방식이었다면, 교정서비스는 제가 프로젝트 하나를 온전히 작성한 프로젝트였습니다. 그러다보니 코드의 맥락을 팀원과 공유 하기가 매우 어려웠습니다. 팀원 입장에서는 계속 바뀌는 기획에 대한 팔로우업이 충분히 이뤄지지 않는 상황에서 오직 코드만 보고 코드의 의도를 파악하기란 굉장히 어려운 일 이었을 테니까요. 이런 상황에선 PR을 올려도 팀원으로부터 제대로 된 리뷰를 받을 수 있을 거란 기대를 하기 어려웠습니다. 이대로 PR을 올려서 approve를 받는 일은 요식행위 밖에 되지 않는다고 생각했습니다.
그래서 이 즈음부터 의도적으로 PR을 의식적으로 더욱 자세하게 쓰기 시작했습니다. 관련된 Jira티켓 링크는 물론이고, 구현한 화면의 작동 예시를 보여주는 동영상이나 이미지를 첨부하고, 기획의 의도나 기획이 바뀌게 된 배경을 충분히 설명하려 노력했습니다. 자연스레 PR을 작성하는데 꽤 많은 시간이 소요 되었지만, 이는 나중에 여러 형태의 보상으로 돌아왔습니다.
예를 들어, PR자체가 문서로서의 기능을 하게 되니, 리그레션을 잡아내는 일이 훨씬 쉬워졌습니다. 물론 기존에도 PR 및 커밋에 지라 이슈 티켓을 첨부해 리그레션을 예방 하려 노력 하고는 있었지만, 사람의 심리가 그 링크들을 일일이 열어보지 않게 되더라고요. 또 이슈티켓에서 논의되는 내용과, 그 논의의 내용을 코드로 구현하는 과정에서 논의해야 하는 내용은 별개 이기도 합니다. 그런 맥락에 대한 내용이 PR안에 있으니, 다음과 같은 방식의 작업방식이 가능 해졌습니다.
•
이슈발생
•
문제가 되는 라인 찾음
•
해당 라인의 git blame 확인
•
해당 커밋에 해당 되는 PR확인
•
왜 그런 라인이 있었는지에 대한 맥락 확인 & 리그레션이 일어날 수 있는 여지 유추
•
이슈 수정 후 리그레션 체크
•
새로운 PR에 다음의 내용 작성
◦
어떤 문제가 있었는지
◦
왜 이 수정이 문제를 해결하는지
◦
그런데 그 코드는 왜 있었는지
◦
그 코드가 당시에 수정한 문제가 재발 되지는 않는지
실제로 이런 작업 방식을 통해 예상치 못한 리그레션 몇 개를 잡아내고 나니, PR 작성에 들이는 시간은 별 것 아니게 느껴졌습니다. 버그를 수정 함으로써 새로 생긴 버그를 발견하기까지 적지 않은 시간이 걸리게 되고, 또 그렇게 늦게 발견한 버그를 수정 할 때 기존의 수정에 대한 맥락을 모르는 상태로 버그를 수정해서 또다른 버그를 낳고 …. 이런 과정에서 낭비할 시간들에 비하면, PR작성에 공을 들이는 것은 충분히 남는 장사인 것 같습니다.
지라의 Time Tracking기능 활용
간단한 사이드프로젝트로, 제 포모도로 앱에 지라를 연동시켜서, 포모도로 세션이 끝날 때마다 작업중인 티켓에 작업한 시간을 기록하도록 만들었습니다. 이 과정에서 “작업시간”도 지라가 관리하는 여러 자원 중 하나라는 것을 알게 되었습니다.
처음에는 그저, 제가 작업한 시간을 기록하는 용도로만 사용했는데, 이를 기록하고 보니 그림에 보이는 것 처럼 “Estimated”라는 개념이 있다는 것도 알게 되었습니다. 즉, 지라 티켓은 원래 “일정을 추산하고, 그 일정이 잘 지켜졌는지 트래킹하고, 또 회고 할 수 있는” 툴이었던 것이죠.
이 기능을 알고, 적극 활용하기 시작했습니다. 어떤 티켓이든 일정을 미리 추산하고 보니까, “일정 추산”이라는 것도 연습하면 더 숙련되는 기술의 일종이라는 생각이 들었습니다. 자꾸 하다보니까 더 잘 하게 되더라고요. 물론 더 큰 규모의 일정을 추산하는 것은 여전히 어려운 일이지만, 그래도 작은 단위로 계속 더 경험을 쌓아가면 앞으로 더 정확한 일정을 추산하게 될 수 있을거라 생각합니다.
아쉬운 것
SwiftUI
아무래도 교정서비스 런칭이 급박해서, SwiftUI를 제대로 파보고자 했던 다짐은 지키지 못했네요. 내년에는 좋던 실던 어떻게든 SwiftUI는 제대로 들여다 봐야 할 것 같습니다. 100 Days of SwiftUI를 훑고 나서는, 심플 포모도로 앱을 SwiftUI로 다시 만들어봐야겠어요.
개인앱 런칭
사실 무료 앱으로 런칭 할려고 하면, 런칭 할 수도 있는 부분 이었습니다. 하지만 애초에 새 앱을 만들게 된 계기가 “최소한 개발자 계정 비용만큼은 앱스토어에서 벌어보자”여서, 어떻게든 유료 앱으로 만들어야 했어요.
그런데 앱스토어에서 돈을 벌려고 보니, 생각보다도 작성해야 할 서류와 읽어야 할 문서들이 굉장히 많더군요. 사실 막상 맞닥뜨리면 별 것 아닐 수도 있겠지만, 괜히 겁에 질려서 엄두를 못내고 그냥 미적이며 기능 추가만 계속 하고 있네요.
앱스토어에 런칭하지 못한 것은 안타깝지만, 그래도 위에서 얘기한 것 처럼 재미있는 기능을 많이 추가하면서 여러 실험을 할 수 있었고, 또 Mac Catalyst를 적용해 볼 실험작으로 쓸 수도 있었기에 아주 큰 후회는 남지 않네요.
앱개발 소식 정리
가급적 매주 블로그 글을 작성하려고 하다보니, 자연스레 “다른 블로그들은 어떤 주제로 어떻게들 글을 쓰고 계시나”같은 것들이 많이 궁금했습니다. 그런데 생각보다 특히 iOS개발 관련해서 정기적으로 글이 올라오는 블로그들을 찾기가 쉽지 않더라고요.
현재는 iOS Dev Weekly, Indie iOS Focus Weekly, Swift Weekly Brief, Swift by Sundell 등의 영어권 뉴스레터등을 통해서 소식을 접하는데, 아무래도 한국어권 개발자들의 관심사 및 상황과는 조금 거리가 있기 때문에, 한국 개발자분들의 소식이 잘 정리된 뉴스레터 같은 것이 있으면 좋겠다고 생각하고 있습니다. 물론 그런 뉴스레터들이 없는 것은 아니지만, 아무래도 대부분이 웹개발 관련된 이야기들이 더 많더라고요.
iOS, 또는 모바일 개발 관련된 한국어 블로그 및 소식들을 전달하는 뉴스레터나, 또는 그런 블로그들을 모아놓은 링크라던가 하는 것들을 찾거나 만들어보려 하고 있습니다. 마침 iOS Tech Weekly Korea 라는 좋은 뉴스레터를 알게 된 것이 최근의 가장 큰 성과네요. 그래도 더 많은 한국어 개발 컨텐츠들을 접할 수 있으면 좋겠어요!
마무리
이번 하반기는 교정서비스 런칭에 파묻혀 지나갔네요. 내년에는 좀 더 여유를 가지고 SwiftUI등을 비롯한 신기술들을 열심히 배워봐야겠습니다.
추가
글을 쓰고 나서 2019년 개발자 회고 모음 이란 포스트를 알게 되었고, 여기서 국내 개발자 블로그를 큐레이션한 awesome-devblog 라는 서비스가 있다는 것을 알게 되었습니다. 내년엔 더 양질의 글들을 더 많이 읽을 수 있겠네요!