군만두의 IT 공부 일지

목차  드디어 이 책을 마무리하게 되었다. 여기서는 테스트를 SOLID 법칙에 따라 어떻게 설계하는지 설명한다. 책을 읽으면서 SRP에서는 실제 프로젝트에서 팀원이 튜터님한테 Repository 의존성을 많이 주입받고 있다고 지적받은 상황이 떠올랐다. 이런 부분을 유의해야 할 것 같다.16 . 테스트와 설계테스트와 소프트웨어 설계가 추구하는 가치에 교집합이 있다. 좋은 설계는 시스템이 모듈로 분해되고 각 모듈이 독립적으로 개발될 수 있게 하는 것을 추구한다. 더 나아가 시스템이 확장될 수 있는 것을 추구한다. 좋은 설계를 갖춘 코드는 대부분 테스트하기도 쉽다.테스트와 좋은 설계1. 테스트하기 어려운 코드는 좋은 설계 원칙을 적용함으로써 테스트하기 쉽게 만들 수 있다.2. 어떤 방식이 좋은 설계인지 헷갈린..

목차 15 . 테스트 가능성테스트를 '개발이 완료된 후 작성하는 것'이 아니라 '개발 전에 미리 작성하는 것', '개발을 하면서 함께 작성하는 것'으로 보기 시작하면, 개발자는 테스트를 어떻게 하면 쉽게 작성할 수 있을지 고민함으로써 코드의 품질을 높일 수 있다.요약1. Testability: '테스트 가능성'이라는 뜻으로, 테스트하기 쉬운 코드일수록 Testability가 높다.2. 테스트하기 쉬운 코드일수록 좋은 설계일 확률이 높다.15.1 테스트를 어렵게 만드는 요소테스트 가능성(Testability): '테스트하기가 얼마나 쉬운가?'를 뜻하는 용어어떤 코드가 테스트하기 쉬운 코드인지는 테스트하려는 대상의 입력과 출력에 있음.테스트는 테스트하려는 대상의 입력을 쉽게 변경할 수 있고, 출력은 쉽게 검..

목차 14 . 테스트 대역테스트 대역(test double): 실제 객체를 대신해서 행동하고 실제 객체가 하지 못하는 일을 대신함.예) 어떤 코드는 테스트 단계에서 실제로 실행하기 부담스러움. 또는 테스트하는 데 굳이 실제 객체를 사용해야 하는지 모르겠음.테스트 대역을 이용하면 개발자가 테스트를 위한 격리되고 고정된 환경(정상적인 상황, 장애 상황, 타임아웃 상황 등)을 만들 수도 있음.서비스에 가입한 회원에게 이메일 인증을 위해 이메일을 발송하고 대기 상태로 데이터베이스에 저장하는 UserService 코드가 있다고 가정한다.// 사용자가 시스템에 가입하는 상황을 표현하는 UserService@Service@RequiredArgsConstructorpublic class UserServi..

목차 12 . 자동 테스트테스트는 시스템을 어떻게 검증하느냐에 따라 2가지로 분류함.수동 테스트(manual testing): 테스트 담당자가 소프트웨어를 직접 실행해보고 각각의 기능을 평가하며 구현된 기능이 요구사항에 부합하는지 검증하는 과정자동 테스트(automated testing): 테스트 스크립트나 도구를 사용해 소프트웨어를 자동으로 테스트하는 과정테스트 코드: 테스트를 위해 만들어진 코드. 어떤 클래스의 메서드가 제대로 동작하는지, 또는 어떤 서비스나 객체의 능동적인 행동의 결과를 확인하기 위해 작성함.장점: 코드가 추가되거나 변경될 때마다 시스템에 이상이 생겼는지 검사함으로써 시스템의 안정성을 보장함. 한 번 작성된 테스트는 의도적으로 지우지 않는 이상 서비스가 종료되는 순간까지 남아있음.깃..

