레벨1 레벨로그

디미터의 법칙

객체의 내부 구현에 대한 정보를 외부로 노출하지 않는 것이다.
객체의 결합도를 낮출 수 있고, 변경에 유연하고 유지보수하기 쉬운 코드를 작성할 수 있다.

IllegalStateException vs IllgalArgumentException

IllegalStateException: 호출받은 객체가 요청을 처리하기 적합하지 않은 때에 호출되었음을 알린다.
IllegalArgumentException: 메서드에 잘못되거나 부적절한 매개변수가 전달되었음을 알린다.

YAGNI (You are not gonna need it)

필요가 생기기 전에는 구현하지 않는다.
현재는 사용하지 않지만 확장성을 고려해서 미리 작업하는 것은 자제하자.

상속과 조합

상속: 기존 클래스를 재활용하여 새로운 클래스를 작성하는 것. 중복된 코드를 줄이고 기능 확장이 가능하다.
조합: 새로운 클래스를 만들고 필드로 기존 클래스의 인스턴스를 참조하는 것
상속의 경우 하위 클래스가 상위 클래스의 구현에 의존하기 때문에 상위 클래스의 변경에 모든 하위 클래스가 영향을 받는다.

불변 객체

생성 후 내부 값을 바꿀 수 없는 객체이다. 사용되지 않고 버려지는 객체는 메모리 관리와 성능에 부담을 끼칠 수 있다.
객체의 상태를 변경할 수 없도록 하고, 클래스를 final로 선언하여 클래스의 확장을 막는다. 클래스의 상태가 가변 객체일 경우 방어적 복사를 적용한다.
장점: 생성자, 접근 메소드에 대한 방어적 복사가 필요 없다. 멀티 스레드 환경에서 동기화 처리 없이 객체를 공유할 수 있다.
단점: 메모리 누수 문제가 존재한다. 사용해야 하는 값의 가짓수가 많으면 그만큼 많은 객체가 생성되어야 하여 성능에 부담을 줄 수 있다.

VO

도메인에서 한 개 또는 그 이상의 속성들을 묶어서 특정 값을 나타내는 객체를 의미한다.
aliasing 문제 때문에 불변 객체로 만들어야 한다.
속성 값이 동일할 때 같은 객체로 만들기 위해 equals()와 hashCode() 를 재정의해야 한다.

함수형 인터페이스

1개의 추상 메서드를 갖는 인터페이스
구현 클래스, 익명 클래스, 람다로 구현할 수 있다.
동시성 side effect를 없앨 수 있다. 구조적으로 유연하고 간결하다.

DTO

계층 간 데이터 교환을 하기 위해 사용하는 객체
getter, setter를 포함하며, 비즈니스 로직은 포함하지 않는다. 그러나 굳이 값을 변경할 필요가 없는 경우 setter를 만드는 것보다 생성자에서 값을 할당하는 것이 좋다.

디폴트 메서드

인터페이스에 있는 구현 메서드.
기존의 구현을 고치지 않고 이미 공개된 인터페이스를 변경하기 위해 고안되었다.
선택형 메서드: 기존 인터페이스에서 잘 사용되지 않는 메서드를 디폴트 메서드로 작성하여 인터페이스 구현 클래스에서 빈 메서드 구현을 하지 않도록 한다.
동작 다중 상속: 인터페이스는 여러 개를 구현할 수 있어 인터페이스를 조합하여 다양한 클래스를 만들 수 있다.

우르 질문

원시 값 포장의 단점
모든 원시값을 포장하시는 편이신가요? 기준이 따로 있으신가요? 원시 값 포장을 할 때 드는 비용과 하지 않을 때의 비용 차이는 어떨까?
VO가 불변성을 지원해야 하는 이유는 뭐라고 생각하는가?
설계에 얼마나 시간을 쏟는 편인가?
설계는 계속해서 변경되지 않나? 얼마나 완벽한 설계를 추구하는가?
일급 컬렉션을 사용하지 않았을 때 발생하는 사이드 이펙트란 무엇을 의미하는가? 일급 컬렉션을 사용해서 어떻게 막을 수 있는가?
unmodifiableList 는 어떤 때 사용하면 좋을까?
설계하면서 객체지향적 설계가 안 좋은 점이 있었나요?
설계에서 가장 중요하게 생각하는 부분은?
역할과 책임을 적절하게 할당이 되었는지 어떻게 확인할 수 있을까?
어떤 경우에 일급 컬렉션을 사용하면 좋을까?
코드를 구현하다 보면 어느 정도 확장성을 고려해서 구현해야 하는 부분도 있다고 느껴지는데, 아예 확장성을 제외하고 미션을 진행하셨나요? 그것이 아니라면 어느 기준까지 확장성을 고려해야 한다고 생각하시나요?
메모리 누수 문제가 단점이라고 하셨는데 어느 기준까지 사용해도 된다고 생각하시나요?
어째서 VO를 사용해야겠다고 생각하셨나요?
TDD 커밋 단위는 어떻게 하는 게 좋다고 생각하시나요?

