taetae98

아래 목록은 다양한 프로그램을 검토하고 리팩터링하면서 만들었다. 프로그램을 수정할 때마다 나는 "왜?"라고 자문한 다음 그 답을 기록했다. 코드를 읽으면서 나쁜 냄새를 정리하다 보니 목록이 상당히 길어졌다. 주석 부적절한 정보 다른 시스템에(소스 코드 관리 시스템, 버그 추적 시스템, 기록 관리 시스템) 저장할 정보를 주석으로 저장하는 것은 적절하지 못하다. 예를 들어 작성자, 변경 이력 같은 정보는 코드만 번잡하게 만든다. 쓸모 없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 쓸모가 없다. 쓸모 없는 주석은 아예 달지 않는 편이 가장 좋다. 쓸모 없어진 주석은 가능한 빨리 삭제하는 것이 좋다. 쓸모 없는 주석은 코드와 무관하게 혼자서 따로 놀며 코드를 그릇된 방향으로 이끈다. 중복된 주석..

첫째, 돌려보자 SerialDate 코드에서 데이비드는 엄청난 절제력과 전문가 정신을 보여준다. 의도와 목적을 고려하건대, SerialDate는 분명히 '우수한' 코드다. 그럼에도 여기서는 낱낱이 까발긴다. SerialDateTests라는 클래스는 단위 테스트 몇 개를 포함한다. 실패하는 테스트 케이스는 없지만, 테스트 케이스를 훑어보면 모든 경우를 점검하지 않는다는 사실이 드러난다. 그래서 나는 클로버를 이용해 테스트 코드를 조사했다. 클로버에 따르면 커버리지는 50% 정도였다. 클래스를 철저히 이해하고 리펙터링하려면 높은 커버리지가 필요했다. 그래서 나는 독자적으로 단위 테스트를 구현했다. SerialDate를 리팩터링하면서 나는 모든 테스트 케이스를 통과하게 코드를 손 볼 작정이다. 둘째, 고쳐보자..

JUnit JUnit의 저자는 많다. 하지만 시작은 켄트 벡과 에릭 감마 두 사람이다. 코드는 잘 분리되었고, 표현력이 적절하다. 저자들이 모듈을 아주 좋은 상태로 남겨두었지만 보이스카우트 규칙에 따라 개선해보자. 기존 코드 더보기 package junit.framework; public class ComparisonCompactor { private static final String ELLIPSIS = "..."; private static final String DELTA_END = "]"; private static final String DELTA_START = "["; private int fContextLength; private String fExpected; private String f..

Args Args 클래스를 통해 시작은 좋았으나 확정성이 부족했던 모듈을 소개하고, 개선하여 정리하는 단계를 살펴본다. Args의 사용법은 생성자에 인수 문자열과 형식 문자열을 넘기고, Args에 값을 질의하여 인수를 얻는다. package com.objectmentor.utilities.args; import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; import java.util.*; public class Args { private Map marshalers; private Set argsFound; private ListIterator currentArgument; public Args(String schema, Strin..

동시성이 필요한 이유? 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 무엇과 언제를 분리하면 애플리케이션 구조와 효율은 극적으로 나아진다. 단일 스레드 프로그램에서 Break Point를 걸어놓으면 무엇을 언제 실행하는지 알 수 있다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 구조적인 관점에서 프로그램은 거대한 루프 하나가 아니라 작은 협력 프로그램 여럿으로 보인다. 시스템을 이해하기가 쉽고 문제를 분리하기도 쉽다. 응답시간과 작업 처리량 개선 미신과 오해 반드시 동시성이 필요한 상황이 존재한다. 하지만, 동시성은 어렵다. 다음은 동시성과 관련된 일반적인 미신과 오해다. - 동시성은 항상 헝능을 높여준다? 대기 시간이 아주 길어 스레드가 프로세서를 공유할 수 있..

창발적 설계로 깔끔한 코드를 구현하자 우리들 대다수는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위 목록은 중요도 순이다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 문서로는 시스템을 완벽하게 설계했지만, 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면, 문서 작성을 위해 투자한 노력에 대한 가치는 인정받기 힘들다. 놀랍게도 "테스트 케이스를 만들고 계속 돌려라"라는 간단하고 단순한 규칙을 따르면 낮은 결합도, 높은 응집력, 객체 지향 방법론이 지향하는 목표를 저절히 달성하게 된다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진..

도시를 세운다면? 도시가 잘 돌아가는 이유. 수도 관리 팀, 전려 관리 팀, 교통 관리 팀 등 각 분야를 관리하는 팀이 있기 때문이다. 도시가 돌아가는 이유는 적절한 추상화와 모듈화 때문이다. 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 구성요소는 효율적으로 돌아간다. 소프트웨어 팀도 도시처럼 구성한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. 시스템 제작과 시스템 사용을 분리하라 우선 제작은 사용과 아주 다르다는 사실을 명심하라. 소프트웨어 시스템은 준비 과정(애플리케이션 객체를 제작하고 의존성을 서로 연결하는) 런타임 로직(준비 과정 이후에 이어지는)을 분리해야 한다. 시..

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 깨끗한 클래스가 필요하다. 클래스 체계 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다. 정적 공개 상수 정적 비공개 변수 비공개 인스턴스 변수 공개 변수가 필요한 경우는 거의 없다. 변수 다음에는 공개 함수가 나오고, 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근 을 허용한..