[팀 프로젝트] 갤러리 뷰 Fragment 구현 완료 - 개발 회고록

들어가며

이번 포스팅의 목적은 이틀이라는 시간동안 연속 작업을 기반으로 UMC 3기 "당신의 발자취" 안드로이드 개발 파트에서 맡은

갤러리 뷰 중 Fragment 작업을 완료 후 개발하면서 느꼈던 점, 새롭게 배운점을 기록하기 위해 포스팅한다.

 

# 사담

개인적으로 학기 중에 UMC 3기 활동말고도, 되게 다양하고 많은...ㅎㅎ 활동을 했기에

안드로이드 개발 공부를 별로 못했었다.

그래서, 안드로이드 개발 지식이 그렇게 풍부하진 않지만, 핵심적인 안드로이드 개발 요소들만 알고 있는 채로

이번 프로젝트에 내가 맡은 부분에 대한 구현을 시작하였다.

 

# 포스팅의 방향성

이번 포스팅에선, 개발에 대한 직접적인 스킬보다는, 안드로이드 개발 지식이 부족했음에도,
구현하고자 하는 바를 비교적 빨리 구현해낼 수 있었던 이유를 기록한다.

그리고, 그 과정들에서 느꼈던 점과 새롭게 배운점을 기록한다.

 

---

구현 설계

이번 프로젝트에서 내가 맡은 사항에 대해서 구현에 시작하기 앞서,
구현하고자 하는 바에 대한 설계를 진행했다.

 

설계는 내가 구현해야 되는 "뷰"는 어떤 구조로 개발이 되어야 하는지에 대한

설계를 진행했다.

 

# 앱 디자인을 토대로 구현할 사항 이해

내가 맡은 파트가 앱의 어떤 부분에서 구현이 이루어지는 지를 확인한다.

그리고, 내가 맡은 파트인 갤러리 뷰에서 이루어지는 동작들을 디자인을 보면서 이해한다.

정리하면, 디자인을 보고 "갤러리 뷰"에서 구현해야할 안드로이드 개발 요소(안드로이드 핵심요소)들을 로직 별로 정리했다. (설계했다.)

 

# 로직 별로 안드로이드 개발 요소 기반으로 설계

• GalleryFragment 개발로직 확정
  1. GalleryFragment에서 리스트 조회 구현
     1. Service에서 더미데이터 생성
     2. GalleryFragmnet 메소드로 Service에서 만든 더미데이터를 받아서 RecyclerView로 구현
• 더미 데이터 RecyclerView로 뿌리기
  
  • 날짜별 카테고리로 리스트 조회
  • Grid 형태로 RecyclerView Sub Item 뿌리기

개발 설계는 GUI 디자인을 보고서
구현할 사항에 대한 동작들을 이해했고, 이를 기반으로
로직 별로 안드로이드 핵심 개발요소들을 설계했다.

# 개발 설계를 진행했던 로직 (생각의 흐름)
구현 시작할 공간이 "안드로이드 스튜디오"이기에, 이에 맞춘
안드로이드 핵심 개발요소들을 기반으로 설계를 진행했다.

설계를 하면서, 구현안해본 것들이나
애매한 것들은 직접 검색 (구글 검색)을 해보면서, 구현하는 방법이 존재하는 레퍼런스들을 찾았다.
(레퍼런스를 토대로 구현이 가능하다고 생각이 들면, 노션에 킵해둔다.)
레퍼런스를 토대로 구현하는 방법을 터득한 후 레퍼런스는 "노션" 같은 곳에 따로 기록해두고,
새롭게 알게된 "안드로이드" 개발 요소들을 가지고 설계를 하면서 막혔던 부분들에 대해 로직 별로
최종적으로 정리한다. (설계한다.)

 

---

템플릿 구성

이번 프로젝트는 백엔드 개발자와 함께 협업해서

프론트 - 백엔드 기반으로 구성된 "앱 서비스"를 제작하는 프로젝트이다.

최종적으로 프론트 개발은 백엔드에서 제공하는 API를 토대로
앱 서비스를 제작해야된다.

그래서, 초기 프론트 리소스만으로 개발을 시작하는 현 시점부터
추후에 백엔드 API를 받아서 엮을 때 사용하는 개발 로직으로 구현을 해두었다.

 

"당신의 발자취"의 "안드로이드" 팀은 MVP 패턴 기반인
개발 템플릿으로 정하고 개발을 진행했기에 이를 기반으로
구현할 공간에 대한 템플릿을 구성해두었다.

 

# 템플릿 구성 시작

