회고

2주차 과제는 숫자 야구 게임이었다. 1주차 기간과 1주차 공통 피드백을 통해 느낀 점을 바탕으로 2주차 과제를 진행했고, 스스로 성장했다는 느낌을 많이 받아 즐거웠다. 이번 2주차를 통해 나는 어떤 성장을 했는가?. 이에 대한 대답으로는 클래스, 메서드를 만들 때 네이밍을 통해 이야기를 적어가는 것처럼 개발하는 즐거움을 느꼈다.이다. 이번 2주 차에는 네이밍에 많은 신경을 썼고, 클래스와 메서드의 이름만으로 역할을 담으려 했다. 이는 마치 전지적 작가의 시점에서 출연진들의 행위를 directing하는 것 같은 느낌을 받았다. 이는 매우 즐거웠고, 이런 방식으로 개발을 이어 나가야겠다는 생각을 했다.

프리코스 1주 차가 지나고, 공통 피드백과 피어 리뷰를 통해 1주 차 과제를 리팩토링하고서 2주 차의 목표를 정리해봤다. (코수타, 코치들과의 수다 타임을 참고해 적었다.)

• Java 컨벤션을 지키자. (과제에 문서 참조가 있다.)
• Git commit 메시지 제목에 기능의 번호 대신 기능을 설명하는 식으로 더 자세하게 표현하자.
• 기능은 최대한 잘게 잘라보자. 그리고 의미있는 기능으로 묶자.
• 리팩토링에 더 신경을 써보자. (메소드 명, 가독성 주로 고려)
• 네이밍으로 의도가 잘 드러난다면, 주석은 지양하자.

구글 자바 컨벤션과 프리코스의 자바 컨벤션을 참고해 정리한 Java Convention은 다음과 같다.

Java Convention

참고하고자하는 convention을 발췌해서 정리했습니다.

3 소스파일의 구조

• 3.4 Class 정의

  • 클래스 멤버들간의 순서는 정답은 없다. 하지만 논리적인 순서를 가지는 것이 중요하다.
  • Overload 메소드들은 뭉쳐 놓는다.

4 포맷

• 4.1 중괄호

  • 중괄호 {}는 if / else / do / while 문에 내용이 없거나 한 줄이어도 반드시 포함한다.
  • 빈 블록은 개행해도, 개행하지 않아도 괜찮다. 하지만 멀티 블록(try/catch 구문 등)은 개행해야 한다.

• 4.2 블록 들여쓰기

  • 들여쓰기는 +4 스페이스

• 4.4 열 제한

  • Java 코드의 열 제한은 120자입니다.

• 4.8 변수 선언

  • 반드시 시작 부분에 변수가 선언되는 것은 아니다. 처음 사용되는 부분 가까이에 선언한다.
  • 클래스와 멤버의 modifiers는 다음과 같은 순서로 작성하는 것이 권장된다.
  public protected private abstract default static final transient volatile synchronized native strictfp

5 네이밍

• 5.2 클래스 이름

• 클래스 이름은 UpperCamelCase로 작성
• 명사( Character ) 혹은 명사구( ImmutableList )로 이름 짓는다. 형용사나 형용사구도 허용 ( Readable )

• 5.3 메소드 이름

• 메소드 이름은 lowerCamelCase로 작성

출처 : Google Java Style Guide / woowacourse-docs

---

가장 많이 참고한 부분은 중괄호 부분과 네이밍이다. 나는 중괄호를 생략하는 습관이 있었는데, 절대 생략하지 않아야 한다는 컨벤션이 있었다. 그리고 네이밍을 통해 객체의 기능을 파악할 수 있도록 네이밍에 많이 신경을 썼다.

그리고 Git commit에서 제목에 기능 번호대신 기능을 적으며 제목만을 보고 무슨 내용인지를 알 수 있도록 작성했다.

Git Commit Message

이렇게 Git commit 메시지를 작성하니, 내가 어느 순서로 기능을 개발했는지와 어느 기능을 구현했는지 바로 알 수 있었다.

네이밍

네이밍은 앞서 말했던 것처럼 최대한 의미를 그대로 나타낼 수 있는 이름을 지었다. 그리고 축약은 지양했다. 그에 따라 DividedRandomNumberElemensMaker라는 엄청 긴 이름을 가친 클래스가 생기기도 했다. 하지만 어느 부분을 축약할지, 의미를 더 잘 담을 수 있는 방법을 깨달을 때까지는 이렇게 의미를 전부 드러내도록 구현하려고 한다.

개선할 점

요구사항을 제대로 확인한다고 했지만, 기능 요구사항에만 너무 집중을 한 것 같다.
'System.exit();을 호출하지 않는다.'라는 프로그래밍 요구사항을 놓친 것이다.
앞으로 더 꼼꼼하게 확인하고, 메서드들의 기능을 더 잘게 나누어야겠다는 생각이 들었다.

내가 혼자 공부할 때는 네이밍, 가독성은 거의 신경쓰지 않았다. 중요하다는 사실은 알고 있었지만, '나중에 필요할 때 하면 되겠지.'라는 생각이었던 것 같다.

하지만 1주 차 과제를 리팩토링할 때, 불과 3일 뒤에 나의 코드를 보았을 때 나는 흐름을 잘 이해하지 못했다. 이를 통해 네이밍, 가독성은 미룰 것이 아님을 깨달았다.

이렇게 혼자 공부할 때 느낄 수 없었던 부분들을 깨달을 수 있게 하고, 다른 동료들과 함께 서로의 코드를 리뷰하며 다양한 관점을 배워갈 수 있는 환경이 너무 매력적이라고 느꼈다. 반드시 우아한테크코스에 최종합격해서 이러한 깨달음 아래에서 함께 성장해가는 개발자가 되고 싶다.