#1 현 개발 행태에 대한 문제점
#1-1 과정의 완벽주의
난 풋내기 프로그래머에 불과하다. 내가 만들 앱 또한 그저 그런 앱일 것이다. 적어도 처음 (출시할 의도로 만드는) 앱을 당연히 그럴 것이다, 아니 그래야만 한다. 그런데 나는 마치 정상급 앱 경영 콘테스트에 출품하는 것처럼 프로젝트를 만들어 가고 있다. 비유하자면 아주 사소한 돌부리만 발에 걸려도, 그걸 포크레인까지 동원해 철저하게 파고 평탄화 작업을 한 뒤에 안전 검사까지 하고 나아가는 셈이다.
최소한의 기능만 만들고 우선 출시부터 한다. 그리고 고쳐나가면 된다. 오히려 그 편이 더 '완벽'하지 않은가? 현재의 나는 결과의 완벽주의가 아니라 과정의 완벽주의를 좇고 있다. 어차피 사람들은 최종 결과만 보는 데 말이다. 나라고 다른가? 나 또한 다른 이들의 '작품'을 볼 때 결과만 본다.
#1-2 개발 로드맵의 부재
또, 로드맵도 없다. 이 또한 방금 말한 과정의 완벽주의 때문이겠다. 과정의 완벽주의가 있다면, 절대로 장기 계획이란 게 존재할 수가 없게 된다. 이제는 버리기로 했으니, 계획을 세워야 한다. 무언가를 장기적으로 창조해내려면 뒷받침되는 로드맵이 필요하다.
#2 계획을 완수하려면
#2-1 계획 완수의 판단 기준
관성을 무시할 수가 없다. 나는 아마 과정의 완벽주의에 끊임없이 유혹받을 확률이 높다. 따라서, 각 기능 별로 개발 시간의 데드라인을 부여해야한다. "어떤 기능을 만들었다"라는 말은 원래의 내게 있어서, 거의 논문급으로 정리된 문서ㆍ주석ㆍ가독성 높은 코드ㆍ테스트 작업까지를 의미했다. 하지만 이젠 정말 "발로 만든 것 같다"는 생각이 들어도 좋으니, 실행만 된다면 "어떤 기능을 만들었다"며 자체 판단하기로 약속한다.
#2-2 적절한 시간 배분
빨리 끝내려는 욕심에 스스로를 몰아붙이는 계획을 짜면 안 된다. 적절하게 널널히 끊어주어야 한다. 물론 말은 쉽다. 먼저 1차적으로 계획을 세우고 그에 기반해 계획을 진행하다보면, 분명히 개발 시간이 남아돌거나 혹은 부족할 수 있다. 이 경우 계획을 수정하겠다. 본 게시글의 제목이 '개발 일정표 (1차)'인 이유다. 계획을 수정하게 된다면 '개발 일정표 (n차)'와 같은 제목의 게시글을 다시 포스팅하겠다. 물론, 그 수정이 '과정의 완벽주의' 때문이어서는 절대 안 된다. '기능 완성'의 기준은, 일단 실행만 되면 OK다.
#2-3 여지
월 ~ 금은 개발을 하되, 토요일과 일요일은 비워둔다. 어떤 일이 생길지도 모르기 때문이다. 예를 들어 화요일에 어떤 사정이 생겨서 개발을 못했다면, 대신 토요일에 개발하는 식이다. 만약 내가 성실히 월 ~ 금을 개발에 매진했다면, 토요일과 일요일은 그냥 쉬겠다.
#3 구체화
#3-1 형태
개발 완수 == 어떤 기능을 완성 == 일단 실행은 됨 == "xxx를 통해 yyy를 확인할 수 있다."
(예) "'전송' 버튼을 눌러 전송된 정보를 LazyColumn에서 확인할 수 있다."
"xxx를 통해 yyy를 확인할 수 있다"라는 명제를 개발의 단위로 둔다. 이 명제를 충족한다면, 아무리 코드가 마음에 들지 않더라도 최소한의 코드 정리만 수행한 뒤에 넘겨버리겠다. 클린 코드를 지향하지 않겠다는게 아니라, 일단 출시부터하고 나서 리팩토링하려는 것이다. 코드가 너무 더러우면 나중에 손도 못댈 수도 있으니 최소한으로 정리만 하겠다는 얘기다.
#3-2 계획표
- [2024.12.31.화 ~ 2025.01.03.금]
"ChatBar를 통해 전송한 MealItem의 name 속성을 LazyColumn에서 확인할 수 있다."- [01.06.월 ~ 01.10.금]
"nutritionInfo 각 프로퍼티에 1대1로 대응되는 아이콘을 가져오거나, (못생겨도 좋으니) 제작하고 Jetpack Compose에서 잘 보이는 지 확인한다."- [01.13.월 ~ 01.17.금]
"아이콘 버튼을 터치하는 형식으로 nutritionInfo의 프로퍼티를 입력하고, 이를 LazyColumn에서 확인할 수 있다."- [01.20.월 ~ 01.24.금]
"LazyColumn이 보유하는 MealItem의 모양을 채팅 UI에 걸맞게 다듬는다. 또, '통계' 화면으로 가기 위한 네비게이션용 버튼을 만들고, 정상 작동을 확인한다."- [01.27.월 ~ 01.31.금]
"'통계' 화면를 캘린더 형태로 구성하고, 그 형태에서 하루 식단의 좋음/나쁨 여부를 확인할 수 있다."- [02.03.월 ~ 02.07.금]
"Hilt를 통한 의존성 주입을 수행하는 구조로 변경하고 정상 작동을 확인한다."- [02.10.월 ~ 02.14.금]
"앱 최초 실행 시, 앱 사용법 화면을 사용자가 확인할 수 있다."- [02.17.월 ~ 02.21.금]
"액티비티의 생명주기 및 Navigation Graph가 이상한 모양이 아닌지, 안드로이드 기기 화면 파편화에 앱 UI가 유연하게 대응하고 있는지 확인한다. 플레이 스토어에 노출할 앱 아이콘 및 이름을 정하고 업데이트한다. 만료되었던 안드로이드 개발자 계정을 복구한다."- [02.24.월 ~ 02.28.금]
"앱 프로젝트를 플레이 스토어에 제출하고, 제출된 앱에 대한 합격/불합격 여부를 확인한다."
총 9개의 기능을 로드맵에 넣는다. 사실 지금 시점으로 볼 때, 너무 널널하게 잡은 것은 아닌 지 걱정도 든다. 직접 해봐야 알 것이다. 시간이 남는다는 판단이 들면 #2-2에서 말한대로 즉시 2차 개발 일정표를 짜서 게시해야겠다.
#4 요약
과정의 완벽주의가 아닌 결과의 완벽주의를 좇기로 결심하고, 개발 일정표 (1차)를 만들었다.
'App 개발 일지 > Nutri Capture' 카테고리의 다른 글
Nutri Capture 백엔드 - StateFlow로 전환 (0) | 2025.01.02 |
---|---|
Nutri Capture 백엔드 - ChatBar에 ViewModel 연결 (0) | 2025.01.02 |
Nutri Capture 프론트엔드 - Dimens와 함께 ChatBar 만들기 (0) | 2024.12.31 |
Nutri Capture 프론트엔드 - Typography (2) | 2024.12.28 |
Nutri Capture 프론트엔드 - bottomBar 동적 변경 (1) | 2024.12.18 |