템플릿 구성은 앞서 정리해둔 구현 설계를 기반으로 쉽게 진행할 수 있었다.

구현 설계를 "안드로이드" 개발 환경 바탕으로 진행했기에, 이를 MVP 패턴 기반으로
필요한 클래스들을 정의만 하면 되었다.

 

# MVP 패턴 이해

우선 MVP 패턴 기반으로 앱 구현이 어떻게 이루어지는 지를 예제 템플릿 코드를 참조하면서 쉽게 이해하였다.

(UMC 3기 안드로이드 개발 템플릿 짱...)

예제 템플릿 코드를 보면, 백엔드 API 데이터들을 관리하는 로직을 쉽게 이해할 수 있고,

이를 기반으로 내가 구현해야 될 갤러리 뷰에서 API 응답 데이터를 관리하는 로직에 대한 템플릿 구성을 진행했다.

 

# 템플릿 구성 완료

템플릿 구성방법은 답이 정해져 있는 것이 아니기에, 구성 방법에 대한 상세 설명은 생략하도록 하겠다.

한가지만 말하자면, 자신이 사용한 템플릿의 아키텍처 패턴을 이해하고, 템플릿 구성을 한다면,
자유자재로 구현에 성공할 수 있을 것이다.

 

 

# "간이 개발 로직" 설계

흔히 말해, Top-Down 방식으로 구현을 시작했다.

이 부분부터 구현이라고 생각이 들겠지만, 템플릿 구성하면서 함께 진행했기에,

나는 설계라는 부분에 넣어두었다.

Top-Down 방식은 한국어로 직역하면, "하향식 설계"라고 불린다.

구현할 사항에 대해선 앞에서 구현 설계를 진행했다.

이를 기반으로 템플릿 구성을 진행하는데, 이때 코드로 간략하게 로직별로 "코드 설계"를 해둔다.

구현 설계에서 정리한 바로 구현하기 위해서, 어떤 로직이 필요하고, 어떤 메소드가 필요한지를 간략하게 작성해두는 것이다.

나는, 로직 별로 구현해야할 사항을 머릿속으로 생각하면서, 구현에 성공하기 위한 메소드들을 기록해뒀고,

그 메소드들이 어디에서 호출해야지 원하는 바를 구현할 수 있을 지에 대해서도
기록한 메소드들을 호출하는 구문까지 작성해뒀다.

 

# 정리

정리하면, Top-Down 방식으로 "run" 버튼을 클릭해 앱을 실행하면,

실행 오류가 뜨지만, 템플릿에 코드를 설계한 대로 작성이 완료되었을 때, "run" 버튼을 클릭했을 때 앱을 실행하면,
원하는 바가 뜰 수 있도록 템플릿 "간이 개발 로직" 설계를 진행했다.

- Top-Down 방식으로 개발을 진행하기 위해선, 정의해둔 메소드가 자신이 구현가능한 수준의 로직으로
설계를 해둬야 가장 이상적인 설계이다.

- 그럼, 개발 수준이 올라가면 갈수록 Top-Down 방식으로 설계는 더욱 단순해 질 수 있다.. (알고리즘 공부를 하는 이유..!)

 

# 느낀점

확실히 개발하면서 안정적으로 개발을 진행할 수 있었다.

난잡하게 코드가 얽히고, 로직이 불분명해지는 경우를 줄일 수 있었서
효율적인 개발 방식이라고 생각을 하게 되었다.

구현해야할 사항에 대해서 미리 설계를 해두고, 설계한 영역에 대한 세밀한 부분에 대해서만
작업을 진행하면 되니깐, 전체적인 개발 시간을 두고보았을 때도,

더 빠르게 구현을 완료할 수 있었다.

---

구현 시작

구현은 앞서 진행한 구현 설계, 템플릿 구성과정 덕분에 쉽게 이뤄질 수 있었고,

개발하면서 복잡해지고, 로직이 해결할 수 없을 정도로 어려워지는 경우는 없었다
단순히, 설계한 바를 토대로 구현될 수 있도록 코드만 작성하면 되기에, 쉽게 개발할 수 있었다.

 

구현하면서 배웠던 점은

디버깅하는 방법이다.

그리고 객체 기반으로 코드를 작성할 때 유의해야할 점들을 새롭게 배울 수 있었다.

그래서 "구현 시작" 부분에 대해선 실제로 구현을 하면서 새롭게 배운점과 느낀점들을 기록하니,
이 점을 참고해서 글을 읽어주길 바란다.

 

# 콘솔 로그는 버그의 GPS