우르 피드백

자신의 생각을 자신감 있게 말하는 모습이 좋았다.
솔직하게 답변하는 모습이 좋다.
경직되지 않고 여러 제스처를 사용해서 답변이 어색하지 않았다.
답변에서 자신만의 철학이 느껴져서 좋았습니다.

제나

질문

private 메서드도 테스트 하는가? 왜 그렇게 쓰는가?
domain과 view의 의존은 어떤 경우에 의존한다고 할 수 있을까?
프로덕션 출력용으로 사용하지 말아야 하는 이유가 무엇일까?
toString() 을 정의해서 좋았던 점이 있나?
어느 정도의 개수까지 캐싱해도 된다는 기준이 있나?
캐싱을 하게 되면 접근 시간이나 계산이 없게 되는 것인가?
어떤 경우에 캐싱을 주로 사용하면 좋을까? (얼마나 자주 사용될 때?)
TDD를 할 때 힘들었던 점은 없나?
정의한 toString() 은 어디서 쓰는가?
캐싱할 때 주로 어떤 자료구조로 구현하는가?
방어적 복사를 안 해도 되는 경우가 있을까?
view에서 모델 객체를 받아서 출력해도 된다고 생각하시나요? 아니면 DTO 객체를 따로 두는 것이 좋다고 생각하시나요?
모델에서 view에서 출력하기 위한 로직이 있어도 된다고 생각하시나요?
모든 경우에 일급 컬렉션을 사용하는 게 좋은가요?

테오

속기

