[2021-02-26 금] TIL

리뷰어의 미션4 코드리뷰

• https://github.com/codesquad-members-2021/java-chess/pull/150

• 리플렉션을 이용해 클래스 이름으로 체스 유닛등을 구별했었는데, 좋지 못한 코딩습관이라고 지적을 당했다.

• Reference 타입은 기본적으로 final을 하면 좋다는 의견을 받았다.

  • 나는 Primitive 타입이 아닌 Reference 타입인 List나 StringBuilder 는 final로 지정을 해주어도 내부 수정이 가능해서 햇갈렸었다.
  • 기본적으로 final을 해주는 이유는 개인적인 선호도인 이유도 있다고 한다.
  • 자신이 생각했을 때, 해당변수가 재할당이 필요하지 않을 것 같고, 앞으로도 재할당이 없을 것이라고 생각된다면 final로 해두는것이 안전하다.

• 이번 미션을 상속을 통해 구현을 했는데, 객체를 구별하기 위한? 의미없는 상속임을 지적받았고, 가능한 상속을 지양하면 좋다는 피드백을 받았다.

• 상속 받는 자식 클래스가 증가할 수록 클래스의 수는 기하급수적으로 많아질 것이고, 조상클래스의 변화는 이러한 모든 자식 클래스에게 변화를 주므로 유연한 변경이 어려워진다고 한다.

• 재귀와 공재귀에 대한 키워드를 알 수 있었다.

  • 기존의 나는 재귀함수를 통해 반복문을 대신할 수 있다? 정도로만 학습을 하고 간단한 실습을 구현할 수 있는 정도였는데, 이러한 재귀함수는 모든 호출 메소드가 콜스택에 계속해서 쌓이는 방식으로, 중간 연산결과를 알 수 없을뿐더러 메모리가 부족할 수 있기때문에 공재귀를 사용한다고 한다.
  • 구글에 검색을 해보면 공재귀에 관한 레퍼런스가 대부분 코틀린임을 확인할 수 있었고, 개념적으로 간단하게만 파악을 하였다.

그룹원의 미션5 코드리뷰

미션4 머지가 진행되지 않아 미리 진행한 미션5를 그룹원들에게 코드리뷰를 요청했었다.

• 객체에 담긴 요소를 일괄 변환하는 for loop를 stream으로 변환하면 좋을 것 같다.
• 객체의 논리적 동치성을 비교할 때, 굳이 객체를 새로 만들 필요 없이 기존 객체를 이용해라.
• switch문은 절차지향 방식이다? 꼭 써야하는지 다른 방식은 없는지 고려할 것을 추천받았다.
  • https://softwareengineering.stackexchange.com/questions/269996/are-switch-statements-generally-used-wrong
• 메서드명을 지을때 동사를 맨 앞에 작성하면 좋을 것 같다.
• 인덱스를 매게변수로 받아 무언가 처리하는 메소드를 작성할 때, 예외처리에 신경을 써라.

느낀점

• 나름 깔끔하게 코드를 구현하기위해 신경써서 작성 한 것 같은데, 역시 honux가 말한대로 코드는 똥이다!가 맞는것 같다. 나 혼자서 내 코드를 가꾸어봤자 좋은 코드인지 판단하기 어렵다. 즉, 애지중지 할 필요가 없다는 것이다. 미션5에서 체스 유닛들의 점수를 계산하는 메서드를 구현할 때 stack을 활용해서 구현했다는 방식이 너무 획기적이라고 생각했고, 너무 깔끔한 코드라고 상당히 뿌듯해했다🤣. 그런데 자바지기님의 레퍼런스 코드를 확인해보니 메서드들을 역할에 맞게 잘분리하셔서 10줄 안에 작성된 것을 보고 나의 코드는 많은 for loop와 if문으로 엄청나게 복잡했다라는 것에 정말 충격을 받았다.