티스토리 뷰
2주차 미션 : 문자열 덧셈 계산기, 사다리 게임
https://github.com/woowacourse/java-ladder
후기
- business logic이 꽤 어려웠다. 오히려 이후의 좌표, 로또가 핵심로직은 더 쉬웠다.
- 쉽지않았지만, 그만큼 그 과정에서 고민할것들이 많아서 도움이 많이 된거같다.
내 코드 피드백
https://www.matheus.ro/2018/01/29/clean-code-avoid-many-arguments-functions/
우린 인자의 개수를 max 3개로 무언의 약속을 하고 있다. 최대한 줄이도록 노력하자.
저 링크를 보면, 인자수를 줄이는 2가지의 대책이 등장한다.
- Extract method technique : 별도 메소드로 추출한다.
- Parameter Object : 인자들을 묶어 별도 객체로 만든다.
즉 한줄로 정리하면 말씀하신대로, 메소드의 인자가 많아지면 메소드를 분리하거나 객체로 묶을 수는 없을지 고민해봐야 한다.
GameData가 List와 List을 갖는, 다소 애매한 구조를 갖고있었다.
스스로도 걸렸던 부분인데, 만들고싶었던 Members, Goals 일급콜렉션을 만드니 controller를 비롯한 전체적인 코드가 훨씬 명확해졌다.
String의 경우, 해당 api를 사용해 null, " ", "" 체크를 할 수 있다.
Apache Library - StringUtils Class
매개변수와 인자의 네이밍도
더 일반적이고 포괄적인 변수명을 갖게할지 or 해당 도메인에 specific한 변수명을 갖게할지
고민하여 상황에 맞게 짓는것이 좋을것 같다.
- 테스트하기 쉬운 것과 어려운 것을 구분하기
- 테스트할수 있는것이라면, 테스트 하기 쉬운 구조로 작성하기 !!
https://github.com/woowacourse/java-ladder/pull/23#discussion_r285459366
해당 discussion은 가장 고민을 많이 했던 부분이다.
객체지향과 역할, 책임 등을 좀더 공부할 필요성을 느꼈다.
byPass 메소드와 factory 메소드의 콜라보
생각치 못했던 방법 !
예전 미션부터 느꼈던 건데, result 정보를 담는 클래스를 만드는건 참 유용한 것 같다.
RacingCar 미션에서도 결과객체를 만들었다면, round별 거리 등을 저장할 수 있었을 것.
유효성 검사 후 값 할당 !
Controller belongs to the Presentation layer?
초반 미션 진행 당시, 객체지향에서 크게 헷갈렸던 부분중 하나인데
확실히 view 또는 뒷단 어느 한쪽에 유효성검사를 몰빵하기보단, 각 layer에서 필요한만큼 적절히 검사하는것이 좋을것같다.
초반미션에선 편한 정규식에 의존하는 경향이 컸는데 점차 그 의존도를 줄이고, InputView에선 최소한의 검사만 하여, 입력채널이 달라질 경우 코드수정을 최소화하는것이 좋을것같다. 출력도 마찬가지로, 출력의 디테일한부분은 OutputView가 담당하여 출력채널에 따라 코드가 크게 달라지지않도록!
Stream을 이용해 depth를 2->1로 줄일 수 있었고,
Jason코치님이 강조하시던 점(.)마다 라인을 넘겨서 가독성 향상과 함께 인텔리제이의 힌트도 볼수있었다 !! 깔끔-.
LadderDirection에서 구현한 방식이 사실 strategy pattern인줄도 모르고 사용했었다. 부끄럽지만.
공부할게 하나더 생겼으니 이번기회에 전략패턴에 대해 알아보자.
Strategy Pattern (전략 패턴)
다른 사람들의 피드백
OutputView에 (나의경우 LottoResult같은) 객체를 통째로 전달해서 출력하는 방식은 괜찮은 방식이고 잘하고 있는것 같다.
Naming a Package
패키지명은 소문자로 작성한다 - 알고있던 사실이다.
만약 단어 2개가 연속하는 경우, CamelCase를 따라야할까?
What is the convention for word separator in Java package names?
: package name은 camel case를 따르지 않는다 ! 모두 소문자로.
필요에 따른 새로운 객체타입 추가 - 항상 염두에 두고 가능성을 열어두어야 한다 !
분리하길 잘했음.
전체적인 가이드가 될수있는 큰 힌트.
아직 MVC 구조가 익숙치 않다. 이러한 컨트롤러의 형태와 역할을 기억하자.
View를 인터페이스로 추상화 시킬수도 있겠다..! 나중에 로또미션에서..?!
깜빡하기 쉬운데, toString 메소드를 오버라이딩했다면 바로 출력ㄱㄱ
모범답안. 재귀는 오버플로우가 일어날수있다.
따라서 함수초반부에 if문으로 중단지점을 걸어놓는게 좋다.
일단 이번 미션에선 고려하지않아도 ㄱㅊ
https://github.com/woowacourse/java-ladder/pull/6#discussion_r284751393
정답이 없듯이, 사람마다 관점이 다르듯이, split정도까진 view에서 해도 괜찮겠다. -물론 안해도 ㄱㅊ
하지만 주의할점은, 이를 넘어 과하게 view의 역할이 많아지면 많은 문제가 생긴다.
번외로, 마지막 discussion인 InputView를 테스트하는 방법중의 하나는
Coordinate 미션에서 Nick이 사용한 방법을 써도 되겠다 ! (input String을 byPass하는 같은 메소드명의 함수를 만들어, 인자로 받도록 해 테스트)
good :)
답답했던 부분 해소 !!! 드디어 기준이 생겼다.
toString을 재정의하는건 좋지만, 객체의 상태를 전달하는 용도로만.
OutputView에 해당하는 출력과 그리는 로직은 다른 곳에서 별도의 메소드를 통해 구현한다.
역시 랜덤은 느슨하게, 외부 주입
그렇군!
ㄴ 피드백의 근거
: 각 객체들의 유효성 체크를 모아둔 Rule로서의 클래스가 별로라는 피드백이었다.
내가 처음에 오해했던, 게임룰의 방식이 여러가지일 경우 공통으로 추출하는 인터페이스같은 용도의 rule이 아니었다.
찾아보니 StringUtils에 isEmpty(), isBlank() 외에도 참 편리한 함수들이 많았다.
앞으로 유용하게 사용하자.
한줄짜리지만 별도 메소드로 추출해 가독성을 높일수도 있겠다.
랜덤 분리와 의존도 약화에 대한 실마리
:)
몰랐던 내용이다. 굿. 로또미션에 적용해보자
추가로, 위 내용과는 관련없지만 String.matches vs Matcher.matches 차이에 관한 글
결국 전자는 regex가 한번만 컴파일되고 후자는 실행시마다.
재활용 good :)
e.printStackTrace는 안티패턴이라고 한다! "Java Exception"글의 SLiPP 링크를 참조해, log를 사용하자~
네이밍에서 단/복수 분리 잘하고 있었다.
역시, 판단 기준이 될수있는 좋은 피드백중 하나.
이럴수도있겠다 :)
{ 비어있거나 한 문장일때도 사용한다 ! }
무의식적으로 &&와 || 를 사용하고있었는데, 새삼 깨닫고 간다.
이렇게 쉽고 빠르게 지식를 얻어가는것이 피드백들을 보는 이유다 :)
내겐 좀 어려웠던 바로 그 글.
Are there any Java method ordering conventions?
그렇구나 !!
위와 같이 간단히 위임 메소드를 하나 추가해서, 디미터 법칙을 준수할수있다.
나는 의외로 이런 메소드를 추가하는걸 꺼렸던것 같다.
내 코드에서도 스트림을 적용할수 있었겠다.
이런 개념도 있다. 빈약한/풍성한 도메인 모델
https://zetawiki.com/wiki/%EB%B9%88%EC%95%BD%ED%95%9C_%EB%8F%84%EB%A9%94%EC%9D%B8_%EB%AA%A8%EB%8D%B8
https://m.blog.naver.com/PostView.nhn?blogId=muchine98&logNo=220304821784&proxyReferer=https%3A%2F%2Fwww.google.com%2F
결국 블로그에서 하는말은 빈약한 도메인 모델을 피하라고 한다.
지속적으로 눈에 띄는데, 스트림과 람다식을 좀더 공부하고 익숙해질 필요성이 있다.
그렇군! 역시 판단의 기준이 하나더 생겼다.
https://github.com/woowacourse/java-ladder/tree/pobi
https://github.com/woowacourse/java-ladder/tree/livecoding
Pobi께서 직접작성한 예시코드를 봐도 도움이 되겠다.
끗 -
'우아한 테크코스' 카테고리의 다른 글
우아한 테크코스) Lv1 - 4~6주차 [Lotto] 미션 후기, 코드리뷰 (0) | 2019.09.13 |
---|---|
우아한 테크코스) Lv1 - 3주간의 페어프로그래밍 회고록 (0) | 2019.09.13 |
우아한 테크코스) Lv1 - 3주차 [Coordinate] 미션 후기, 코드리뷰 (0) | 2019.09.13 |
우아한 테크코스) Lv1 - 1주차 [RacingCar] 미션 후기, 코드리뷰 (0) | 2019.09.13 |
우아한 테크코스) 개발 피드백, 팁 모음 (종합) (0) | 2019.09.13 |
- Total
- Today
- Yesterday
- brute-force
- Vo
- git
- queue
- Algorithm
- 프로그래머스
- Java
- C
- Data Structure
- 우아한 테크코스
- 리버싱
- graph
- 웹해킹
- 회고
- JPA
- FRAGMENT
- mysql
- webhacking.kr
- 해외여행
- 개발자
- Stack
- OneToMany
- dfs
- reversing
- javascript
- bfs
- socket
- Android Studio
- Android
- sort
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |