클린 코드 #10 클래스코드 레벨, 함수 레벨까지 제대로 작성하는 것도 중요하지만, 더 차원 높은 단계까지 신경써야 한다.이 챕터에서는 깨끗한 클래스에 대해 다룬다.클래스 체계표준 자바 컨벤션에 따르면변수 목록이 가장 먼저 나온다.그 중 상수( = 정적 공개 상수)가 맨 처음에 나온다.그 다음으로 정적 비공개 변수가 나온다.그 다음에 비공개 인스턴스 변수가 나온다.공개 변수가 필요한 경우는 거의 없다.변수 목록 다음에는 공개 함수가 나온다.비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 추상화 단계가 순차적으로 내려가기 위함이다.캡슐화변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 할 필요는 없다. protected로 만들고 테스트 코드에서 접근을 허용하기도 한다.같은 패..

클린 코드 #9 단위 테스트과거에 비하면 테스트 분야가 엄청난 성장을 이뤘고, 단위 테스트를 자동화하는 프로그래머가 많아지고 있다.하지만, 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 미묘하면서 중요한 사실을 놓치고 있다.TDD 법칙 세 가지TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다. 하지만 이 규칙 외에도 많은 규칙들이 있다.실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.컴파일은 실패하지 않으면서 실행 시 실패하는 정도로만 단위 테스트를 작성한다.현재 실패하는 테스트를 통과할 정도로만 테스트를 작성한다.이렇게 일하면, 매일 수 십개의 테스트 케이스가 나온다. (1달이면 수 백개…) 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문..

클린 코드 #8 경계SW 개발을 할 때 모든 SW를 직접 개발하지 않는다. Reuse도 많이한다. 오픈소스를 사용하거나, 패키지를 사거나, 사내 팀이 제공하는 컴포넌트를 쓰거나….이러한 외부 코드를 우리 코드에 깔끔하게 통합하는 것이 중요하다. 이 경계를 깔끔하게 처리하는 기법을 살펴보자.외부 코드 사용하기인터페이스 제공자와 사용자는 원하는 바가 다르다.인터페이스 제공자(ex. 패키지 제공자, 프레임워크 제공자)적용성을 최대한 넓히려고 한다. (더 많은 고객 구매를 위해)인터페이스 사용자자신의 요구에 집중하는 인터페이스를 바란다.이렇기에 시스템 경계에서 문제가 생길 소지가 많아진다.ex) 대표적인 예시: java.util.MapMap은 다양한 인터페이스로 다양한 기능을 제공한다. 하지만 그만큼 위험도 크..

클린코드 #7 오류 처리왜 클린 코드 책에 오류 처리가 나왔을까? 깨끗한 코드와 오류 처리는 확실한 연관성이 있기 때문이다. 실제로, 많은 코드들이 전적으로 오류 처리 코드에 좌우된다. 오류 코드가 막 흩어져있어, 실제 코드의 로직을 파악하는게 불가능하다.오류 처리는 프로그램에서 반드시 필요한 요소 중 하나이다. 입력이 이상하거나 디바이스가 실패할 지도 모르기 때문이다. 다만, 오류 처리로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.오류 코드보다 예외를 사용하라과거에는 예외 처리를 지원하지 않는 프로그래밍 언어가 많았다. 예외를 지원하지 않으면 오류 처리 및 보고 방법이 제한적이다.if (handle != DeviceHandle.INVALID) { retrieveDeviceR..

#6 객체와 자료구조 변수를 private로 정의하는 이유는, 남들이 변수에 의존하지 않도록 하게 만들고, 변수 타입과 구현을 맘대로 바꾸기 위해서다.그런데, 왜 Getter와 Setter를 남발해서 private 변수를 외부에 노출하는 것일까?자료 추상화변수를 private으로 선언하더라도 값마다 Getter, Setter를 제공하면 사실상 구현을 외부로 노출하는 것과 같다.변수 사이에 함수라는 계층을 넣는다고, 구현이 저절로 감춰지는게 아니다. 구현을 감추려면 추상화가 필요하다.추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 클래스이다.자료를 세세하게 공개하기보다는, 추상적인 개념으로 표현하는 편이 좋다.인터페이스만으로, 또는 Getter/Setter만으로 추..

