DAY17

  • 오늘 읽은 범위 : 8장 경계~9장 단위테스트 p157

책에서 기억하고 싶은 내용을 써보세요

8장

  • 개발을 하며 모든 소프트웨어를 전부 직접 개발하는 경우는 드물다. 패키지 또는 오픈소스 또한 이용하는데, 이러한 외부코드들을 우리코드에 깔금하게 통합해야만 한다.
  • 인터페이스 제공자와 인터페이스 사용자의 사이에는 각자의 이해관계가 있다. 제공자는 최대한 범용성 있는 인터페이스를 제공하길 원하고 사용자는 사용자의 입맛에 맞는 인터페이스를 제공받길 원한다.
    • Map클래스의 사용 문제1
      • Map클래스를 사용하는 사용자라면 인터페이스가 제공하는 수많은 기능을 사용할 수 있다. 예를 들어보자면 Map 을 여기저기 사용하다 보면 Map의 기능 중 clear()메서드를 누구든지 사용가능하다는 뜻이다. 또한 지네릭스 이후로 Map에는 특정 객체유형만 저장하지 않으며, 마음만 먹으면 어떤 객체 유형도 추가할 수 있게 돼있다.
      • 경계 인터페이스인 Map을 해당 객체 안에 숨김으로써 해당 객체에서 어떤 클래스를 지네릭스로 사용할지 숨김과 동시에 지네릭스의 사용 주도권을 우리가 정의한 클래스에서 가져가도록 결정함으로 Map 인터페이스가 변하더라도 나머지 프로그램에 영향을 미치지 않게 할 수 있다.
      • 추가적으로 위처럼 구현한다면 Map인터페이스에서 우리가 필요한 기능만 제공하도록 캡슐화할 수 있다.
  • 학습테스트 - 외부코드를 사용하면 시간대비 더 많은 기능을 출시하기에 유리하다. 하지만 외부코드를 사용하면서 해당 외부코드를 학습함과 동시에 발생가능한 문제를 대비해 해당 코드들을 우리가 테스트하는 편이 바람직하다.
    • 테스트하고 학습하고 캡슐화하라!2
  • 경계테스트를 활용한다면 기존 버전의 패키지에서 새로운 버전의 패키지로의 이전이 쉬워진다!-우리가 필요한 모든 테스트는 이전버전 패키지를 사용할 때 작성했던 테스트를 모두 통과해야하기에-
  • 아직 존재하지 않는 코드에 대한 인터페이스를 먼저 정의해둔다면, 우리가 인터페이스를 전적으로 통제한다는 장점이 생기며, 코드 가독성과 의도도 분명해진다.3
  • 소프트웨어 설계가 우수하다면 경계에서 변경하는데 많은 투자와 재작업이 필요하지 않다.
  • 경계에 위치하는 코드는 깔끔히 분리해야 한다.

9장

  • TDD의 법칙 세가지
    1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
    2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로면 단위 테스트를 작성한다
    3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다
      • 위 세가 규칙을 따른다면 개발과 테스트가 대략 30초 주기로 묶인다.
      • 테스트 코드를 작성함과 동시에 실제 코드가 함께 나온다.
      • 테스트 코드를 위와 같이 작성할 경우 매달 수백 수천개의 테스트 코드가 나오는데 이는 심각한 관리문제를 야기하기도 한다.
  • 테스트코드는 실제코드 못지 않게 중요하다-깨끗한 단위 테스트 코드가 성공의 지름길이다!
  • 테스트는 유연성, 유지보수성, 재사용성을 제공한다
    • 아키텍처가 아무리 유연하더라도, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없다면 개발자는 변경을 주저한다=모든 것이 잠재적 버그

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

  1. 오늘은 두 장을 같이 읽었습니다. 현업에서 많은 외부 인터페이스(모듈, 패키지, 프레임워크)를 사용하며 왜 발생되는지 모르는 수많은 버그들이 그 외부 인터페이스들로 부터 온다는 것을 알았을 때 굉장히 스트레스를 많이 받았으며 그 버그들을 고치는데 많은 시간을 할애하게 되었습니다. 하지만 오늘 장을 마지막으로 외부 인터페이스들은 깔끔하게 내부코드와 단절시키며 클래스 안으로 숨김으로써 변경에 무감각한 코드를 짤 수 있겠다 생각이 들었습니다.
  2. 아직도 많은 개발회사들이 테스트케이스를 사용하지 않는것으로 알고 있습니다. 저 또한 TDD를 사용하는 회사를 아직까지 겪어보지 못했으며, 단순히 이런것이 있다 라는 것만 알고 지나갔는데, 9장을 읽어본 후, 제가 항상 느꼈던 코드에 대한, 그리고 변경에 대한 불안감의 해답은 TDD에 있다는 것을 알게되었습니다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

세줄 요약

8장

  • 경계인터페이스의 사용은 클래스내부로 숨기고 우리가 원하는 기능만 사용하도록 제한해라
  • 테스트하고 학습하고 캡슐화하라!
  • 경계는 우리가 통제하기 어렵다! 설계하고 분리하고 사용빈도를 줄여서 변경비용이 지나치게 커지지 않도록 주의하자

9장

  • 테스트 코드는 실제 코드만큼이나 중요하다.
  • 테스트 케이스가 없다면 모든 코드는 잠재적 버그유발자!
  • 테스트 코드를 통하여 설계와 코드의 변경을 유연하게 유지할 수 있게 된다!

주석

  1. p144의 외부코드 사용하기 하위 예제 참조 ↩

  2. 학습방법은 p147의 log4j 익히기 참조 ↩

  3. p150 아직 존재하지 않는 코드를 사용하기 참조 ↩