아기개발자의 성장일기

단위 테스트 1~3장 내용을 기반으로 하고 있습니다. 1장 단위테스트의 목표 # 단위테스트 현황 논쟁은 '단위 테스트를 작성해야하는가?' 에서 '좋은 단위 테스트를 작성하는 것은 어떤 의미인가?' 로 바뀌었다. # 단위테스트의 목표 - 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것 지속가능한 프로젝트 성장을 위해서는 고품질 테스트에만 집중해야한다. (사람들은 종종 테스트가 많으면 많을 수록 좋다고 생각한다. 하지만 그렇지 않다. 코드는 자산이 아니라 책임이다. 코드가 많아질 수록, 소프트웨어 내의 잠재적인 버그에 노출되는 표면적이 더 넓어지고 프로젝트 유지비가 증가한다.) 테스트는 코드의 단위가 아니라 동작의 단위. 즉 문제 영역에 의미가 있는 것. 이상적으로는 비즈니스 담당자가 유용하다고 ..

단위 테스트 3장 내용을 기반으로 하고 있습니다. [ 저자가 생각하는 단위테스트 네이밍 안티패턴 ] 1. 엄격한 명명구조 가장 유명하지만 가장 도움이 되지 않는 방법 중 하나가 다음과 같은 관습이다. [테스트 대상 메서드]_[시나리오]_[예상결과] - 테스트 대상 메서드: 테스트 중인 메서드의 이름 - 시나리오: 메서드를 테스트하는 조건 - 예상결과: 현재 시나리오에서 테스트 대상 메서드에 기대하는 것 동작 대신 구현 세부사항에 집중하게끔 부추기기 때문에 분명히 도움이 되지 않는다. 간단하고 쉬운 영어 구문이 훨씬 더 효과적이다. 예를들어 public class CalculatorTests { public void Sum_of_two_numbers() { ... // when double result =..

회사에서 TDD 관련 외부세션을 듣다가 '서비스가 안티패턴' 이라는 말을 들었다. 왜 안티패턴일까..? 머리에 궁금증이 남아있었는데 클린아키텍처 27장('크고 작은 모든' 서비스들) 을 읽으며 이유를 알게 되었다. 그래서 정리! (참고로 책을 쭉 이끌어온 저자의 맥락을 이 요약글에 다 담을 수 없으니.. 책을 읽어보시는 것을 추천드립니다.) [1] 서비스 아키텍처? 서비스의 이점? 서비스 지향 '아키텍처' 와 마이크로서비스 '아키텍처' 는 최근에 큰 인기를 끌었다. 그 이유는 다음과 같다. - 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. // 결합 분리 - 서비스를 사용하면 개발과 배포 독립성을 지원하는 것 처럼 보인다. // 개발 및 배포 독립 둘다 일부만 맞는 말이다. 뒤에서 살펴..

[1] 서론 업무로 모듈화를 진행하고 있는데, cyclic dependency가 생각보다 많았다,,, 폴더 구조일 때는 편하게 이곳저곳 다 참조하고 있던 코드들이 모듈 구조로 바뀌니 그제야 아픈 곳을 드러내기 시작했다.. 22장 > 클린아키텍쳐 에 나오는 이 내용을 알고 있었으나.. 소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다. 내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다. 특히 내부의 원에 속한 코드는 외부의 원에 선언된 어떤 것에 대해서도 그 이름을 언급해서는 절대 안된다. 이것을 지키려면 수정범위가 많으니까,,, 적당히... 타협해도 되지 않을까....?.... 내부의 원도.... 외부의 원을.... 조금... 알 수...있게..... 그럼...양방향.....

클린아키텍처 11장 DIP - 의존성 역전원칙 을 읽다가 Abstract Factory 에 대해 여러 고민이 들어서 기록! [1] 책 내용 객체를 생성하려면 해당 객체를 구체적으로 정의한 코드에 대해 소스 코드 의존성이 발생하게 된다. 이런 의존성을 처리하기 위해 추상 팩토리를 사용한다. 예를들어 Application은 ConcreateImpl 에 대한 소스 코드 의존성을 만들지 않기 위해 ServiceFactory 인터페이스의 makeSvc 메소드를 호출하고 ServiceFactoryImp 구현체가 ConcreateImpl 의 인스턴스를 생성한 후 Service 타입으로 반환한다. 곡선은 아키텍쳐 경계를 뜻하는데, 구체적인 것들로부터 추상적인 것들을 분리한다. [2] 경험 + 구글링 보통 Factory..

마틴 파울러 - 리팩터링 (2판) 의 12장 - 상속 다루기 중 좋았던 것들 기록 ✏️✏️ 12.6 타입 코드를 서브클래스로 바꾸기 (Replace Type Code with Subclasses) 보통 열거형, 문자열, 숫자 등의 타입 코드를 쓴다. 타입코드만으로도 특별히 불편한 상황은 별로 없지만 그 이상의 무언가가 필요할 때가 있다. 여기서 '그 이상' 이라 하면 바로 서브클래스를 가리킨다. 서브클래스는 두 가지 면에서 특히 매력적이다. 1. 조건에 따라 다르게 동작하도록 해주는 다형성을 제공 (타입 코드에 따라 동작이 달라져야하는 함수가 여러 개일 때 특히 유용) 2. 특정 타입에서만 의미가 있는 값을 사용하는 필드나 메서드가 있을 때 (필요한 서브클래스만 필요한 필드를 가지도록 하여 더 명확) 이..

마틴 파울러 - 리팩터링 (2판) 의 11장 내용 중 좋았던 것들 기록 ✏️✏️ 11.4 객체 통째로 넘기기 객체를 통째로 넘기면 - 변화에 대응하기 쉽다. - 매개변수 목록이 짧아져서 일반적으로 함수 사용법을 이해하기 쉬워진다. 하지만 함수가 객체 자체에 의존하기를 원치 않을 때는 이 리팩토링을 수행하지 않는다. 특히 객체와 함수가 서로 다른 모듈에 속한 상황이면 특히 더 그렇다. 어떤 객체로부터 값 몇 개를 얻은 후 그 값들로만 무언가를 하는 로직이 있다면 그 로직을 객체 안으로 집어넣어야함을 알려주는 악취로 봐야한다. ==> '객체 통째로 넘기기 vs 객체에서 값 몇개를 꺼내 파라미터로 넘기기'는 개발하며 자주 고민되는 이슈이다. 나도 객체와 함수가 서로 다른 모듈에 속해있는 경우 통째로 넘기기를 ..

마틴 파울러 - 리팩터링 (2판) 의 10장 내용 중 좋았던 것들 기록 ✏️✏️ 10.4 조건부 로직을 다형성으로 바꾸기 조건부 로직(특히 switch문)을 다형성으로 바꾸는 것은 오브젝트에서도 많이 나온 내용이다. 어디서부터 시작할 지 막막할 수 있는 리팩토링인데, 리팩터링 과정을 절차화해주셔서 진행하기 쉽게 해주신 게 좋았다. [ 절차 ] (아래 절차는 책이랑 다르게 제가 순서를 조금 수정한 부분이 있습니다!) 1단계 다형적 동작을 표현하는 클래스들이 아직 없다면 만들어준다. 조건부 로직 함수를 슈퍼클래스로 옮긴다. (조건부 로직이 온전한 함수로 분리되어 있지 않다면 먼저 함수로 추출한다) 2단계 적합한 인스턴스를 알아서 만들어 반환하는 팩터리 함수도 함께 만든다. 호출하는 코드에서 팩터리 함수를 사..

마틴 파울러 - 리팩터링 (2판) 의 9장 내용 중 기억하고 싶은 것 기록 ✏️✏️ 9.4 참조를 값으로 바꾸기 (change Reference to Value) - 참조로 다루는 경우: 내부 객체는 그대로 둔 채 그 객체의 속성산 갱신함. - 값으로 다루는 경우: 새로운 속성을 담은 객체로 기존 내부 객체를 통째로 대체함 값 객체는 불변이기 때문에 자유롭게 활용하기 쉽다. 불변 데이터 값은 프로그램 외부로 건네줘도 나중에 그 값이 나 몰래 바뀌어서 내부에 영향을 줄까 염려하지 않아도 된다. 값을 복제해 이곳저곳에서 사용하더라도 서로간의 참조를 관리하지 않아도 된다. 그래서 값 객체는 분산 시스템, 동시성 시스템에서 특히 유용하다. 9.5에서 나오지만.. 이런 값 객체의 특성 때문에 이번 리팩터링을 적용..

마틴 파울러 - 리팩터링 (2판) 의 7장 내용 중 기억하고 싶은 것 기록 ✏️✏️ 6장에서는 기본적인 리팩터링 기법들을 설명해주십니다. (함수 추출하기 / 함수 인라인 하기 / 이름 바꾸기 / 매개변수 객체 만들기 등등) 7장에서는 캡슐화를 주제로한 리팩터링 기법들을 설명해주시는데 인상깊은 몇가지만 기록합니다. 7.1 레코드 캡슐화 하기 (Encapsulate Record) (위의 예제랑 다른 예제에 대한 설명입니다,,) .... 클라이언트가 데이터 구조를 요청할 때 실제 데이터를 제공해도 된다. 하지만 클라이언트가 데이터를 직접 수정하지 못하게 막을 방법이 없어서 '모든 쓰기를 함수 안에서 처리한다' 는 캡슐화의 핵심 원칙이 깨지는게 문제이다. 그래서 내부데이터를 복제해서 제공한다. get rawDa..