노바의 개발도서관

15장. Junit 들여다보기 Junit 프레임워크 Junit은 저자가 많다. 하지만 시작은 켄트 벡과 에릭 감마 두사람이 비행기를 타고 가다 3시간 동안 Junit 기초를 구현했다. 우리가 살펴볼 모듈은 문자열 비교 오류를 파악할 때 유용한 코드다. ComparisonCompactor라는 모듈로, 영리하게 짜인 코드다. ComparisonCompactor는 두 문자열을 받아 차이를 반환한다. 예를 들어, ABCDE와 ABXDE를 받아 를 반환한다. ComparisonCompactorTest.java package junit.tests.framework; import junit.framework.ComparisonCompactor; import junit.framework.TestCase; public ..

14장. 점진적인 개선 Intro 확장성이 부족했던 모듈을 소개하고, 모듈을 개선하고 정리하는 단계를 살펴볼 것. 14-1 간단한 Args 사용법 public static void main(String[] args) { try { Args arg = new Args("l, p$, d*", args); boolean logging = arg.getBoolean('l'); int port = arg.getInt('p'); String directory = arg.getString('d'); ececuteApplication(logging, port, directory); } catch (ArgsException e) { System.out.println("Argum..

13장. 동시성 동시성과 깔끔한 코드는 양립하게 어렵다. 스레드를 하나만 실행하는 코드는 짜기가 쉽다. 겉으로 보기에는 멀쩡하나 깊숙한 곳에 문제가 있는 다중 스레드 코드도 짜기 쉽다. 이런 코드는 시스템이 부하를 받기 전까지 멀쩡하게 돌아간다. 이 장에서 다룰 내용 여러 스레드를 동시에 돌리는 이유 여러 스레드를 동시에 돌리는 어려움 동시성을 테스트하는 방법과 문제점 동시성이 필요한 이유? 동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇(what)과 언제(when)을 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 그래서 호출 스택을 살펴보면 프로그램 상태가 곧바로 드러난다. 흔히 단일 스레드 프로그램을 디버깅하는 프로그래머는 정지점(breakpoint)을 정..

12장. 창발성 창발적 설계로 깔끔한 코드를 구현하자 켄트 백이 제시한 단순한 설계 규칙 네 가지 모든 테스트를 실행한다 중복을 없앤다. 프로그래머 의도를 표현하라 클래스와 메서드 수를 최소로 줄여라 단순한 설계 규칙 1: 모든 테스트를 실행하라 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템, 즉 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 높아진다. 크기가 작고 목적 하나만 수행하는 클래스가 나온다. SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다. 테스트 케이스가 많을 수록 개발자는 테스트가 쉽게 코드를 작성한다. 결합도가 높으면 테스트 케이스를 작성하기 어렵다. 그러므로 DIP와 같은 원칙을 적용하려 애써서 DI, 인..

11장. 시스템 도시를 세운다면? 도시를 구상한다면? 도시에는 수도 관리팀, 전력 관리팀, 교통 관리 팀, 치안 관리팀, 건축물 관리팀과 같이 각 분야를 관리하는 팀이 있듯, 큰 그림을 그리는 사람도 있으며, 작은 사항에 집중하는 사람들도 있다. 이를 통해 도시가 잘 돌아갈 수 있다. 도시는 적절한 추상화와 모듈화 덕에 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 '구성요소'는 효율적으로 돌아간다. 소프트웨어 팀도 도시처럼 구상한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서 깨끗함을 유지하는 방법을 알아보자. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의..

10장. 클래스 1. 클래스 체계 클래스를 정의하는 표준 자바 관례 (순서) 변수 목록 정적 공개 상수 (public static final) 정적 비공개 (private static final) 비공개 인스턴스 변수 공개 변수 (공개 변수가 필요한 경우는 거의 없다) 공개 함수 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. (추상화 단계가 순차적으로 내려간다.) 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙은 없다. 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야 한다면 그 함수나 변수를 protected로 선언하거나 패키지 전체로 ..

8장. 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 오픈소스를 이용하거나, 사내 다른 팀이 제공하는 컴포넌트를 이용하거나, 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다. 외부 코드 사용하기 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까. 반면 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 차이로 시스템 경계에 문제가 생길 소지가 많다. 예시) java.util.Map Map이 제공하는 기능과 유연성은 확실히 유연하지만 그만큼 위험성도 크다. 예를 들어, Map의 clear() 메서드는 Map의 사용..

9장. 단위 테스트 기존에는 단위 테스트란 자기 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과했다. 클래스와 메서드를 공들여 구현한 후 임시 코드를 급조해 테스트를 수행했는데 대개는 간단한 드라이버 프로그램을 구현해 자신이 짠 프로그램을 수동으로 실행했다. TDD(Test Driven Development) 테스트 주도 개발 (실제 코드를 짜기 전에 단위 테스트부터 짜라) 애자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 늘어나는 추세이다. 그러나 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 중요한 사실을 놓쳐버렸다. TDD 법칙 세 가지 1. 첫 번째 법칙 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. ..

7장. 오류 처리 오류 코드와 깨끗한 코드 오류 처리는 중요하다. 하지만 오류 처리 코드로 이해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 이 장에서는 고상하게 오류를 처리하는 기법과 고려사항 몇 가지를 소개한다. 1. 오류 코드보다 예외를 사용하라 이전에는 예외를 지원하지 않는 프로그래밍 언어가 많았다. 따라서 오류 플래스를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였다. DeviceController.java (오류코드 사용) public class DeviceController { ... public void sendShutdown(){ DeviceHandle handle = getHandle(DEV1); // 디바이스 상태를 점검한다. if (handle !=..

객체와 자료구조 자료 추상화 구현을 감추려면 추상화가 필요하다. 그저 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. 인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. 자료/객체 비대칭 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료구조는 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다. (자료 구조를 사용하는) 절차..