김동형수 개발기

4장 프라이버시 할일목록 $5 + 10CHF = $10(환율이 2:1일 경우) $5 X 2 = $10 amount를 private로 만들기 Dollar 부작용? Money 반올림? equals() hashCode() Equal null Equal object Dollar.times() 연산은 결과값을 Dollar 인스턴스를 반환해야 한다. 하지만 테스트가 정확히 그것을 말하지는 않는다. assertion을 Dollar와 Dollar를 비교하는 것으로 재작성할 수 있다. 임시변수인 product는 제거한다. 변경된 코드에서는 amount필드에 public하게 접근하지 않아서 private로 변경할 수 있다. 할일목록 $5 + 10CHF = $10(환율이 2:1일 경우) $5 X 2 = $10 amount를..

3장 모두를 위한 평등 Dollar 객체같이 객체를 값처럼 쓸 수 있는데 이것을 값 객체 패턴 (value object pattern)이라고 한다. 값 객체의 대한 제약사항 중 하나는 객체의 인스턴스 변수가 생성자를 통해서 일단 설정된 후에는 결코 변하지 않는다는 것이다. 값 객체를 사용하면 별칭 문제에 대해 걱정할 필요가 없는 아주 큰 장점이 있다. 값 객체가 암시하는 것 중 하나는 2장에서와 같이 모든 연산은 새 객체를 반환해야 한다는 것이다. 또 다른 암시는 값 객체는 equals()를 구현해야 한다. 할일목록 $5 + 10CHF = $10(환율이 2:1일 경우) $5 X 2 = $10 amount를 private로 만들기 Dollar 부작용? Money 반올림? equals() hashCode()..

2장 타락한 객체 일상적인 TDD 주기 1. 테스트를 작성한다. 오퍼레이션 코드 상상, 인터페이스 개발, 필요한 요소 모두 포함 2. 실행 가능하게 만든다. 가장 중요한 것은 테스트를 통과 시키는 것이다. 구현하는 방법이 생각이 났어도 메모해놓고 단순한 방법으로 해결 3. 올바르게 만든다. 중복을 제거하고 테스트를 통과시키자. 작동하는 깔끔한 코드를 얻는 것은 최고의 프로그래머조차도 도달하기 힘든 목표일 수 있다. '작동하는', '깔끔한 코드'를 나눠서 부분적으로 해결하자. 할일목록 $5 + 10CHF = $10(환율이 2:1일 경우) $5 X 2 = $10 amount를 private로 만들기 Dollar 부작용? Money 반올림? 테스트를 통과했지만 뭔가 이상하다. Dollar에 대해서 연산 수행 ..

1부 화폐 예제 TDD의 리듬 1. 재빨리 테스트를 하나 추가한다. 2. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다. 3. 코드를 조금 바꾼다. 4. 모든 테스트를 실행하고 전부 성공하는지 확인한다. 5. 리펙토링을 통해 중복을 제거한다. TDD를 통해 놀랄 것 - 각각의 테스트가 기능의 작은 증가분을 어떻게 커버하는지 - 새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지 - 얼마나 자주 테스트를 실행하는지 - 얼마나 수 없이 작은 단계를 통해 리팩토링이 되어가는지 1장 다중 통화를 지원하는 Money 객체 다중통화가 지원되는 리포트에는 아래의 테스트들이 통과해야 정상적인 동작을 한다고 확신할 수 있다. - 통화가 다른 두 금액을 더해서 주어진 환율에 맞게 변한 금액을..

아키텍처 스타일 결정하기 도메인이 왕이다 헥사고날 아키텍처는 영속성 관심사나 외부 시스템에 의한 의존성 등의 변화로부터 자유롭다. 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치다. 영속성 문제나 다른 기술적인 측면에 대해서 함께 생각할 필요가 없게 되면 도메인에 대해 가장 잘 고려할 수 있게 된다. DDD(도메인 주도 개발) 도메인을 중심에 두는 아키텍처 없이는, 도메인 코드를 향한 의존성을 역전시키지 않고서는, DDD를 제대로 할 가능성이 없다. 도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면 이 아키텍처 스타일은 필요하지 않을 것이다. 경험이 왕이다 경험에 의해서 습관처럼 계층형 아키텍처 스타일을 이용한다. 과거에..

의식적으로 지름길 사용하기 잠재적인 지름길에 대한 인식을 높이고 그 영향에 대해 이야기한다. 이 정보만 있어도 우발적으로 사용되는 지름길을 인식하고 수정할 수 있다. 정당한 지름길이라면 지름길의 효과를 의식적으로 택할 수도 있다. 어떤때는 (의식적으로)지름길을 먼저 취하고 나중에 고치는 것이(혹은 아예 고치지 않더라도) 실제로 더 경제적일 수도 있다. 왜 지름낄은 깨진 창문 같을까? 깨진 창문(유리창) 이론 : 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다. 출처 - https://ko.wikipedia.org/wiki/%EA%B9%A8%EC%A7%84_%EC%9C%A0%EB%A6%A..

아키텍처 경계 강제하기 일정규모 이상의 프로젝트에서는 시간이 지나면서 아키텍처가 서서히 무너지게 된다. 계층간의 경계가 약화되고 코드는 점점 더 테스트하기 어려워진다. 이번 장에서는 아키텍처 내의 경계를 강제하는 방법과 아키텍처 붕괴에 맞서는 몇가지 조치를 살펴본다. 경계와 의존성 애플리케이션 계층은 애플리케이션 서비스안에 유스케이스를 구현하기 위해 도메인 엔티티에 접근한다. 어댑터는 인커밍 포트를 통해 서비스에 접근, 반대로 서비스는 아웃고잉 포트를 통해 어댑터에 접근한다. 설정 계층은 어댑터와 서비스 객체를 생성할 팩터리를 포함하고 있고, 의존성 주입 메커니즘을 제공한다. 아키텍처의 경계는 명확하다. 각 계층 사이, 안쪽 인접 계층과 바깥쪽 인접 계층 사이에 경계가 있다. 의존성은 항상 안쪽 방향으로..

애플리케이션 조립하기 애플리케이션이 시작될 때 클래스를 인스턴스화하고 묶기 위해서 의존성 주입 메커니즘을 이용한다. 평범한 자바, 스프링, 스프링 부트 프레임워크에서 각각 어떻게 하는지 살펴본다. 왜 조립까지 신경 써야 할까? 코드의존성이 올바른 방향을 가리키게 하기 위해서 모든 의존성은 안쪽으로 ( 웹 -> 영속성 ) 유스케이스가 영속성 어댑터를 호출하는 케이스를 만들지 않기 위해서 아웃고잉 포트 인터페이스 생성 유스케이스는 인터페이스만 알고(참조하고) 있어야한다. 헥사고날 아키텍처의 유익한 부수효과 중 하나는 코드를 휠씬 쉽게 테스트할 수 있는 것이다. 의존성이 있는 모든 객체를 생성자로 전달할 수 있다면 mock으로 전달할 수 있고 이는 격리된 단위 테스트를 생성하기가 쉬워진다. 설정 컴포넌트는 애..