Written by Hyemin
on 

[서울시 앱 공모전] I Time U:
프로젝트를 마치며

서울시 앱 공모전에 제출할 안드로이드 앱 I Time U의 버전 1.0.0 릴리즈를 완료했다. 아직 공식적인 제출은 하지 않았지만 곧 제출 예정이다. 개발 기간은 7월 23일부터 9월 21일까지, 꼭 두 달 정도가 걸렸다.

서울시 앱 공모전 웹페이지

I Time U github 저장소

프로젝트를 마쳤으니 그간의 진행 플로우에 대해서, 그리고 아쉬웠던 점에 대해 기록하고자 한다.

프로젝트의 시작

이번 프로젝트는 ‘여름방학인데 안드로이드를 공부하고 개발 경험도 쌓아보자’ 라는 취지에서부터 시작됐다. 실전 경험으로부터의 학습이 빠른 성취를 선사해주기도 하니까 말이다! 삽질도 많아진다는 게 문제

열흘 정도 git과 github를 숙지 하는 기간을 갖고(사용방법에 익숙한 사람도 있었지만 그렇지 않은 사람도 있었기 때문이다), 그 이후 공모전 주제에 대해 논의 하며 안드로이드 개발을 위한 최소 지식을 얻기 위해 Udacity에서 안드로이드 초급 강좌 를 수강했다.

+이미지의 계획에선 기간이 한 달 가량(!)으로 잡는 패기를 보였지만방학 마지막 주는 쉬고 싶었다 사실 다들 개발이 더 길어질 걸 예감하고 있었다.

실질적인 개발을 구현하기 전 서비스 화면을 구성했는데, 대략적인 구조는 다음과 같다.

그리고 각각의 액티비티에 대한 세부 기능과 그 설명을 작성했었다. 물론 완성된 구조를 보면 내용의 변동/추가가 존재하지만, 그래도 의도한 결과에 지장은 없었다.

개발한 기능

필자가 개발한 모듈은 크게 세 가지로 나뉘며 대략적인 설명은 다음과 같다.(앱에 대한 소개와 사용자 매뉴얼은 저장소 페이지에 잘 정리되어 있다.)

세부 설명(1) - List

  1. 달성률
    리스트에 오늘의 달성률을 표시한다. 퍼센티지와 (완료한 세션 갯수)/(총 세션 갯수)
  2. 날짜 지정(옵션)
    날짜를 클릭하면 날짜를 선택할 수 있는 창이 뜨며, 날짜를 선택하면 해당 날짜에 생성된 아이템만 리스트에 출력된다.
  3. 아이템 추가
    플러스 버튼을 클릭할 시 활성화 되며, 하고자 하는 일의 이름(필수 값)과 일의 분량을 지정하여 리스트에 새로운 아이템을 추가한다. 새로운 아이템(To Do status)은 스택 기법을 사용해 리스트의 최상단에 위치하게 된다.
  4. 아이템 수정 및 제거
    리스트에 있는 아이템(To Do status)을 길게 클릭할 경우 수정/삭제 중 하나를 선택할 수 있다. 수정 시 아이템의 이름과 분량을 수정할 수 있으며, 삭제 시 아이템이 리스트에서 제거된다.
  5. 아이템 스테이터스 종류 - To do, Doing, Done :
    • 아이템 활성화 리스트에 있는 아이템(To Do status)을 짧게 한 번 클릭할 경우&리스트 상단에 위치한 날짜가 현재의 날짜와 일치할 경우 타이머가 시작된다.(Doing status)
    • 아이템 비활성화 지정한 시간이 지나면 아이템이 비활성화(Done status) 되며, 색상이 변경된다. 클릭해도 타이머가 시작되지 않는다.

세부 설명(2) - Statistics

  1. 통계 :
    • 달성률(수치) - 완료 개수 / 전체 개수 (100%)를 화면에 출력
    • 그래프 출력
  2. 출력 단위 :
    • 주 단위 - 한 주 단위로 사용자의 세션 달성률을 표시한다.
    • 월 단위 - 한 달 단위로 사용자의 세션 달성률을 표시한다.
    • 커스텀 - 사용자가 지정한 일자의 사용자 세션 달성률을 표시한다.

세부 설명(3) - About

  1. 앱 버전 출력
  2. 라이센스
  3. 피드백 - 메일 인텐트 연결
  4. 지원하는 언어 - 영어 / 한국어

아쉬웠던 점

