희연's 개발 일기장

abstract public class VacationPolicy { 
    public void accrueVacation() {
        calculateBaseVacationHours() ; 
        alterForLegalMinijnums() ; 
        applyToPayroll();
    }
    
    private void calculateBaseVacationHours() .{*/./.}; 
    abstract protected void alterForLega!Minimums(); 
    private void applyToPayrolK) .{*/./.};
 }
    
public class USVacationPolicy extends VacationPolicy { 
    @Override protected void alterForLegalMinimums() {
    // 미국 최소 법정 일수를 사용한다. 
    }
}   
  
public class EUVacationPolicy extends VacationPolicy { 
    @Override protected void alterForLegalMinimums() {
    // 유럽연합 최소 법정 일수를 사용한다. }
    }
}

1. 프로그래머 의도를 표현한다.
   • 좋은 이름 선택
   • 함수와 클래스 크기 줄이기
   • 표준 명칭 사용
   • 단위 테스트 작성
2. 클래스와 메소드 수를 최소로 줄인다.

public class X {
    private int lastldllsed;
    
    public int getNextId() { 
        return ++lastldllsed;
    } 
}

• astldUsed 필드를 42으로 설정하고, 두 스레드가 같은 변수를 동시 참조하면
• 한 스레드는 43를 받고, 다른 스레드도 43을 받는다. lastIdUsed는 43이 된다.

동시성 방어 원칙

• 단일 책임 원칙(Single Responsibility Principle)
  • 주어진 메소드, 클래스, 컴포넌트를 변경할 이유가 하나여야 한다.
  • 동시성 관련 코드는 다른 코드와 분리한다.
• 따름 정리(corollary) : 자료 범위를 제한하라
  • 공유 객체를 사용하는 코드 내 임계영역(critical section)을 synchronized 키워드로 보호한다.
  • 자료를 캡슐화하고, 공유 자료를 최대한 줄여라
• 따름 정리 : 자료 사본을 사용하라
  • 공유 자료를 줄이려면 처음부터 공유하지 않는 방법이 제일 좋다.
  • 하지만 사본으로 동기화를 피하게 되면, 사본 생성과 가비지 컬렉션이 성능 부하를 상쇄할 수 있다.
• 따름 정리 : 스레드는 가능한 독립적으로 구현하라
  • 다른 스레드와 자료를 공유하지 않는다.
  • 각 스레드는 클라이언트 요청 하나를 처리한다.
  • 모든 정보는 비공유 출처에서 가져오며 로컬 변수에 저장한다.

라이브러리를 이해해라 - 스레드 환경에 안전한 컬렉션

• java.util.concurrent 패키지가 제공하는 클래스
• 다중 스레드 환경에서 사용해도 안전하고, 성능이 좋다.
• ConcurrentHashMap은 거의 모든 상황에서 HashMap보다 빠르다.

실행 모델을 이해해라

• 기본 용어

실행 모델 종류

• 생산자/소비자(Producer-Consumer)
  • 하나 이상 생산자 스레드가 정보를 생성해 버퍼(buffer)나 대기열(queue)에 넣는다.
  • 대기열은 한정된 자원
  • 생산자 스레드는 대기열에 빈 공간이 있어야 정보를 채우고, 소비자 스레드는 대기열에 정보가 있어야 가져온다.
  • 생산자 스레드와 소비자 스레드는 서로 대기열 정보에 관련한 시그널을 보낸다.
• 읽기/쓰기(Readers-Writers)
  • 읽기 스레드를 위해 공유 자원을 사용하게 되면, 쓰기 스레드가 이 공유 자원을 갱신할 때 처리율(throughput) 문제가 생길 수 있다.
  • 처리율을 강조하면 기아(starvation) 현상이 생기거나 오래된 정보가 쌓인다.
  • 쓰기 스레드가 버퍼를 오랫동안 점유하게 되면 읽기 스레드는 버퍼를 기다리느라 처리율이 떨어진다.
• 식사하는 철학자들(Dining Philosophers)

동기화하는 메소드 사이에 존재하는 의존성을 이해해라

