- 실행 결과를 입력해야한다.
- ,로 구분
- Name과 비슷함. 재사용해볼 수 있지 않을까?
- 사다리 결과에 실행 결과 추가해준다.
- 결과를 보고 싶은 사람
- 추가되는 로직
- 실행결과 클래스가 하나 있으면 좋겠다.
- 사람이름 입력한 것에 대한 실행 결과는 지연결과를 하던, 생성 당시에 계산해놓던 하기로 함. (map이 좋을 것 같은데, 출력 순서가 있으므로 list를 이용)
- 실행 결과를 계산하는 로직이 필요함
- 실행 결과 계산하는 로직
- 사다리 실행 결과를 출력해야 한다.
- 개인별 이름을 입력하면 개인별 결과를 출력하고, "all"을 입력하면 전체 참여자의 실행 결과를 출력한다.
- 의미가 있는 로직은 메서드로 만들어서 가독성을 높여주자
- while(true)를 재귀로 구현해보기(꼬리재귀)
- forEach는 순수성(외부로직의 값이 변경되면 안됨)을 지켜줘야한다.
- stream.map 중개스트림이 동일한 것이 2번 있으면 2번 순회한다.
- @DisplayName에는 어떤 조건하에 어떤 결과가 나올지에 대한 내용이 모두 포함되어야 한다.
- 재귀함수를 사용할 때, 기저조건에 도달하기까지 비용이 적다면, 사용하는 방법도 고려해보자.(코드의 가독성이 좋아질 수 있다)
- 테스트코드 설명을 할 때, 적절한 수식어구를 이용하여, 가독성을 올려주자.
- 이름, 사다리, 사다리게임
- 이름
- 이름 값만 가지고 있으면 됨.
- 유효성(최대 5글자)
- 일급컬렉션인 이름s
- ,로 구분
- 사다리
- 자료구조로써의 사다리, 2차원 boolean 배열 -> List<List> -> List
- Line -> List -> List
- LadderPart -> Rail, Rung
- 인덱스를 이용해 LadderPartFactory에서 Rail, Rung생성
- 이전 Rung이 세팅되어있으면 다음 Rung은 빈 rung이어야 한다.
- Rail, Rung (LadderPart 구현체)
- 짝수 Rail, 홀수 Rung
- rail, rung, emptyRung
- String value() -> "|", "-----", " "
- Function<XXX, Integer> => ToIntFunction
- for문을 스트림으로 IntStream.range(0, n)으로 변환(map, collect 활용)
- 불변성 확보하는 일은 좋은 일
- dto 패키지 분리
- Predicate -> IntPredicate
- Util 객체들은 SRP정책을 위반하기 쉽다. 특정 객체가 Util클래스를 사용함으로써 SRP를 위반하는지 고민을 해보자. 해당 팩토리에서만 사용한다면 클래스내 상수도 괜찮다
- 유틸성 클래스 객체 생성 제한
- Rung 생성 로직을 전략패턴을 이용해보기
- 람다식을 사용하는 이유 명확하게 하기(람다식은 다른 도메인 혹은 계층에 전달할 수 있다는 점이 의미가 있다) 단순히 일급함수로 만든다면 의미가 있을까?
- PreviousRung 제거하기
- 자동생성코드라도 {} 생략하지 않기
- String.isEmpty(), Objects.nonNull() 활용
- 클래스명과 멤버필드 이름 동일하게 하지 않기
- 정적팩토리 메서드는 이름을 줄 때 관례를 따르는 것이 더 좋음
- 새로 생성하는 객체가 있다면 재활용 가능한지 생각하기
- 로직 중복 없애기
- 매직넘버, 매직리터럴
- toString 생략가능하다면 생략
- 람다에 너무 목메지 말기 메서드를 사용해도 됨
- 스트림에서 람다가 길어지게 된다면 메서드 레퍼런스를 생각하기
- 객체 생성을 DI하는 위치에 대해서 생각해보기
- 함수형 인터페이스 java.util.function 한 번 훑어봄. 어떤 것들이 있는지 알게 되었음.
- for문을 스트림으로 바꿀 수 있다는 사실을 알게 됨. idx를 안 쓰는 부분들은 아직도 조금 걸리긴 함.
- 불변성은 항상 생각하는게 좋은 것 같음. 해당 객체가 값이 바뀔 가능성을 걱정 안하게 되는 부분이 편함.
- 유틸성 클래스 객체 생성 제한. 유틸성 클래스를 많이 안 쓰다보니 종종 까먹게 되는 것 같음.
- 함수형 인터페이스를 통해서 전략패턴 비슷하게 사용할 수 있구나라는 사실을 알게 됨.
- 람다식을 사용하는 이유에 대해서 단순히 변수로 생성하는 것보다는, 다른 도메인에 전달하는게 의미가 크다는 사실을 알게 됨.
- 의존성에 대해서, 자바가 기본적으로 제공하는 패키지는 사용해도 된다는 생각을 하게 됨.(원래는 Objects.nonNull 같은 것도 의존성이 생겨서 안 좋다고 생각을 했었음)
- 정적팩토리 메서드를 프로그래머가 찾기 어렵다는 말이 이해가 잘 안갔는데, 생각하다보니 이해가 조금 가게 됨. 관례를 따르는 것이 좋은 것 같음.
- 클래스명과 멤버필드 이름 동일하지 않게 하기. 의아하기는 했었는데 관례처럼 사용해도 되는건가라는 생각을 했었음. 하지만 역시 아니였음.
- 매직넘버랑 매직리터럴을 어디까지 빼야하는지는 아직 잘 모르겠음. IntStream.range(0, max)에서 0도 빼야하는건가 하는 생각을 함.
- 사다리 게임 게임 요구사항을 파악한다.
- 요구사항에 대한 구현을 완료한 후 자신의 github 아이디에 해당하는 브랜치에 Pull Request(이하 PR)를 통해 코드 리뷰 요청을 한다.
- 코드 리뷰 피드백에 대한 개선 작업을 하고 다시 PUSH한다.
- 모든 피드백을 완료하면 다음 단계를 도전하고 앞의 과정을 반복한다.
- @FunctionalInterface 명시 굿
- Stream을 자주 사용하자
- 반환 타입에 따른 map 또는 mapToLong 꼼꼼히 보기
- Stream에서도 축약어는 쓰면 안된다. 앞으로 변수명에서 축약어 절대 금지
- 에러 메시지도 매직 스트링이다.