문서화 작업
#1. 테이블 명세서 작성
기존 일정대로 전날 작성했던 erd를 합쳐갔다. 테이블 관계를 재정립하고 불필요한 테이블을 지우고 테이블 명을 구체적으로 정했다
어쩌다가 이렇게 된지 모르겠지만 초반 내가 요구사항 정의서 작성에 있어서 어플의 핵심 기능인 '식단'파트를 담당하게 되고 다음 문서 작성에 있어서도 이어지면서 erd, 테이블 명세서, api명세서에서도 일이 많아졌다. 생각보다 영양소 값을 담을 필드명이 많아지면서 이래도 되나? 싶었지만. 사실 다 사용하고 싶었다. 다른 팀원들을 설득시키려 노력했고, 이 문제를 토론하는것 자체를 피곤해 하는 듯 했지만 동의를 받았다. 다행이었다
#2.
초반 많은 기능을 생각했고 구현을 꿈꿨지만 구현하면 할수록 해야할게 많아지며 부담이 커졌다.
특히 기획이 구체화 되어 가면서
식단 분석 -> 부족한 영양소 확인 -> 관련된 식재료와 음식 추천 -> 구매 연결
이라고 생각했지만 아이디어를 제시한 팀장을 포함해 팀원들의 의견이
식단 분석 -> 부족한 영양소 확인 -> 관련된 식재료와 음식으로 식단 추천 인걸 깨닫고 생각이 복잡해 지기 시작했다. 단순히 음식을 추천하는 것과 음식을 가지고 식단을 짜는 것은 난이도가 전혀 다르다.. 이걸 이해하고 있는 걸까?
#3.
구체적으로 어떻게 구현할 건지 이야기를 먼저 꺼냈다. 꺼내야 했다
대화를 나눴지만 구체적으로 어떤 로직으로 기준에 적절한 탄단지 비율과 칼로리를 구성한 식단을 조합할 것인지 나오지는 않았다. 지금이야 생각을 정리해 글을 포스팅한다지만, 당시에는 내 생각도 정리가 안되어 말하는 것도 힘들었다. 필터조건과 엔티티, 필드 설정에 여러가지 고민이 생겼다. 다른 팀원들은 어디까지 생각했을까?
부족한 것을 찾는 것은 쉽다. 하지만 그것을 기반으로 적절한 데이터값을 조합하는건 어렵다..
내일 다시 이야기를 꺼내봐야 겠다..
-
영양소의 어디까지 사용할 것인지
메이저(탄단지당나, 칼로리)와 기타로 나눴다
기타(비타민, 무기질, 콜레스테롤 등)를 제외할까 했지만 정보가 있는만큼 과감하게 필드를 여러개 만들어 추가시키기로 했다 -
추천 식단 구성에 사용될 값에 대해
칼로리 +탄단지나당 까지를 투표로 결정했지만.. 로직을 구현할 수록
나트륨과 당분까지 맞추기에는 무리였다 -> 솔직히 이 부분에서는 화끈하게 빼버리자 단언했다. 메인 영양소인 주제에 실제 식단추천 로직에 쓰이지 않을 것 같아서였다. 쓰이게 되면 필터링된 DB에 남는게 없는 거라는 생각에서 였다. -
추천 식단 구성 로직에 대해
단순하게 부족한 영양소를 뽑고 그걸 많이 함유한 음식을 조합하면 된다는 의견이 나왔다
하지만 반대로 기준보다 과도하게 포함된 식단이 나올 경우의 수를 막아야 한다.
부족한 영양소를 케어할 때도 마찬가지다 적게 함유한 음식으로 조합하다 다른 영양소가 초과되게 하면 안된다. 우리가 추천한 식단이 우리가 분석한 기준에 미달이라니.. 그런 끔찍한 앱이 어디있는가
