[우아한테크코스] 안드로이드 레벨1 오목 미션 회고

 

미션 관련 링크

오목 레포지토리

https://github.com/kimhm0728/kotlin-omok
오목(렌주룰) 1단계 PR

https://github.com/woowacourse/kotlin-omok/pull/62

오목(안드로이드, 데이터베이스) 2단계 PR
https://github.com/woowacourse/kotlin-omok/pull/93

 

 

 

코드 리뷰 받은 코멘트들 

Dao는 도메인 로직일까?

모델의 생성자에 Dao를 받아서, 모델 내에서 저장을 해주었다.

하지만 데이터를 저장하는 것은 도메인 로직이 아니기 때문에, 모델이 Dao를 알 필요가 없다.

Dao(SQLite) 자체가 안드로이드 프레임워크에 의존적이니, 액티비티에서 Dao를 수행한다.

 

 

Activity 내의 flag

flag가 Activity에 많아질 수록, 유지보수성이 떨어질 수 있다.

flag는 최대한 model 내에서 처리하도록 한다.

 

 

화면 회전 시 데이터 보존

나는 액티비티에 screenOrientation을 지정해서, 세로로만 화면이 고정될 수 있도록 했다.

하지만 화면 회전이 가능하도록 요구사항이 변경된다면 어떻게 될까?

 

먼저, Configuration Change 가 일어난다면 아래와 같은 생명주기를 타게 된다.
onPause → onStop → onDestory → onCreate → onStart → onResume

그런데 홈 버튼을 눌러서 앱을 백그라운드에 두고 다시 돌아왔을 때는 아래와 같은 생명주기를 타게 된다.
onPause → onStop -> onRestart → onStart → onResume

그렇기 때문에 무조건 onDestroy()에서 데이터 보존에 대한 코드가 존재하면 안 된다.

 

또한 액티비티의 onSaveInstanceState(), onRestoreInstanceState()를 이용해 데이터를 보존할 수 있다.

+ ViewModel로도 가능..

 

 

데이터 저장을 어디서 해야할까?

기존에는 사용자가 돌을 놓을 때마다 DB에 저장했다.

그런데 앱 종료시에만 DB에 접근하여 한번에 저장하는 것은 어떨까?

앱이 버그 등으로 인해 종료되는 경우 onStop(), onPause(), onDestroy()와 같은 생명주기가 타지 않는다.

앱 종료시 저장하면, DB 접근에 대한 오버헤드를 줄일 수 있다.

하지만 안정적으로 데이터를 저장하기 위해서는 클릭 시마다 DB에 저장하는 것이 좋다.

 

 

문자열 상수만을 담는 클래스에 대해..

문구가 수정이 되어있을 때, 모든 구현마다 돌아다니면서 확인 하지 않아도 된다.

여러 곳에서 사용되는 경우에는, 한번의 수정으로도 모든 곳에서 같은 결과를 도출해 낼 수 있다.

 

 

 

리뷰어/페어 피드백

리뷰어 피드백

- 많은 우여곡절이 있었지만 리뷰를 반영하고 올리브의 생각을 담으면서 발전해나가시는 모습이 인상깊었음.

- 앞으로 미션을 진행하면서 헷갈리거나 내용에 대해서 이해가 안되는 것들이 있다면, 언제든 공식문서와 여러 레퍼런스를 참고하여 자신의 생각과 기준을 잘 잡으셨으면 좋겠음. (맹신x, 참고o)

- 어떤 내용을 고민하고 있는지, 어떤식으로 구현을 하였는지 공유를 해줘서 좋았음. 미션을 진행하며 잘못 알고 있던 것들, 구현한 의도를 알게 되었음. 이를 통해 어떤 것을 중점으로 리뷰할지 판단하는 기준을 잡을 수 있었음.
- 남겨둔 코멘트에 대해서 자신의 생각을 자유롭게 말해줘서 좋았음.

 