콘솔 로그를 통해 원치않은 실행결과에 따른 원인을 쉽게 추적할 수 있다.

로그는 실행 코드 중간중간에 삽입하여 Console 창에 실행코드에 대한
변수나 메소드 호출값을 띄울 수 있다.

 

콘솔로그 사용법, 정석은 존재하지 않다.

로그를 찍지 않고, 단순히 머릿속으로만 연산을 진행해서, 버그를 찾는 건
복잡하고, 시간도 오래 걸린다.

그냥 로그를 찍어보고, 직접 눈으로 그 값들을 확인해보면서 추상화된 코드를 이해하면 쉽게 버그도 찾고,
원인에 대한 해결책을 제시할 수 있다.

 

사실, 나도 아직까지는 로그를 제대로 찍는 방법을 잘 모르긴하다.
근데, 이번에 개발하면서 도저히 해결하지 못할 것같은 로직을 콘솔을 찍어보면서,
버그의 원인 영역을 줄여나갈 수 있었고,

그에 따라 버그가 어디서 발생하는지를 쉽게 찾을 수 있었다.

 

정리하면, 콘솔로그는 버그의 원인 영역을 좁혀주는 좋은 도구라는 생각이 든다.
머릿속으로 추론하면서 버그의 원인 지점을 찾는 건 넓은 영역 속 하나의 버그 덩어리를 찾는 것과 같다.
하지만, 콘솔로그를 통해 버그의 원인 영역을 축소시켜 쉽게 찾을 수 있는 것 같다.
코딩하면서, 디버깅을 해야할 때는 일단 뭐라도 찍어보자는 마인드로, 콘솔 로그를 찍는 습관을 들이자.
귀찮지만, 그게 제일 빠른 길이고 효율적이다.

 

# 코딩 로직이 생각나지 않는다면, 처음부터 시작하자

더미 데이터를 생성하고, RecyclerView로 더미 데이터를 뿌려주기 위해
이에 맞춘 데이터 형태로 가공해야 되는 상황이었다.

 

더미 데이터 -> RecyclerView에서 사용할 데이터 객체로 바꿔주면서 깨달은 바이다.

더미 데이터는 유저의 모든 게시글 정보를 지니고 있다.

게시글 사진, 위치, 등록날짜, 좋아요 수 등등

RecyclerView로 조회하기 위해선 더미 데이터를 "등록 날짜"를 카테고리로 삶아서
같은 날짜에 있는 게시글을 그룹화해서 저장해야 되는 상황이었다.

이 부분에 대해서 구현을 하면서 새롭게 배운 점이었다.

 

"코딩 로직이 생각이 나지않거나, 어렵다고 느껴진다면,
주석을 처리하고 처음부터 시작하자" 라는 것이다.

 

나를 비롯한 대부분 사람들은 코딩을 하면서 구현하고 있던 로직에 대해서
구현이 된다고 생각하고 "실행"을 해보면 실망하거나, 낙담하기 마련이다.

그래서, 다시 원래 있던 코드를 살펴보면서 디버깅을 하는 것이 보통이다.

원래있던 코드를 디버깅하면서, 구현에 성공하면 좋긴하다.

하지만, 원래있던 코드를 연속적으로 디버깅해서 코드를 수정하면,
코드가 산으로 갈 상황이 초래될 수도 있다.

이때, 지금까지 작성해뒀던 코드가 아깝더라도, "주석"을 해두고
새로운 개발 로직을 구성하는 것을 추천한다.

이는, 복잡하게 얽힌 코드로 구현을 성공하더라도, 나중에 똑같은 방식으로 개발을 진행하는 가능성은 희비하기 때문이고,
개발에 대한 시야를 좁힐 수 있다.

마치, 이러한 사항을 개발하려면, 저번에 경험처럼 이렇게 구현을 해야돼! 라는 고정관념에 사로잡혀버릴 수 있기 때문이다.

그래서, 처음부터 아예 새로운 개발 로직으로 개발을 시작하는 것이
새로운 개발 관점을 경험할 수 있을 뿐더러 더 쉽고 빠르게 구현에 성공할 수 있다.

 

# 코딩 로직에는 "정답"이 없다.

그래서, 주어진 상황에 대한 적합한 “로직”을 구현하려고 신경쓰고, 처음에 생각해낸 발상을 고집하진 말자.
많은 시도를 해보면서 주어진 상황에 적합한 “로직”을 구현하는 것이다.

 

 

# 레퍼런스를 참조해서 개발할 때는, 추측해서 개발하지 말고,
있는 그대로 가져와서 코딩하자