• 공유 객체 하나에는 메소드 하나만 사용하기
• 공유 객체 하나에 여러 메소드가 필요한 경우
  • 클라이언트에서 잠금 : 클라이언트에서 첫 번째 메소드를 호출하기 전에 서버를 잠근다. 마지막 메소드를 호출할 때까지 잠금 유지
  • 서버에서 잠금 : 서버에서 "서버를 잠그고 모든 메소드를 호출한 후 잠금을 해제하는" 메소드를 구현한다. 클라이언트가 이 메소드를 호출한다.
  • 연결(Adpated) 서버 : 잠금을 수행하는 중간 단계를 생성한다.

동기화하는 부분을 작게 만들어라

• 자바에서 synchronized 키워드를 사용하면 락을 설정한다.
• 락은 스레드를 지연시키고 부하를 가중시키기 때문에 키워드를 남발하지 않는다.
• 임계영역 개수를 최대한 줄이는 것이 좋지만, 필요 이상의 임계영역 크기는 스레드 간의 경쟁이 늘어나고 프로그램 성능이 떨어진다.

올바른 종료 코드는 구현하기 어렵다

• ex. 데드락
  • 부모 스레드가 자식 스레드를 여러 개 만들고, 모두 끝나면 자원을 해제하고 종료하는 시스템
  • 자식 스레드 하나가 데드락에 걸리면 부모 스레드는 계속 기다리게되고, 프로그램은 종료할 수 없다.

스레드 코드 테스트하기

• 테스트가 정확성을 보장하지는 않지만, 위험도를 낮출 수 있다.
• 문제를 노출하는 테스트 케이스를 작성하라
• 구체적인 지침
  • 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라
  • 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
  • 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드르 ㄹ구현하라
  • 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
  • 프로세서 수보다 많은 스레드를 돌려보라
  • 다른 플랫폼에서 돌려보라
  • 코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라
  • 직접 구현하기
  • 자동화

📌 14장 점진적인 개선

점진적으로 개선하다

• 테스트 주도 개발(Test-Driven Development)
  • 언제 어느 때라도 시스템이 돌아가야 한다.
  • 내용이 변경되어도 시스템 변경 전과 똑같이 돌아가야 한다.
• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.
• 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 쉬워진다.

LocalPort port = new LocalPort(12); 
try {
    port.open();
} catch (PortDeviceFailure e) {
    reportError(e);
    logger. log(e.getMessage(), e);
} finally {}

public class LocalPort {
    private ACMEPort innerPort;
    public LocalPort(int portNumber) { innerPort = new ACMEPort(portNumber);
}
    public void open () { 
        try {
            innerPort.open ();
        } catch (DeviceResponseException e) {
            throw new PortDeviceFailure(e);
        } catch (ATM1212UnlockedException e) {
            throw new PortDeviceFailure(e); } 
        catch (GMXError e) {
            throw new PortDeviceFailure(e);
        } 
    }
}

• 다른 라이브러리로 갈아탈 경우 비용이 적어진다.
• 프로그램 테스트가 쉬워진다.

정상 흐름을 정의하라

• 외부 API를 감싸 독자적인 예외를 던지고, 코드 위에 처리기를 정의해 중단된 계산을 처리한다.
• 중단이 적합하지 않은 경우 : ex. 비용 청구 애플리케이션
  • Special Case Pattern 특수 사례 패턴
  • 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식 -> 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.
  • 예외가 논리를 어렵게 만드는 경우, 특수 상황을 처리할 필요가 없으면 더 개선될 것이다.

try {
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID()); 
    m_total += expenses.getTotaK);
} catch(MealExpensesNotFound e) { 
    m_total += getMealPerDiem();
}

// 개선 방법 : ExpenseReportDAO를 언제나 MealExpense 객체를 반환하도록 수정
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID()); m_total += expenses.getTotaK);

public class PerDiemMealExpenses implements MealExpenses { 
    public int getTotal() {
// 기본값으로 일일 기본 식비를 반환한다.
} }

null 을 반환하지 마라

• 메서드로 null 을 전달하는 코드와 반환하는 코드는 피한다.

결론

• 깨끗한 코드는 읽기 좋은 코드 + 높은 안정성
• 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하자

---

📌 8장 경계

외부 코드 사용하기

