클래스 체계 변수목록 static public static private 비공개 인스턴스 변수 함수 공개 비공개 (자신을 호출하는 공개 함수 직후에 배치) 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 것이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 종종 변수와 유틸리티 코드를 protected로 선언(비공개로 함수를 만들어 TC를 짤 수 있다면 best)해 테스트 코드에 접근을 허용하기도 한다. 클래스는 작아야 한다 물리적 크기도 중요하지만 클래스가 갖는 ‘책임’의 수가 작아야 한다. 클래스 이름: 클래스의 책임을 기술 (Processor나 Manager가 붙은 이름은 클래스 하나가 여러 책임을 떠안은 것) 단일 책임 원칙 (SRP, Single Responsibility Principle) 클래..
TDD (Test Driven Development) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. → 개발 - 테스트 30초 주기로 진행하면 TC와 실제 코드가 함께 나온다! → TC의 증가는 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기 지저분한 TC는 변경이 어렵다. (실코드를 변경하면 TC도 변경이 필요하게 됨) : TC에 대한 유지보수 비용이 증가한다. 하지만 TC를 포기하게 되면 수정한 코드가 제대로 도는지 확인할 방법이 없기 때문에 코드 변경에 있어 주저하게 되고 코드가 망가질 수 있음. 그러므로 TC는 사고, 설계, 주의..
외부코드와 우리 코드가 융합되는 부분을 깔끔하게 처리하는 법 외부코드 사용하기 외부 코드를 활용하는 경우, 이를 이용하는 클래스나 클래스 계열 밖으로 노출시키지 않고 내부에서 처리 --> 외부 코드를 사용할 수 있도록 내부 코드에서 클래스 같은걸로 묶어서 인터페이스만 열어주면 나중에 외부 코드가 바뀔 때도 여유있게 대응 가능 경계 살피고 익히기 학습테스트: 외부 코드를 사용하기 전에 간단한 TC를 작성해보면서 외부 코드를 익힘 --> 프로그램에서 사용하는 방식으로 외부 API를 호출해보면서 내가 예상한대로 동작하는지를 체크하는 과정 학습테스트는 공짜 이상이다 외부 API에 대해 필요한 지식만 확보하는 손쉬운 방법 --> 새로운 패키지 버전이 나오는 경우, 미리 짜둔 학습테스트를 돌려서 변경사항을 체크할 ..
뭔가 잘못될 가능성은 늘 존재한다. ---> 오류 처리의 중요성이 높아짐 오류보다 예외 사용하기 - 비즈니스 로직과 오류 알고리즘을 분류 - Try - Catch - Finally 문부터 작성하라 - 예외가 발생할 코드를 짜는 경우에 추천. - try 블록에서 무슨 일이 생기든 호출자가 기대하는 상태 정의가 쉬워진다 - TDD 할 때 강제로 예외를 일으키는 테스트 케이스 작성 후 테스트를 통과하게 코드를 작성하는 방향 권장 - try 블록의 트랜잭션 범위부터 구현 ---> 트랜잭션의 본질을 이해하기 쉬워진다. 미확인(unchecked) 예외 사용 예외에 의미를 제공 - 오류가 난 원인을 찾기 쉽도록 정보를 담아 던질 것 호출자를 고려해 예외 클래스를 정의 정상 흐름을 정의하라 null을 반환하지 마라 -..