모든 도메인 속성들에 대해 커스텀 예외를 만들었나? : 예외 객체가 지금은 작은 시스템이지만 큰 시스템이라고 한다면 예외 객체가 관리 대상이 되기 때문에 비용이 클 수 밖에 없다. 예외 객체도 도메인이 수정될 때 같이 수정되어야 하기는 하지만 관리가 어렵다.
예외 필드로 무엇을 가질 수 있는지가 중요하다. 예외 객체가 추상화 레벨을 파괴할 수 있다. 원시 타입 정도는 가져도 될 거 같다.
예외 객체가 도메인에 의존된다는 느낌이 있는 경우 사용하면 안 될 거 같다.
자료구조는 값이 중심이 될 수 밖에 없어서 디미터의 법칙이 적용되지 않아도 된다고 생각한다.
일급 컬렉션에서는 디미터의 법칙을 덜 지켜도 되나? : 일급 컬렉션 객체를 반환하는 것에 대해 큰 문제라 생각하지 않는다. 상태와 행위를 동시에 관리하기 위한 객체라고 생각한다. 굳이 일급 컬렉션에서는 디미터의 법칙을 준수하지 않아도 된다고 생각한다.
모든 과정에서 TDD 했는가? : 모든 과정에서 하지는 못했다. 시간적 압박 때문에 초반에는 TDD를 하게 되었지만 마감일이 다가올 때는 프로덕션 코드만 작성하고 테스트는 검증용으로만 사용했다.
TDD가 시간이 오래 걸리는 이유? : 만들어지지 않은 것에 대한 행위를 작성하기 때문에.
이상적으로는 안정적인 코드. 현실적으로 생각했을 때 버려야 할 때가 있다.
TDD에서 신경쓰는 것?: 인간의 인지 능력을 제어하는 것이라고 생각한다. 베이비 스텝으로 진행하려고 의식적으로 노력했다. 그런 과정을 통해 예측하고 있던 자신만의 기준이 사라지는 듯한 느낌을 받았다.
TDD를 잘하지 않는 환경에서 TDD 하자고 설득한다면?: 테스트 코드가 하나의 문서가 될 수 있다. 테스트 코드는 변경에 대처할 수 있는 하나의 수단이 될 수 있다.
TDD를 왜 해야 하는가?: 테스트 코드를 잘 짜고, 좋은 프로덕션 코드를 만드는 수단으로서 TDD를 사용하는 것이 좋을 거 같다.
TDD가 어떻게 좋은 프로덕션 코드를 만들 수 있는가? : 가독성 측면에서 이점이 있을 거 같다.
TDD 사이클 중에서 가장 중요한 것: 실패한 테스트를 만드는 것. 실패한 테스트이면서 클라이언트가 원하는 정보인가? 이 객체에 해당하는 행위인지를 생각해봐야 한다. 실패한 테스트를 선별하는 작업이 중요하다.
실패하는 요구사항을 작성하면 되지 않을까? TDD 만의 장점인가?: TDD는 하나의 구현 과정이기 때문에 요구사항 분석보다는 잘 사용하는 것이 좋을 것 같다.?
테스트 코드 작성함에 있어서 검증 코드를 만드는데 있어서 본인만의 신경쓰는 부분이 있는가?: 모든 테스트가 당연히 통과할 수 밖에 없는 코드로 만들어졌다. 이것을 검증으로 볼 수 있을까에 대한 고민을 많이 했다. 예측하는 행동인가? 예측할 수 없는 부분에 대한 테스트를 만들기 위해 의식적인 생각을 많이 하게 된다.
테스트에 대한 기법이 뭐가 있을까? : 테스트를 작성할 때 이것이 과연 클라이언트가 원하는 정보인가?에 대한 생각을 하게 된다. 모든 유스케이스를 생각해보고 필요한 행동이라고 생각될 때 구현한다.
유스케이스 작성??: 어떤 시나리오가 존재할지 생각해보는 것. 프로덕션 코드와 테스트 코드 작성자를 분리하는 것도 좋은 방법이다.
테스트 코드가 부정적인 영향을 준 적은 없는가?: 설계 반영에 대한 테스트는 실패하는 것이 맞다. 그에 따른 오버헤드가 발생할 수 밖에 없다.
테스트 코드가 없는게 확인하기 편하지 않을까? : 테스트가 있으면 변경했을 때 이게 아니다 라는 것을 알게 되기 때문에 필요하다.
테스트 코드를 작성하면서 유의했던 점?: 국소적인 부분을 테스트하고 있나?라는 생각을 하고 있다. 프로덕션 코드와 연결해서 생각해서 해당 부분에 대한 테스트가 정말 이 부분에 대한 테스트가
데이터 베이스 연동 부분 테스트는 했는가? : 데이터베이스는 테스트하지는 못했다. 작성을 해야 한다면 테스트용 툴을 사용할 것 같다. mock이나 spy 같은 것을 사용할 것 같다.
데이터 베이스는 테스트를 안 해도 되나?: 해야 하기는 하지만 데이터베이스의 값을 확인하기 위한 테스트는 필요 없다고 생각한다. 테스트 해야 할 부분은 서비스 계층, DAO 비즈니스 로직 부분이라고 생각한다.
쿼리는 따로 검증의 대상이 되어야 한다고 생각한다.
죄송해요 이 이후부터는 잘 못 적었어요 ㅋㅋ ㅜㅜ

피드백

말을 적당한 속도로 차분하게 잘 말했다.
개발에 대한 확실한 자기 주관이 있다는 생각이 들어서 좋았다.
말을 더듬는 부분이 없이 명확한 답변을 해주셔서 좋았다.
대답을 하다 보면 질문에 대한 답이 아닌 다른 답을 할 때가 있었다. 꼬리 질문을 하다보면 원래 질문에서 멀어진 답을 한 적이 있어서 그 부분을 신경 써주시면 좋을 것 같다 ˙ᵕ˙

필립

속기

