[우테코] 사다리 미션 1단계 회고

💋 코드 저장소

https://github.com/woowacourse/java-ladder/pull/53

[1단계 - 사다리 생성] 깃짱(조은기) 미션 제출합니다. by eunkeeee · Pull Request #53 · woowacourse/java-ladde

https://github.com/eunkeeee/java-ladder/tree/step1

GitHub - eunkeeee/java-ladder: 사다리타기 미션을 위한 저장소

 

 

👍 좋았던 점

- 정말 좋은 리뷰어를 만났다. 보통 최종 commit한 내용을 바탕으로 리뷰를 해주시는 분이 많은데, 40개 정도 되는 내 commit을 모두 확인하면서 피드백 해주셔서, 거의 페어 프로그래밍같은 느낌도 들고 내 지난 주의 코드 작성한 기록들을 옆에서 실시간으로 피드백 받는 느낌이 들었다.

 

- 일주일 간 코드를 작성하고 리뷰를 받으며 느낀 것인데, 좋은 리뷰를 받기 위해서는 먼저 내가 명확하게 질문하고 싶은 점을 정리해 놓아야 한다. 리뷰어 분들도 퇴근한 뒤에 간단하게 각자 세 명 정도씩 리뷰를 맡는데, 내가 리뷰어라면 명확하게 정리한 README 문서가 있다면 리뷰하기도 편하고, 누군가에게 더 크게 기여할 수 있다는 생각이 들어서 더 리뷰하고 싶은 마음이 들 것 같다. 

 

💋 아쉬웠던 점

- 리뷰어에게 commit 과정까지 꼼꼼히 피드백 받다보니 아쉬운 점이 많았다. 앞으로는 commit 중간에도 컨벤션에 대해서 늘 지키는 습관을 가져야 겠다. 마지막에 리팩터링 한다며 딱 한 번에 바꾸면 연습이 되지 않으니, 항상 지키자.. 추가로 가끔 Ctrl Alt C로 했을 때 자동으로 public 상수로 선언이 되는 경우가 있는데, 최종이 아니더라도 접근제어자에 대한 부분은 더 신경써서 꼼꼼히 점검해야 겠다.

 

- 변수, 상수, 메서드의 이름을 정할 때 크게 고민하지 않고 고민할 시점이 되면 자꾸 미루면서 임시 이름으로 사용해 왔다. 근데 그것이 화가 되어서, 나중에 Floor, Floors, Ladder, Lines 등등 정말 혼란의 도가니가 되었다. 알고보니 Floors와 Ladder은 같은 의미였고 이 실뭉치를 파헤치며 모든 변수명과 메서드, 클래스 명을 고칠 때 꽤나 고생을 했다. + commit 로그도 굉장히 지저분해졌다.(ㅠㅠ) 앞으로는 설계할 때에 확실하게 이름까지 잘 정하고 가야겠다고 다짐했다. 

 

- 마찬가지로 이름 짓기를 미루는 습관이 자꾸 피드백이 많아지게 한다. 이번에도 ladder를 출력하는 과정에서 StringBuilder의 변수 이름을 result로 지었는데, 보았을 때 어떤 변수인지 유추가 되는 ladderDisplay같은 이름이 더 좋을 것 같다. 이것도 나중에 바꾸려고 대충 지어놓고 바꾸는 것을 까먹었다.

 

- 우테코에서 제공하는 예시 코드의 이름들이 좀 현실과 동떨어져 있고 구리다고 생각해서 나와 페어는 새로운 이름을 고민했고, 페어가 Floor이라는 신박한 이름을 생각해내서 즐겁게 사용했는데, 어떻게 보면 통일되지 않은 이름을 사용한 것이고 예시 코드에 나와있기 때문에 리뷰어는 그 이름으로 숙지가 되어 있을 텐데 혼란을 줄 수 있다고 느꼈다. 구리더라도 다  하는 것을 따라하는 것도 좋은 개발자의 덕목일 수도 있다. 누군가 내 코드를 보고 구리다고 변수명을 다 바꿔버리면 다음에 봤을 때 너무 초면같지 않을까?

 

- 페어와 함께 하다보니, 혼자 할 때에 비해서 좀 산만해졌다. 그래서 요구사항을 끝까지 잘 안 읽은 것 같다. 일급 컬렉션을 사용하라는 추가 요구사항이 있었는데, 제대로 읽지 않았다. 다행히, 요구사항은 읽지 않았음에도 모두 지켰다...! (대단한걸...)

 

- 테스트 코드에서 @DisplayName을 사용하다 말다 하는 경향이 있었는데, 나는 아직도 테스트 코드를 프로덕션 코드만큼 공들이지 않는 것 같다. 다음 미션부터는 좀 더 꼼꼼히 모든 것을 테스트하도록 연습해야겠다. 다른 사람 코드를 보면 객체의 동일성까지 테스트한 분도 있는데, 저 정도까지는 못할지라도...

 

 

또한 @Nested에서 끊어서 @DisplayName을 작성하는 예시도 리뷰어가 보여줘서 메모하고 앞으로 이렇게 해야지...

 

- 지난 번의 공통 피드백에 있었던 Car 객체는 파라미터가 randomNumber인지 알 필요 없다는 것과 비슷한 피드백을 받았다. 객체의 입장에서 독립적으로 생각해 이름을 지어야겠다. 또 Lines 객체에서 linesCount처럼 중복되는 이름보다는 그냥 count를 사용해도 된다.

 