• Map은 제공하는 기능성과 유연성이 있지만, 다른곳으로 넘길 경우 clear 메소드로 Map 사용라면 누구나 Map 내용을 지울 권한이 있는 위험이 있다.
• Map의 인터페이스가 변하게 되면, 수정할 코드가 많아진다.
• Map을 깔끔하게 사용한 코드. 제네릭스의 사용 여부는 Sensor 안에서 결정한다.

public class Sensors {
    private Map sensors = new HashMap();
    
    public Sensor getById(String id) { 
        return (Sensor) sensors.get(id);
}
// 이하 생략 }

경계 살피고 익히기

• 타사 라이브러리를 사용할 경우
  • 하루나 이틀 이상의 시간동안 문서를 읽고 사용법 결정
  • 코드를 작성 후 라이브러리가 예상대로 동작하는지 확인
• 학습 테스트
  • 코드를 작성해 외부 코드를 호출하는 것보다 먼저 간단한 테스트 케이스 작성 후 외부 코드를 익히는 방법

log4j 익히기

• log4j를 사용해서 패키지를 내려받고, "hello"를 출력하는 테스트 케이스

@Test
public void testLogCreate() {
    Logger logger = Logger.getLoggerC'MyLogger");
    logger, infoC'hello"); // Appender가 필요하다는 오류 발생
}

@Test
public void testLogAddAppender() {
    Logger logger = Logger.getLogger("MyLogger"); 
    logger.removeAllAppenders(); 
    logger.addAppender(new ConsoleAppender(
        new PatternLayout("%p %t %m%n"),
        ConsoleAppender.SYSTEM_OUT)) ;
    logger. infoC'hello");
}

학습 테스트는 공짜 이상이다

• 이해도를 높여주는 정확한 실험이다.
• 패키지 새 버전이 나오면 학습 테스트를 돌려 차이를 확인한다.
• 패키지가 예상대로 도는지 검증한다.

아직 존재하지 않는 코드를 사용하기

• 경계와 관련해 또 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계
• 지식이 별로 없는 상태에서 시스템을 개발하려고 하는 경우, 하위 시스템과 먼 부분부터 작업을 진행

• 송신기 API에서 CommunicationsController 분리
• 다른 팀에서 송신기 API 정의 후에 TransmitterAdapter를 구현해 간극을 매운다.
• ADAPTER 패턴(어댑터 패턴) 으로 API 사용을 켑슐화 해서 API가 바뀔 때 수정할 코드를 한 곳으로 모았다.

깨끗한 경계

• 경계에 위치하는 코드는 깔끔하게 분리한다.
• 기대치를 정의하는 테스트 케이스도 작성한다.
• 외부 패키지에 의존하는 것보다 우리 코드에 의존하는 편이 훨씬 좋다.
• 외부 패키지를 호출하는 코드를 가능한 줄인다.
  • 새로운 클래스로 경계를 감싸거나 어댑터 패턴을 사용해서 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환한다.

---

📌 9장 단위 테스트

TDD 법칙 세 가지

• 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

깨끗한 테스트 코드 유지하기

• 지저분한 테스트 코드가 있는 것보다 테스트가 없는 것이 낫다.
• 테스트는 유연성, 유지보수성, 재사용성을 제공한다.

깨끗한 테스트 코드

• 중복되는 코드, 자질구레한 사항이 너무 많을 경우 표현력 저하
• BUILD-OPERATE_CHECK 패턴
  • BUILD : 테스트 자료를 만든다.
  • OPERATE : 테스트 자료를 조작한다.
  • CHECK : 조작한 결과가 올바른지 확인한다.

도메인에 특화된 테스트 언어

• DSL(도메인 특화 언어) 으로 테스트 코드를 구현하는 기법
• 보통 시스템 조작 API를 사용하지만, 대신에 API 위에 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용한다.
  • 테스트 코드 작성과 읽기가 쉬워진다.
• 이중 표준
  • 실제 환경에서는 안되지만 테스트 환경에서는 문제 없는 방식
  • ex. StringBuffer는 효율적이지만 테스트 환경은 자원이 제한적일 가능성이 낮다.

테스트 당 assert 하나

• given-when-then 이라는 관례를 사용해서, 테스트 코드를 읽기 쉽게 작성
• 테스트를 분리하게 되면 중복 코드가 생기게 된다.
• 방법1 : TEMPLATE METHOD(템플릿 메소드) 패턴을 사용하면 중복 제거 가능
  • given/when 부분을 부모 클래스에 두고, then 부분을 자식 클래스에 둔다.
• 방법2 : 독자적인 테스트 클래스를 만들어서, @Before 함수에 given/when 부분을 넣고 @Test 함수에 then 부분을 넣는 방법

테스트 당 개념 하나

F.I.R.S.T

• 깨끗한 테스트를 위한 다섯가지 규칙
• Fast(빠르게) : 테스트는 빨리 돌아야 한다.
• Independent(독립적으로) : 각 테스트는 서로 의존하면 안된다.
• Repeatable(반복가능한) : 어떤 환경에서도 테스트는 반복이 가능해야 한다.
• Self-Validating(자가검증하는) : 테스트는 bool 값으로 결과를 내야 한다.
• Timely(적시에) : 단위 테스트는 테스트를 하려는 실제 코드를 구현하기 직전에 구현한다.

---

📌 10장 클래스

클래스 체계

• 변수 목록
  • static public 변수
  • static private 변수
  • private instance 변수
  • public 변수가 필요한 경우는 거의 없다.
• 공개 함수
• 비공개 함수 : 자신을 호출하는 공개 함수 직후
• 캡슐화
  • 변수와 유틸리티 함수는 가능한 공개하지 않는다.
  • 테스트 코드에 접근을 허용할 수 있도록 protected 으로 선언하는 경우가 있다.
  • 하지만 비공개 상태를 유지할 방법을 생각한 후, 캡슐화를 풀어주는 것은 마지막 수단으로 한다.

클래스는 작아야 한다!

• 클래스 이름에 해당 클래스 책임을 기술한다.
• 클래스 설명은 if, and, or, but 등을 제외한다. 그리고 25단어 내외로 가능해야 한다.
• SRP 단일 책임 원칙(Single Responsibility Principle)
  • 클래스는 책임이 하나여야 한다.

응집도 Cohesion

• 클래스는 인스턴스 변수의 수가 작아야 한다.
• 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
• 변수를 많이 사용할수록 메소드와 클래스는 응집도가 더 높다.
• 응집도를 유지하면 작은 클래스 여럿이 나온다

변경으로부터 격리

• 구체적인 클래스 : 상세한 코드를 포함
• 추상 클래스 : 개념만 포함
• 인터페이스와 추상 클래스를 사용해서 구현이 미치는 영향을 격리한다.
• 시스템의 결합도를 낮추면 유연성과 재사용성을 높일 수 있다.

// 직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)){}

// 코드로 의도 표현
if (employee.isEligibleForFullBenefits())

좋은 주석

• 법적인 주석 : 저작권 정보, 소유권 정보
• 정보를 제공하는 주석 : ex. 정규 표현식이 시각과 날짜를 뜻하는 것을 명한다.

// kk:mm:ss EEE, IWI dd, yyyy 형식이다. Pattern timeMatcher = Pattern.compile(
:"*\\d W,*\\w,*\\d "*\)\;d

public class ReporterConfig {
/**
* 리포터 리스너의 클래스 이름
*/
private String m_className;
/**
* 리포터 리스너의 속성
*/
private List<Property> m_properties = new ArrayList<Property>(); public void addProperty(Property property) {
m_properties. add (property);
}

// 변경 후
public class ReporterConfig {
  private String m_className;
  private List<Property> m_properties = new ArrayList<Property>();
  public void addProperty(Property property) { m_properties. add(property);
  } }

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

// 기차 충돌 개선
Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
final String outputDir = scratchDir.getAbsolutePath();

final String outputDir = ctxt.options.scratchDir.absolutePath;

public List<int[]> getThem() {
List<int[]> listl = new ArrayList<int[]>();
 for (int[] x : theList) if (x[0] = 4)
listl.add(x); return listl;
}

• 이름 변경후

public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>(); for (Cell cell : gameBoard)
if (cell.isFlagged()) flaggedCells.add(cell);
return flaggedCells; }

public static void copyChars(char al[], char a2[]) { for (int i = 0; i < al.length; i++) {
a2[i] = al[i]; }
}