클린코드 #5 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.이를 위해 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀에 속했다면 팀의 규칙을 따라야 한다.(요즘은 코드 스타일을 xml 등의 문서로 작성해 IDE에 등록해주면 코드 스타일을 자동으로 적용해준다)형식을 맞추는 목적코드 형식은 너무 중요하다. 코드 형식은 의사소통의 일환이다. 너무 중요하니, 코드 형식을 맹목적으로 따르면 안 된다.오늘 구현한 기능은 언젠간 바뀔꺼고, 오늘 구현한 코드는 앞으로 바뀔 코드 품질에 큰 영향을 미친다.맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.그러면 대체 원활한 소통을 장려하는 코드 형식은 무어일까?적절한 행 길이를 유지하라.소스 코드의..

가짜로 진짜를 테스트하기: Mock어드민 페이지에 '오늘 자 매출 통계 메일 전송' 기능을 추가한다고 해보자. 이 기능을 테스트하려면 OrderStatisticsService를 실행해야 한다.// OrderStatisticsService.javapublic boolean sendOrderStatisticsMail(LocalDate orderDate, String email) { // 1. 해당 일자의 결제완료된 주문들을 가져온다. // 2. 총매출 합계를 계산한다. // 3. 메일을 전송한다. boolean result = mailService.sendMail(..., email, ..., ...); if (!result) { throw new IllegalArgu..

지금까지 Repository와 Service 계층을 통합 테스트하며 아래에서 위로 올라왔다. 드디어 외부 세계의 요청을 가장 먼저 마주하는 Presentation Layer(Controller) 에 도착했다.Controller를 테스트할 때는 이전과 다른 전략을 사용한다. 하위 계층(Service)은 이미 충분히 테스트했고 잘 동작한다고 가정하고, Controller의 책임에만 집중하는 것이다. 이를 위해 Mocking을 사용한다.Controller 테스트와 MockingMock은 말 그대로 '가짜' 객체다. Controller가 의존하는 Service를 가짜 객체로 대체하면, 우리는 Service의 실제 로직과 상관없이 Controller의 동작(요청 매핑, 파라미터 검증 등)만을 순수하게 테스트할 수..

지난 글에서는 Persistence Layer를 테스트하며 기반을 다졌다. 이제 애플리케이션의 핵심, 비즈니스 로직을 구현하는 Business Layer(Service) 를 테스트해볼 차례다.Business Layer (Service) 테스트Service 계층은 Persistence Layer와 상호작용하며 비즈니스 로직을 전개하고, 트랜잭션을 보장해야 하는 아주 중요한 역할이다. 여기서는 하위 Repository 계층까지 아우르는 통합 테스트를 진행하며 TDD 방식으로 개발해보자.요구사항: 상품 번호 리스트를 받아 주문을 생성한다.TDD 사이클에 따라, 실패하는 테스트부터 작성한다.// OrderServiceTest.java@SpringBootTest@ActiveProfiles("test")class ..

통합 테스트의 필요성지금까지 단위 테스트, TDD, 테스트를 문서로 활용하는 법까지 알아봤다. 그런데 실제 애플리케이션은 수많은 객체(모듈)들이 서로 협력하며 동작한다. A 모듈과 B 모듈이 만났을 때, 우리가 예상한 대로 잘 동작할까?이걸 확인하려면 통합 테스트가 필요하다. 단위 테스트만으로는 전체 기능의 신뢰성을 보장하기 어렵기 때문에, 우리는 풍부한 단위 테스트와 함께 큰 기능 단위를 검증하는 통합 테스트를 병행해야 한다.이번 시리즈에서는 스프링 부트의 계층형 아키텍처(Layered Architecture)에서 각 계층을 어떻게 테스트하는지 알아보자. 그 첫 번째 주자는 데이터를 책임지는 Persistence Layer다.Repository (Persistence Layer) 테스트Persisten..