- 의미가 없는 상수화를 하고 있었다. ","를 상수화하면서 COMMA라는 끔찍한 이름을 붙여 주었다ㅋㅋㅋㅋ 앞으로는 상수화를 하는 의미에 대해 생각하면서, 이 코드를 처음 읽는 사람에 대해 공감능력을 좀 길러야겠다.

 

- 나와 페어는 클래스 내에서 메서드를 작성하는 순서에 대해 생각이 달랐는데,

그냥 페어가 하자는 대로 했다가 피드백을 받았다. 좀 더 논쟁해봐도 괜찮았을지도...?! 나는 약간 논쟁을 회피하고 타협을 빠르게 하는 경향이 있는 것 같다. 배움에 있어서 좋은 태도인지 모르겠지만! 지옥토론을 싫어하는 편이다... 그래서 우테코에 지내다보면 다른 페어들의 지옥토론이 좀 놀랍기도 하다. (여태까지 항상 타협해서 빠르게 끝내던 편) 어떤 태도를 가져야할지 좀 더 고민해봐야겠다. 

 

리뷰어는 아래 글을 추천해줬다.

 

👍 리뷰어에게 배운 점

- 사소하지만 중요한 파일 끝의 개행에 대해 배웠다. Git쪽에서 체크하는 부분이기 때문에, 추가하지 않으면 보기 싫은 기호가 뜬다. 당장은 사소해 보이지만 프로는 사소한 컨벤션을 모두 당연히 지키는 사람이다

 

- 늘 너무 어려운 부분이지만, 네이밍에 관한 피드백을 받았다. 

사다리 게임에서 연결되는 다리는 입력된 사람 수보다 1개 적게 된다. 연관성이 있기 때문에 메서드 상에서 저런 방식으로 작성했는데, 코드를 작성하던 당시에도 조금 이상하다는 느낌을 받았다. 사다리의 층 자체를 기준으로 생각한다면, 사람 수가 갑자기 입력되는 것은 다소 뜬금없고 어색한 것 같다.

 

- 자바 패키지의 네이밍에 대해 알아보면 좋겠다는 피드백을 받았다. utils 패키지에 대해 잘 생각하지 않고 사용했었는데, util 하위에 너무 많은 클래스를 넣고 다닌 것 같기도 하다.

 

- 리뷰어들의 피드백에 공통적으로 개행에 대한 부분을 굉장히 많이 짚어 주셨는데, 사실 나는 평소에 개행에 대해 깊이 생각해본 적이 없다. 그래도 여기서 개행하면 좋겠다, 개행이 한 번 더 된 것 같다라고 종종 피드백 해주는걸 보면 컨벤션에 맞지 않는 개행은 상당히 거슬리나 보다....! 앞으로는 좀 잘 찾아보고 신경써야겠다.

 

리뷰어의 피드백을 받고 내가 정리해본 글이다.

[JAVA] 줄바꿈에 대하여: 출력 개행에 \n을 쓰면 안된다고??

 

- 객체의 주입에 대해서 생각해 봤다. 현재의 생각으로는, 저렇게 하면 안되는 것 같다.

 

Application이나 Controller부터 폭포수 내려오듯 주입받는 방식이 더 적절할 것 같고 객체 지향적인 것 같은데, 필드가 너무 많아질 것 같아 그것도 걱정이다.

 

 

- 리뷰어에게 검증 클래스의 위치에 대한 질문을 받았다.

 

 

나는 사실 프론트엔드를 두 달 정도 공부하면서 항상 사용자에게 input을 받을 때 즉시 검증을 해 왔기에, domain에서 검증을 한다는게 굉장히 어색했다. 근데 생각해보니 데이터베이스에 한 번 검증된 값이라고 마구 저장해버리면 그것도 좀 도박!

 

 

현재까지의 나의 의견이다.

 

세 가지 경우의 수 전부 이마를 치며 공감했습니다ㅠㅠ
저는 안전 제일주의라 둘 다 검증이 있는 것이 좋다고 생각하는데, 대부분 View는 사용자와 만나는 지점이기 때문에 프론트엔드의 역할이 되기 때문에 어쩌면 JS로 하는 검증일 수도 있을 것 같아요...!
회사의 비용이 남아도는 곳까지 한다를 원칙으로 하고, 제가 정말 돈이 없는 밥풀 뜯어먹는 회사라면, Domain에만 검증을 하고 나중에 View에도 검증 로직을 넣을 것 같아요. 당장 사용자에게 알려주는 것보다 회사의 존패에는 데이터베이스가 무사하냐가 더 중요할 것 같아요
이상 저의 의견이었습니다.

 

💋 나의 끊임없는 궁금증

 

- 이번 미션에서 Controller에 필드가 많아서 아래와 같은 피드백을 받았다

Controller는 Model이나 View를 제어하는 부분이라고 생각했기 때문에, 아래와 같은 상태값을 가지는 게 이상하다고 생각했습니다.

Controller에서 메서드를 분리하려고 하다보면, 자연스레 각 메서드 간 공통되는 부분을 필드로 작성하게 되는데, 어떻게 하면 필드의 양을 줄일 수 있을까?

 

이를 해결하기 위해 프리코스 때 사용했던 방법을 간단히 샘플 코드와 함께 첨부한다.

샘플 코드이고, 간단한 설명도 달아놨다!