뇌피셜로 이렇게하면 되겠지하다간, 하나의 실수로 모든게 구현이 안되는 상황이 초래될 수 있다.
(TMI로, 이번에 구현하면서, XML 파일을 내 맘대로 바꿨다가, RecyyclerView가 제대로 안띄어지는 오류가 있었다..)

# 레퍼런스는 "여러 개의 레퍼런스"를 참고하면서,
원하는 바를 구현하자

구글은 엄청나게 많은 레퍼런스들이 있다. 지금 학부생 기준으로 충분히 학습할 수 있는 레퍼런스들은 충분하다.
그래서, 구글의 레퍼런스를 참조하다가 구현이 막힐 때는 또 다른 레퍼런스를 참고하자.
하나의 레퍼런스만 보지말고, 여러 개의 레퍼런스를 보면서 내가 구현하고자 하는 원하는 것들을 구현할 수 있도록 하자.

 

정리하면, 하나의 레퍼런스만을 "고집"하지 말고, 비슷한 파트의 여러 레퍼런스를 참고하면서
핵심적인 내용을 축약해서 구현을 하자.
구현에는 정답이 없기에, 여러 레퍼런스를 보면서 구현하는 시야를 넓힐 수 있다.

---

구현 완료

- RecyclerView를 이용해 Fragment 상에서
날짜별 카테고리로 발자취 리스트를 조회하는 뷰를 구현하였다.

- 스크롤 하면서 조회된 데이터를 확인할 수 있다.

---

마치며

이번 "당신의 발자취" 안드로이드 개발자로 참가하게 되면서
내가 맡은 파트인 "갤러리 형태로 발자취 게시글 조회 뷰"를 구현을 진행 중이다.

 

내가 맡은 사항 중 1/3 가량 개발이 완료된 상태이고, 이번 포스팅을 통해 1/3을 구현하면서 새롭게 배운점 느낀점들을 기록해두었다.

 

이 포스팅을 쓰면서 정리된 생각은
개발을 진행하기 전에도 "개발 환경"에 맞춘 설계를 진행해두고 시작하면 효율적으로 개발을 완료할 수 있다는 점이 구체화되었다.

그리고, 설계는 "일정한 방향성" 대로 진행하면, 쉽게 설계할 수 있다는 점도 깨달을 수 있었다.

(여러 명이서 설계를 하는 것이 아닌, 내 생각, 혼자서 설계하면서 구체화를 진행)

 

# 개인적인 사담

이번 프로젝트하면서도 많이 성장하고 있는 듯하다.

비록 이번 프로젝트는 이전 프로젝트에 비해, 나의 자리가 배우는 자리, 따라가는 자리가 아닌, 가르쳐주는 자리, 리드하는 자리이다.
처음에는 더 많이 "배워보려고" 들어왔던 프로젝트인데, 내가 가르쳐주고, 리드해야되는 자리에 들어서니,
심적으로 감당이 어려웠고, 많이 불안하고 힘들었다.

그치만, 지금은 많이 극복한 상황이고, 이전 프로젝트 때 "빙글"님께 정말 말로 표현할 수 없을 정도로 많은 걸 배웠던 경험처럼

나도, 팀원들에게 "빙글"님께서 가르침을 받았던 느낌이 들도록 프로젝트를 진행하는 방법에 대해서 공유하면서 함께 성장하는 사람이 되도록 노력할 것이다.

 

정말 삶은 내가 꿈꾸는 대로 이루어지는 것 같다.

7개월 전만해도, "빙글"님처럼 프로젝트를 이끄는 자리에 가보고 싶었는데, 그게 2023년 1/3일부로 실현되었다.

꿈이 실현된 만큼, 절대 거만해지지 않고, 항상 배우는 자세로 새로운 소망을 가지며
새로운 것들을 배워보고 실천해나갈 예정이다.
그리고, 앞으로도 남들이 하라고하는 것들이 아닌, 오직 내가 원하는 것들,
꿈꿔왔던 일들을 실천할 것이며, 내 소망과 일치하는 활동들을 할 수 있도록 노력할 것이다.

 

 

이 글을 마치며,
군대 가기 전 사실상 마지막 프로젝트? 라고 볼 수 있는 겨울방학 UMC 앱 런칭 프로젝트를 성공적으로 완수할 수 있도록
책임감있게 행동할 것을 나와 약속하고,
앞으로 남은 프로젝트 기간내내 팀원들에게 감정적으로 반응하지 않고,
이성적으로 행동하는 존재가 되도록 노력할 것이다.

그리고, 2023.02.15 데모데이에 출전하여
대상을 노려볼 것이다.