목차 10. 도메인소프트웨어 공학에서 도메인: 애플리케이션이 해결하고자 하는 문제 영역10.1 소프트웨어 개발의 시작린(lean) 방식의 업무 스타일1. 사용자의 문제 상황을 인식함.2. 문제 상황에 따라 어떤 솔루션을 제공하면 좋은 반응을 얻을 것이라고 가설을 세움.3. 가설이 맞다면 결과가 어떤 지표로 반영될 것이라고 가정함.4. 가설을 검증할 수 있는 가장 빠른 방법을 생각하고 이를 실험함.5. 사용자와 지속적으로 소통하면서 가설의 방향성을 지속적으로 조정, 확장함.린 방식의 업무 스타일에서는 사용자가 겪는 문제와 사용자의 문제를 해결할 수 있는 해결책을 만들어야 함을 강조함.오늘날 대부분의 사업은 고객의 문제에서 출발함. 여기서 사용자들이 겪는 문제 영역이 바로 도메인임.10.2 애플리케이션의 본..

목차 모듈과 패키지의 개념에 대해서 이전에는 예시처럼 무언가 부족한 답변을 가지고 있었습니다. 모듈이 단순히 독립된 코드의 집합이라고만 생각했고, 자바의 패키지 시스템을 모듈 시스템과 동일시하는 오류를 범하기도 했습니다. 이러한 기초 개념에 대한 이해 없이 프로그래밍을 해왔다는 것을 깨닫고, 학습의 필요성을 다시 한번 느꼈습니다.9. 모듈시작하기 전 질문은 아래와 같음.Q. 모듈이나 모듈 시스템이란 무엇일까?A1. 모듈은 독립된 코드 묶음임. (△)A2. 자바에서 모듈 시스템은 패키지임. (X)A3. 자바 9에서 모듈 시스템은 module-info.java임. (△) 이번 장을 학습하면 아래 질문에 답변할 수 있음.Q. 소프트웨어에서 말하는 모듈이나 모듈 시스템이란 무엇일까?Q. 자바의 패키지는 왜 모듈..

목차 이전 장에서 배웠던 레이어드 아키텍처에 대해 다루려고 합니다. 레이어드 아키텍처를 설계할 때 자주 발생하는 실수 중 하나는 개발 시작점을 잘못 설정하는 것입니다. 많은 개발자들이 데이터베이스 설계나 API 엔드포인트 정의부터 시작하는 경향이 있는데, 진정한 의미에서 레이어드 아키텍처를 구현하기 위해서는 도메인 중심의 설계를 기반으로 기술적 구현을 고려해야 합니다.8. 레이어드 아키텍처8.1 레이어드 아키텍처의 최소 조건레이어드 아키텍처는 애플리케이션을 레이어로 나누고 각 레이어에 역할을 정함. 대표적인 레이어는 프레젠테이션, 비즈니스, 인프라스트럭처가 있음.컴포넌트에 맞춰 레이어를 분류하는 것은 폴더를 관리하는 것과 다를 바 없음.아키텍처는 정책과 제약 조건을 이용해 목적을 달성함.레이어드 구조를 ..

목차 이 책의 2부에서는 저처럼 스프링에 대해서 배운지 얼마 안 된 개발자들이 놓치는 부분을 알려줍니다. 책을 공부하면서, '내가 지금까지 트랜잭션 스크립트 같은 안티패턴을 사용하고 있었구나'하고 반성하게 되는 것 같습니다. 각종 컴포넌트와 DTO 구현에 대한 것도 많이 배워가는 것 같습니다.6. 안티패턴6.1 스마트 UI스마트 UI(User Interface) 패턴: 시스템의 UI 레벨에서 너무 많은 업무를 처리하고 있는 경우스마트 UI는 데이터 입출력을 UI 레벨에서 처리함.스마트 UI는 비즈니스 로직도 UI 레벨에서 처리함.스마트 UI는 데이터베이스와 통신하는 코드도 UI 레벨에서 처리함.→ 백엔드 개발자도 백엔드 개발자의 UI(백엔드 API)를 신경써야 함.컨트롤러(Controller)는 API를..