이전에는 기능적으로 할 수 있는 단위로 커밋했었는데 실행 가능한 단위로 커밋하는 것이 좋아보인다.
언제 hashcode, equals를 하거나 하지 않나요? : 단순 기능 구현을 위해 사용한다기보다는 같은 것으로 확인하는 경우에는 동등하다고 생각한다. 그 외의 경우에는 ...
인덱스만 같으면 동등한가요?
자바의 hashcode 내부 알고리즘은 알고 계신가요?
미션 수행 하시면서 null 반환을 하셨나요 아니면 Optional을 반환하셨나요?: 굳이 해야 한다면 Optional을 리턴하거나 예외를 반환하는 방식으로 구현했다.
Optional을 굳이 쓰는 이유가 있나요? : null을 반환하게 되면 실행 결과를 받는 곳에서 null 체크를 하는지 확인해야 한다. Optional을 사용하면 빈값인지 아닌지 확인하는 것을 명시적으로 할 수 있어서 좋다.
이번 미션에서 상속과 조합을 어떻게 적절하게 사용하셨나요? : 체스 미션의 기물에서는 상속을 사용했습니다. 킹, 퀸이라는 각자의 기물들 종류가 기물에 포함 관계가 확실하기 때문에 사용했습니다. 조합의 경우는 블랙잭 때 사용했다. Money를 만들고 BettingMoney가 Money를 인스턴스로 사용했었다.
모든 동등성을 가진 객체가 캐싱이 필요한가요?: 반복적으로 생성하는 일이 많을 때 하는것이 좋다.
그런 경우가 어떤 경우가 있을까요?: 체스 판에서의 위치 정보를 표현할 때. 매 이동마다 시작점과 끝점, 사이의 점을 계속 생성해야 해서, 이런 경우 캐싱을 사용하면 좋을 거 같다.
캐싱을 할 때 고려할 점이 있을까요?:
캐싱을 할 때 문제가 발생할 수 있는 점이 있을까요? : 캐싱을 한 객체가 불변 객체가 아닌 경우 다른 곳에서 값이 변경되면 캐싱 내부의 객체 값이 변경되어 사용하는 다른 곳도 값이 변경되게 된다.
상태 패턴을 어떻게 쓰셨나요?: 체스에서 게임 상태를 표현할 때 사용했다. 각각의 경우에 따라 체스의 말을 움직이거나 명령을 내렸을 때 기능을 수행할 수 있는지 없는지 구분이 필요할 때 사용했다.
전략 패턴에 대해서 아시나요?: 정확하게는 잘 모른다. 행위를 해야 할 때 행위에 대한 의미나 행위를 통해 나와야 할 결과물이 정해졌을 때, 결과물을 만드는 방법이 다른 경우 다양한 전략들을 생성해두고 필요에 따라 구현된 전략을 사용할 수 있는 것이 전략 패턴인 것 같다.
상태 패턴과 전략 패턴을 비교해서 설명해주세요.: 전략은 한 번 정해진 전략을 잘 바꾸지 않는 것 같다. 상태 패턴은 진행되면서 유연한 변화가 가능하다는 차이가 있다. 변경된 상태를 반환하는 방법으로 새로운 상태를 반환할 수 있다.
DTO를 생성할 때 도메인을 전달 받도록 하셨나요? : 도메인이 내부에 포함되게 되면 뷰에서 받을 때 도메인 객체를 그대로 가져올 수 있게 되어서 숨기고 싶은 정보들도 공개될 수 있다. 그래서 DTO를 생성할 때 풀어서 주는 편이다.
파라미터가 너무 많아지지 않나요? : 도메인의 정보를 숨기는 것이 우선시 되어야 한다고 생각한다.
도메인의 정보를 어떤 이유로 숨겨야 할까?
이번 미션에서 숨겨야 하는 경우가 존재했나요?: 체스에서 기물에 대한 정보를 꺼내서 사용했는데, 기물 자체가 자신이 이동한 위치의 기물을 반환하는 기능을 갖고 있었다. 기물 정보를 그대로 보내면 뷰에서 기물을 조작할 수 있기 때문에 이를 막기 위해 사용했다.
도메인과 뷰를 개발한 사람이 달랐나요?: 혼자서 개발한다고 하면 굳이 DTO를 쓸 필요가 없다고 생각한다. 연습하고 공부하는 입장에서 언젠가 함께 일하는 상황을 연습하려고 사용해보고 있습니다.
프로젝트가 길어지게 되면 유지보수를 하고 다음에 사용할 때도 어떤 목적을 위해 전달했는지 확실히 하기 위해 썼다는 걸 명시해줄 수 있다. 그런 경우 DTO를 사용하는 것이 좋아보인다.
도메인 하나만 전달하면 값을 전달하는 것보다 유지 보수가 편하지 않을까요? : 도메인이 변하거나 뷰가 변하는 사항이 있을 때 도메인에 대한 변화까지 전파될 수 있어서 좋지 않다고 생각한다.
방어적 복사를 사용하게 되면 굳이 DTO를 사용하지 않아도 되지 않을까요? 훼손이 문제라면?: 훼손만 문제가 된다면 내부적으로 변화에 대한 것은 막을 수 있지만 ... ()
모델 뷰 컨트롤러는 레이어인가요?: 목적이 다르니까 레이어라고 봐도 된다고 생각합니다.
일단 뷰에서 컨트롤러로 올 때는 원시 타입으로 받을 수 있을 때는 그대로 받고 연관이 되는 데이터를 받아서 합쳐서 보낼 때에는 DTO를 사용했습니다. 컨트롤러에서 도메인으로 넘길 때도 단순한 하나의 원시값이나 문자열로 보낼 때는 그냥 보내지만 연관된 정보가 있는 경우에는 DTO를 리턴합니다.
본질적으로 DTO라는 것은 왜 생겼을까요?: 제가 생각했을 때 어떤 한 쪽의 변화가 다른 한 쪽으로 전파되는 것을 최대한 막기 위해서입니다.
도메인에 DTO는 왜 필요할까요?: 도메인 객체에 대한 것을 다른 곳에서 모르게 하기 위해서.

