# 과일 카드 게임 앱 - K6

## 참여자

|번호|이름|
|--|--|
|K056|차지원|
|K060|최진형|
|K021|박유진|
|K032|신재혁|
|K033|심은석|
|K031|신민정|

## Git

- commit & PR의 가독성 좋은 컨벤션에 대해 고민했다.
- project 탭을 활용한 계획 관리에 대해 고민했다.

## 코드 리뷰

- 바인딩 방식
- with문의 활용
- `binding`의 반복 사용을 줄일 수 있다.
- Fragment에서 사용하는 Binding은 Memory leak를 신경써야한다.
- 화면이 destroy 될 때 `_binding = null` 처리를 한다.
- 객체 지향
- 테스트 코드를 작성하면서 세분화의 중요성에 대해 알게 되었고, 테스트를 고려하며 객체를 나누면 더 좋을 것 같다는 생각이 들었다.
- 테스트 코드
- given, when, then 형식에 따라 작성하면 편하게 작성할 수 있다.
- 테스트를 위해 기존 코드를 수정해야할 필요도 있다.
- 화면이 재생성될 때의 데이터 보존
- Fragment가 항상 onDestroy 되는 형태라면 Activity에서 ViewModel을 통해 데이터를 보존하는 방법이 있다?
- savedInstanceState에 값을 저장하는 방식?
- Appbar의 여러 사용법
- noActionBar 테마를 사용해서 기존 Appbar을 없애고 각 layout에 Appbar를 만드는 방식
- 기존 Appbar를 layout마다 custom해서 사용하는 방식
- Player가 다른 객체에 종속되는 것이 맞는가
- 앱의 기능에 따라 다를 것이라고 생각됨
- 본 구현사항에서 Player는 Game만 하도록 요구했다.
- 만약 Player가 다른 기능을 추가적으로 수행해야한다면, 종속되지 않아야한다고 생각한다.

## 나눈 고민

- 객체지향적인 프로그래밍 방법
- 객체의 역할 구분이나 테스트를 위해 기존 설계가 잘 돼있다면 View(Activity, Fragment)안 의 함수 내에서 구현하는 부분이 줄어들지 않을까?
- 테스트의 범위
- 기능 테스트를 진행할 때 어디까지 하는게 좋을까? 얼마나 해야하는 것이 효율이 좋을까?
- TDD에서 시간이 많이 걸려 현업에서 사용되지 않는 것으로 보아 테스트를 많이 하는 것이 무조건 좋은 것은 아닐 수 있다.
- 하지만 테스트를 많이 진행한다면 완성도가 높은 앱을 만들 수 있을 것이다.

## 해결되지 않은 고민

- Activity에서는 binding을 lateinit을 사용하지만 Fragment에서 binding을 backing property를 사용하는 이유
- 메모리 누수의 문제점?
- [구글링1](https://stackoverflow.com/questions/68697794/should-viewbinding-properties-in-fragments-always-have-a-backing-non-nullable-pr)