개발 완료 후 팀원들과 피드백을 나누었고, 아래와 같은 내용이 나왔다.

개발 과정에서의 아쉬움

  1. 유닛 테스트를 사용하지 않음
    유닛 단위의 테스트 없이 진행을 해서 디버깅에 시간이 적지 않게 걸렸던 것 같다. 다음에는 유닛 테스트+자동화 유닛 테스트를 시도해보면 좋겠다.
    TDD Unit test tutorial
  2. 코드 리팩토링 & 디자인 패턴: 코드의 가독성이 낮고, 단위가 크며, 상호 종속성이 높다.
    이 부분은 유닛 테스트 시도 & 클린 코드 강의(학교 수업)를 수강하면서 보다 나아질 것으로 전망된다.
  3. 풀 리퀘스트(PR)를 통한 리뷰의 부재
    이 부분은 시간이 빠듯했기 때문에 어쩔 수 없다고 여겨지는 부분이긴 하다. 하지만 졸업작품을 할 때는 리뷰 기간을 정해두고 어느정도 의무성을 띈 리뷰가 이루어졌으면 좋겠다. 이번 프로젝트에서는 서로가 서로의 코드에 대해 전혀 이해하지 못했다.(기껏해야 함수 호출 정도만 함)
  4. 페어 코딩의 부재
    페어 코딩에 대해서는 시간이 많이 걸릴 것 같다는 우려를 들은 바 있으므로, ‘그렇지 않다’라는 취지로 설명을 하고자 한다.

    내 경험에 따르면, 짝을 지으면 두 배 이상 생산적이된다. 혼자 했을 때와 짝 지어 했을 때를 비교해 보면, 작업을 완료하는 데 필요한 실제 시간(디버깅 시간도 포함해서)은 혼자 했을 때가 두 배 이상 걸렸다. 따라서 짝 프로그래밍을 하면 깔끔하고 완성된 코드를 사실상 더 일찍 들고 나올 수 있다. 짝의 가치와 개인의 가치를 비교할 때에는, 실제로 배치될 만한 코드를 만드는 경우의 생산성과 소요 시간을 둘 다 포함해야 한다.- 익스트림 프로그래밍(Extreme Programming), 켄트 벡(Kent Beck)

    페어 프로그래밍으로 배우는 프로그래밍-by Gyujin Cho

    일단 시간적인 부분은 문제가 되지 않음을 알 수 있다. 물론 위의 링크를 포함해 긍정적인/부정적인 피드백이 있다. 하지만 시도해볼만한 가치(일의 효율+실력 향상+팀워크에 대한 자세 함양)가 있다고 생각한다. 단, 시도할 경우 주의사항을 사전에 숙지+점진적 적용을 할 필요가 있다.
  5. Push를 늦지 않게 한다
    개발 과정에 대한 업데이트가 빠르게 진행되도록 한다.
  6. Requirement 문서 작성을 보다 자세히 하자
    구현을 할 때, 예상했던 것보다 추가되는 기능이 많아서 어려움이 있었다.

팀 의사소통에서의 아쉬움

  1. 팀원 간 개발 진도에 대한 공유 필요
    이번 프로젝트에서는 이슈에 어느 기간 동안 무엇을 할 지 적었다. 하지만 개발 기간을 산정하는 어려움이 있었다. 개발 기간이 느려지거나 빨라질 경우, 팀원이 그를 바로바로 알아차리지 못했다는 부분이 아쉬웠다. 주변에 조언을 구해서 나름의 해결 방안으로 얻어왔다. 매일 저녁 ‘오늘 한 일 / 방해요소 / 앞으로의 할 일’을 슬랙에 공유하여 상대 팀원의 진행도를 파악할 수 있게 한다.
  2. 개발시간 지정
    시간을 정해놓고 개발을 하자. 일할 땐 일하고 쉴 땐 쉬면서 효율을 높이자는 취지이다.

결론

사실 git/github를 팀원 모두가 사용해 개발을 진행한 건 이번이 처음이다. 그리고 안드로이드로 프로젝트를 해본 것 역시 처음이다. 이로 미루어 볼 때, 최초의 의도대로 앱의 빌드를 완료했다는 점과 전체 기능을 모두 구현했다는 건 꽤 뿌듯한 일이었다.

이번의 경험과 느낀 점을 바탕으로 앞으로도 개발 실력이 꾸준히 상승했으면 하는 바람이다! :)