피드백

꼬리질문이 계속해서 이어졌는데 최대한 열심히 대답하려고 하는 모습이 좋았습니다.
미션에서 직접 사용한 내용에 대해서 작성한 것이 느껴져서 좋았습니다.
모르는 부분에 대해서 미리 인정하는 것이 좋았습니다. 잘 모르겠는 부분을 인정해주셔서 좋았습니다.
꼬리 질문이 이어질 때 약간 당황하는 모습이 보였는데 답변 잘 이어나갔던 것 같습니다.
'이제' 라는 단어가 당황할 때 자주 언급되는 것 같습니다.

달리

속기

미션 하면서 TDD로 개발했는데, TDD의 장점과 힘든 점이 있었을까요?: 여러 가지 객체들이 이런 기능을 갖겠다, 라는 일종의 방향성을 갖는 장점이 있었습니다. 프로덕션 코드가 변경이 될 때마다 테스트 코드를 고쳐주는 과정에서 오히려 시간이 오래걸렸다.
프로덕션 코드를 고치면서 테스트가 깨졌던 경험이 있었나요? : 처음에 TDD를 하면서 이런 방향성을 갖고 작성했지만, 이후 놓쳤던 부분이 발견되기도 하여서 변경 사항이 생겼습니다. 설계적인 부분에서 문제가 발생한 경우에도 문제가 생겼었다.
달리가 생각하는 리팩토링의 정의란 무엇인가요?: 기능적인 면이나 프로덕션 코드를 구현했음에도 유지보수 측면에서 좋은 방향으로 만들거나 변경할 때가 리팩토링이라고 생각합니다.
테스트 코드를 고치는 것도 리팩토링일까요? : 같은 기능을 하되 설계적 측면에서 변경이 될 수도 있기 때문에 유지보수 측면에서 코드 추가적인 수정이 필요할 때는 필요하다면 리팩토링이라고 할 수도 있을 거 같다.
객체에 물어보지 말고 일을 시키는 것을 지양해야 하는 이유가 무엇인가요?: 자동차 미션 때 왜 getter를 지양해야 하는가에 생각해야 했다. 책임을 객체에게 주라는 뜻으로 이해했다.
JUnit5와 JUnit4의 차이?: 모르겠다.
원시값 포장, 값 객체 모두 값을 포장하는 것인데 차이점이 뭐가 있을까요?: 원시값 포장은 어떤 값을 포장함으로써 유효성 검사를 내부에서 할 수 있기 때문에 사용한다. 다른 값들과의 비교가 필요한 경우 값 객체를 사용한다.
extracting 메서드를 사용한 이유는 무엇인가요?: 체스 미션에서 64개의 칸을 갖고 있는지 확인하기 위해 사용했다. 테스트로 제대로 확인하기 위해 extracting을 사용했습니다.
private을 테스트 하는 이유는 무엇인가요?: 테스트를 위해 public을 사용하지 않기 위해서 사용했다.
private으로 막아두는 이유는? : 외부에서 값을 감추기 위해서
테스트에서는 열어서 검증할 필요가 있을까?: 특수한 상황이었다. 생성과 관리를 내부에서 하기 때문에 프로덕션에서는 감춰져 있지만 테스트에서는 해야 할 거 같다.
다른 방법으로 해결할 수 있는 방법이 있을까?: 찾지 못했다.
equals를 사용해서 해시코드를 비교하는 방법도 있었을 것 같은데 어떤가요?: 테스트를 위해 equals, hashcode를 만드는 것은 getter를 만드는 것과 차이가 없다고 생각한다.
getter를 안 만들어야 하는 이유가 있나요? : 캡슐화를 깨는 것이고, 프로덕션 로직에도 필요 없어서 테스트에서 해결하는 방법인 extracting을 사용하였다.
extracting을 사용해서 생기는 문제점이 있을까요?: 하드코딩이기 때문에 문제가 될 것이라고 생각했다. getter를 추가하거나 프로덕션 코드를 바꾸느니 extracting을 사용하는 것이 나은 거 같다.
책임 연쇄 패턴과 상태 패턴을 어떤 경우에 사용하셨나요?: 책임 연쇄 패턴은 같은 요청에 따라 자동적으로 구현체가 정해지고 고르게 되어 어떤 움직임을 하는지 알기 위해 사용했다. 상태 패턴을 통해 체스 게임의 상태를 관리했다.
다형성에 대해 설명해주세요.: 추상적인 것을 통해 어떤 것을 추상화하고 입력을 했을 때 추후에 입력할 것을 정의해서 유지보수 차원에서 유연하게 한다.
어떤 부분에서 유지보수가 좋나요?
좋은 객체지향은 무엇일까요?: 객체가 응답과 요청을 통해서 객체 스스로가 일을 시키게 하는 것이 좋은 객체 지향인 것 같다. 객체의 상태를 변하게 함으로써 시스템이 돌아가게 하는 것이 객체지향이라고 생각한다.
SOLID 중에서 인상 깊었던 원칙이 있을까요?: open-closed 원칙.
본인 미션에서 그런 부분을 지키고자 노력했던 순간이 있었나요?: 단일 책임 원칙을 지키려고 노력했다. 가장 작은 단위를 갖도록 노력했다. 각 객체들이 하나의 책임만을 가질 수 있게 유도할 수 있어서 최대한 단일 책임 원칙을 지키려고 했다.
하나의 책임을 정의하는 본인만의 기준점이 있을까요?: 정확한 단계나 선이 없어서 찾기 힘들었다. 자신에게 꼬리 질문을 하면서 최대한 줄이려고 노력했다.
체스 미션 구현 중에 단일 책임 원칙을 지키지 못한 부분이 있는 것 같습니다.
체스 미션 중에 데이터 베이스 연동하면서 인상 깊었던 부분, 신경 쓴 부분이 있을까요?
MVC 패턴과 레이어는 어떤 차이가 있을까요?
서비스를 테스트할 때 어떻게 하셨나요?
컨트롤러는 테스트 하지 않은 이유가 있을까요? : 도메인과 뷰를 분리해주는 역할이라 생각해서 뷰의 테스트를 하지 않기 때문에 컨트롤러도 하지 않았다. 컨트롤러가 뷰로 보내주는 데이터들을 확인하는 테스트를 작성했다. 그러나 하면 할수록 큰 로직이 없어서 테스트를 하지 않아도 될 것 같았다.
뷰를 테스트 하지 않은 이유가 있을까요? : 현업에서는 협업을 하게 되기 때문에 뷰를 구현하는 부분은 확인하지 않아도 된다고 생각했습니다.
큰 로직이 아니면 테스트를 하지 않아도 되나요?

