[부스트코스] 안드로이드 프로그래밍 - 프로젝트 D 코드 리뷰

난이도가 확 뛰었던 프로젝트 D였습니다.

만들면서도 이렇게 해도 되나 싶은 생각이 참 많이 들었던 기억이 납니다.

일단 모로 가도 서울로 가는 코드로 Pass는 했지만

아직은 많이 부족하다는 걸 느낄 수 있었습니다.

구현방식의 차이라는 것은 의도와는 다른 결과물이 나왔다는 의미이겠죠?

사실 저 부분은 세부화면에서도 햄버거버튼이 보이게 하려는 의도로 넣은 코드가 맞습니다. 그렇지만 실무에서는 상위 화면으로 이동한 뒤에 화면 이동이 가능하도록 만드는 것 같네요. 세부화면에서는 화살표 버튼으로 두는 게 보통인 것 같습니다.

 

이 부분은 네비게이션에서 화면을 이동하는 코드였습니다. 더 직관적으로 구현하는 방법이 있었습니다.

 

이 부분은 제가 상속의 개념을 반만 활용한듯한 느낌이네요.

여러 다른 화면을 만들 땐 한 화면을 상속한 클래스로 각각 만드는 게 맞지만

같은 화면 여러 개일 뿐이었으므로 굳이 그럴 필요가 없었습니다.

앞으로의 프로젝트를 위해서도 하나의 클래스만 활용해야 할 것 같군요.

 

onClickListener에 finish를 넣는 대신 이런 방법을 사용할 수 있겠네요.

 

이 부분은 Try again을 받았습니다...

액티비티와 달리 뷰를 직접접근하는 메소드가 없기때문에 뷰를 생성하는 위치에서 뷰를 참조하여 아이디값으로 해당 위젯을 찾아와야 한다는 피드백을 받았습니다. 여기까지는 생각이 미치지 못했는데 이런 부분을 집어주셔서 정말 고마웠습니다. 코드리뷰의 장점이 이런 부분에 있다고 생각합니다. 이론적인 이해도가 낮은 초보자로서는 혼자서 이런 부분을 찾아내기 어려운데, 코드 리뷰를 받으면 바로바로 그런 부분을 찾아 피드백을 받을 수 있습니다. 

 

이번에는 제가 메모를 조금 길게 남겼습니다. 그런데 훨씬 더 긴 답변을 받았고, 내용을 요약하면 제가 한 방식으로 하는 것이 좋고, 그 방식을 사용하면 알아서 관리가 되니 더이상 건드릴부분이 없다는 것이었습니다. 사실 소 뒷걸음질치다 쥐 잡은 격으로 떠올린 아이디어였는데 오히려 괜찮은 방법이라는 평을 받았네요. 

저희 과 교수님께서 자주 하시는 말씀이 있습니다.

어떤 방법이 빠르냐, 정확하냐 두 가지를 끊임없이 고민하라는 것과

시간을 들이라는 것.

어쨋든 제가 사용한 방법이 빠르고 정확하다는 것은 만족했던 것 같군요.

아직 간결한 코드와 간결하지 않은 코드 사이의 어딘가에서 헤메는 모습인데

조금 더 '시간을 들일' 필요를 느꼈습니다.