페어 피드백

- 자신이 설계를 잘 못한다고 얘기했는데, 실제로는 잘했음. 구현 중 설계를 유연하게 변경하는 역량이 뛰어나다고 생각함.

- 구현 중에 제가 자꾸 설계를 다시 하고자 하는 모습을 보일 때, ‘이제는 구현을 해야 할 때’ 라고 부드러우면서 단호하게 이야기 해주어 좋았음.

 

 

오목 미션을 끝내고

이번 미션에서는 처음으로 연극 조가 다른 크루와 페어가 되었다. (제일 같이 하고 싶었던 크루 ㅋㅋ) 

미션을 진행하면서 서로 하드스킬과 소프트스킬이 향상되어 그런가?

코드도 가장 마음에 들고 소통 또한 가장 원활했다.

구현하는 스타일이 너무 잘 맞았고, 무엇보다 중요치 않은 부분에 너무 집중하고 있을 때마다 분위기를 서로 환기시켜주었다.

또한 칭찬을 많이 해줘서 좋았다...!!!!

나도 페어에게 칭찬을 많이 해주려고 노력했는데 ㅋㅋㅋ 습관이 안 잡히다보니.. 잘 안 됨..

 

 

그리고 이번 미션에서는 느슨한 결합을 유지하기 위한 생각과 고민을 정말 많이 했다.

고민을 해결하기 위해 리뷰어께 질문도 많이 드렸고, 정말 많은 얘기를 주고받았다.

어찌보면 리뷰어를 귀찮게 한 걸지도 모르겠다..

 

계속 머리를 싸매고 있는 나와 페어에게.. 제이슨이 지나가듯이 해주신 말이 있다.

제이슨은 기억 못 하실 수도 있지만 ㅋㅋ 나는 되게 인상깊어서, 후다닥 옵시디언 켜서 적어두었다..

약결합과 강결합이 필요한 때를 구분할 수 있어야 한다. 모든 부분이 약결합일 필요는 없다.

 

또한 응집도와 결합도에 관련된 포스팅을 읽은 적이 있는데, 

이 포스팅에서는 아래와 같은 문장이 있다.

변경될 가능성이 적은 모듈의 경우는 결합도가 높아도 문제가 적은 것 같습니다.
 표준 라이브러리의 포함된 모듈이나 성숙 단계에 접어든 모듈에 의존하는 경우가 그러한 경우인 것 같습니다.

계속 관련된 질문을 드렸는데, 미션의 주된 목적에서 벗어나는 오버엔지니어링이 될 수도 있다는 리뷰어의 피드백도 받았다.

 

 

나는 우승 조건이 5목이 아닌 6목으로 변경될 가능성도 열어두고 싶었고,

렌주룰(3-3, 4-4, 장목) 중 일부의 규칙이 없어지거나 포함될 가능성도 열어두고 싶었다.

그런데 렌주룰 자체가 <3-3, 4-4, 장목>의 조합이기 때문에 정말 변경될 가능성이 있을까?

미션 자체가 "오목"인데 "육목"으로 변경될 가능성이 있을까?

 

고민 끝에, 나는 미션에서 벗어나는 과한 욕심을 부리고 있다는 결론을 내렸다.

느슨한 결합을 유지하기 위해 진행했던 클래스 분리들을, 오목이라는 도메인에 맞는 단순한 코드로 수정했다.

 

 

블랙잭 미션에서도 느꼈지만,

나에게는 현재 미션에서 어떤 것이 가장 중요한 건지 파악하고 그것에만 집중하는 역량이 필요한 것 같다.

일단... 잘하려는 욕심이 과하다. (하지만 잘 하고 싶은 걸 어떡해...)

현실과 타협하는 것도 실력인 것을 뼈저리게 느끼는 중!!!!!!!

 

다음 미션에서는 마음을 조금 편하게 가지고 싶다.

못하면 어때! 아직 배우는 과정인 걸!