피드백

전체적으로 말이 빨라서 말이 밀리는 경우가 있었습니다.
본론이 앞에 나오면 좋을 것 같다.

질문자와 눈을 맞추려고 하는 모습이 집중하고 있다는 인상을 주는 것 같습니다.
모르는 부분을 말하고 알고 있는 부분을 최대한 말하는 모습이 좋았습니다.
미션 내용과 연관지어서 말해주셔서 어떤 부분에서 사용하셨는지 이해하기 쉬웠습니다.

제나

속기

모든 하위 클래스에서 재정의했을 때 문제가 발생하신적이 있나요?: 디버깅할 때 쓰면 유용하다고 해서 작성했습니다. toString은 디버깅 용도입니다. 프로덕션 요구사항이 변경되면 도메인의 toString을 고쳐야 하기 때문입니다.
왜 뷰가 변할 때 도메인이 변하면 안 될까요? : 뷰는 변화가 잦은 곳이라서 도메인도 함께 변경되면 안정적인 도메인이 아니게 됩니다.
도메인이 변할 확률이 굉장히 적은 경우에서는 변경될 여지가 없는데, 도메인이 뷰에 대한 정보를 가지고 있더라도 괜찮지 않을까요?: 도메인에서 꺼내기보다는 도메인을 뷰로 전달할 때 매핑 객체를 만드는 것이 좋아보인다.
기계적으로 toString을 정의하게 되면 프로덕션 코드가 변경되는 경우 디버깅 시에 오류가 생길 수 있다. 언제쯤 toString을 오버라이딩 하는 것이 좋을까?: 객체 생성시에 toString을 오버라이딩 한다.
Object 클래스에 있는 메소드들에 어떤 것들이 있을까요?: clone, toString, equals, hashcode 정도 알고 있습니다.
A가 B를 가지고 있고, B가 A를 가지고 있으면 toString 시에 문제가 생기지 않을까요?: A가 변경되었을 때 B도 재정의를 해줘야 해서 문제점이 있을 것 같습니다.
실제로 테스트 코드를 도입함으로써 어떻게 시간 절감을 실감하셨나요?: 나중에 리팩토링 과정을 거치면서 코드가 안정적으로 동작하는지 테스트 코드로 검증할 수 있어서 시간이 절약되는 것을 실감할 수 있었습니다.
원시값 포장과 VO의 차이는 무엇이 있을까요?: 원시값 포장은 값을 포장한 것이고, VO는 동등성과 자기 유효성 검사도 할 수 있고, 불변이어야 한다는 특징이 있습니다.
원시값 포장은 동등성이 보장되지 않나요?: 동등성 주소값이 다를 때 값이 같으면 같은 것으로 판단하는 것으로 알고 있습니다.
사다리 미션에서 원시값 포장을 어떻게 하셨을까요?: 사다리의 높이, 플레이어 이름 등을 원시값 포장을 해줬습니다.
그 객체들은 VO는 아닌가요?: Name은 VO로 바꿔주었습니다.
불변 객체로 만드는 것과 가변 객체를 나누는 기준이 있으셨나요?: 보통은 불변 객체로 만들었다. 가변 객체는 계속 바뀌는 것들을 선언했습니다.
일급 컬렉션을 가변이 아닌 불변으로도 선언하실 수 있으셨을텐데 그 부분에 대해 고민해보셨나요?
객체를 한 번 생성하는데 비용이 많이 드나요?: JVM을 믿고 맡기면 된다고 생각하지만, 객체 생성에 대한 오버헤드는 많이 고려하지 않아도 된다고 생각합니다.
Java8에 추가된 큰 변화는 어떤 것이 있을까요?
기존의 for문과 stream은 어떤 차이가 있을까요? stream에 대해서 설명해주세요: 파이프라인을 지나가듯이 돌리면서 요소 하나하나에 적용하고 싶은 operator들을 적용 시켜서 원하는 것들을 만들어줍니다. 중간 operator가 있고 종단 operator로 완료해 주어야 합니다. 종단 operator가 들어오면 그때 연산이 일어나서 stream을 할 수 있습니다. 사용하는 장점은 Collection을 돌면서 필터를 걸거나 match를 사용하는 경우 편리합니다.
해당 기능은 단순 for문으로도 할 수 있지 않나요?: 가독성 측면에서 stream으로 구현하는 것이 좋을 때가 있다고 생각합니다.
stream이 for문보다 가독성이 좋다는 근거가 있을까요?: for 문은 어떤 컬렉션 안의 객체를 정의해주고 하나씩 돌려야 하는데, stream은 stream으로만 변환해주면 알아서 실행해주니까 더 편하다고 생각합니다.
속도 측면에서는 어떻게 생각하시나요?
일단은 for문이 더 빠르다는 건가요?
충분히 메소드 분리를 통해 개선 여지가 있지 않나요?: 이중 for문을 사용하는 경우는 메소드 분리를 진행했습니다. 학습 목적과 가독성 측면에서 stream을 많이 사용했습니다.
for문의 가독성이 더 좋다고 생각하는 페어라면 어떻게 하실건가요?: 가독성과 성능 비교를 해보고 페어의 의견에 맞춰줄 것 같습니다.
페어에 맞춰주지 못하는 부분이 있나요?: 메서드 중간에 공백을 두는 부분은 소신을 지키고 있습니다.
테스트 하실 때도 공백을 두지 않으시나요?: 프로덕션에서만 두지 않는 편입니다.
view가 도메인에 의존하지 않아야 하는 이유는 무엇일까요?: 도메인 객체에 접근할 수 있기 때문에 뷰에 필요하지 않은 정보에도 접근할 수 있습니다.
뷰에서 값을 보여줘야 하는데 도메인에서 가져오지 않으면 어떻게 가져오나요?: 도메인의 값을 원시값으로 풀어서 전달합니다.
종단 연산에 관련된 함수 몇 개만 말씀해주세요. : foreach, count, sum
findAny, findFirst도 종단 연산일까요?
findAny, findFirst는 어떤 차이가 있나요?
shuffle이 된다는 것은 어떤 의미인가요?
stream을 사용하게 되면 리스트를 구성하는 순서가 바뀌게 되나요?
stream에서 중간 연산을 사용할 때 주의해야 할 점이 있을까요?: 실행이 안 되고 있다가 종단 연산이 오면 실행하는 거라서 단일 스트림이 아닌 병렬로 진행하면 고려해줘야 한다.
map, sorted, filter가 있을 때 어떤 순서로 배열해야 효율적일까요?
stream을 반환값으로 사용하면 안 된다고 하는데 왜 반환값으로 사용하면 안 되는지 설명해주실 수 있나요?
stream의 forEach를 지양해야 하는 이유가 무엇인지 말씀해주세요.

피드백

말을 더듬지 않고 차분한 어조로 말해주셔서 하고 싶은 말이 무엇인지 잘 전달됐습니다.
어려운 질문이 많았는데 꼬리 질문에 잘 대답하는 부분이 좋았습니다.
질문 답변이 간결해서 좋았습니다. 정확하게 질문에 대한 답변이 주어져서 좋았습니다.

인터뷰어의 페이스에 말리는 부분이 있어서 조금 아쉬웠습니다.
준비했던 말보다 페이스에 말린 질문을 많이 받은 것 같아서 안타까웠습니다.

여우

질문

in-out 설계와 out-in 설계 중에서 현재는 어떤 것을 선호하시나요? out-in 방식이 좋은 경우에는 어떤 때가 있을까요?
단위 테스트를 작성하는 자신만의 기준이 있으신가요?
생성자 주입을 하지 않고 내부에서 값을 생성하는 경우가 좋았던 적이 있으신가요?
getter는 어떤 경우에 사용해야 한다고 생각하시나요?
서비스 레이어가 필요한 경우는 어떤 경우라고 생각하시나요? 현재 미션에서 서비스 레이어를 사용해야 하는 경우가 있으셨나요?
현재는 void 메서드를 테스트하시나요?
현재는 예외 발생 이유를 구분해서 테스트하고 계신가요? 보완하는 방법으로는 어떤 방법이 있을까요?
어느 정도까지 단위 테스트를 작성해야 한다고 생각하시나요?
블랙잭 미션에서 생성자 주입 이야기가 나왔는데, 현재는 고정적이지만 값이 변경되는 경우의 확장성을 고려해서 생성자 주입을 하는 것이 좋지 않을까요?
딜러와 참가자 객체 사이에 유의미한 차이가 없어지도록 어떻게 하셨는지 알려주실 수 있으실까요?
tdd의 필요성에 대해 어떻게 생각하시나요?
static은 언제 사용하는 것이 좋을까요? 객체 인스턴스 생성과 static을 사용하는 여우만의 기준이 있을까요?

피드백

눈을 마주치면서 말한 부분이 좋았습니다.
쉽게 풀어서 이야기 하는 부분이 좋았고, 어떤 경험으로부터 이런 생각을 하게 되었는지 말해주셔서 좋았습니다.

제 기준에서는 말이 조금 느렸던 것 같습니다.
질문에 대한 대답이 뒤쪽에 있어서 아쉬웠습니다.