도메인에 특화된 테스트 언어 가독성을 위해 테스트 코드에서만 사용하는 특수 API를 사용하는 것도 좋다. 이중 표준 실제 환경과 테스트 환경은 요구사항이 다르다. => 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있음(메모리나 CPU 효율과 관련 있는 경우 등) 테스트 당 assert 하나 함수마다 assert 문을 단 하나만 사용해야 한다고 주장하는 의견들이 있음 assert문이 하나인 함수는 결론이 하나라 코드를 이해하기 쉽고 빠르지만, 꼭 지켜야만 하는 법칙은 아니다. => 테스트 코드를 짜다 보면 assert를 여럿 두는 편이 가장 간결하고 이해하기 쉬울 때가 있음. 다만 assert문 개수는 최대한 줄이는 편이 좋다. 테스트 당 개념 하나 테스트 함수마다 한 개념을 ..

깨끗한 경계 경계를 잘 처리하면 소프트웨어 변경에 많은 투자와 재작업이 필요하지 않다. 경계에 위치하는 코드는 깔끔히 분리하고, 테스트 케이스를 작성하여 통제할 수 있게 한다. 단위 테스트 TDD 법칙 세 가지 TDD : 실제 코드를 짜기 전에 단위 테스트부터 짜는 것 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스트가 30초 주기로 묶여, 테스트 코드와 실제 코드가 함께 나온다. 깨끗한 테스트 코드 유지하기 테스트 코드는 유지하기 힘들지만, 테스트 코드가 없으면 시스템 결함율이 높아진다. => 코드 변경을 ..

경계 패키지, 오픈 소스 등의 외부 코드를 우리 코드에 깔끔하게 통합시키기 위한 기교를 알아보자. 외부 코드 사용하기 만약 외부에서 가져온 인터페이스를 우리 코드 여기저기에서 각자의 인스턴스를 만들어 사용한다면, 해당 인터페이스가 변할 경우 수정할 코드가 상당히 많아진다. => 경계 인터페이스를 여기저기 넘기지 않고 이를 캡슐화한 클래스를 만들어 이용하면 이를 예방할 수 있다. 경계 살피고 익히기 외부 패키지를 사용할 땐 테스트 코드를 사용하는 게 바람직하다. 학습 테스트 : 간단한 테스트 케이스를 통해 외부 코드를 익히는 기법 학습 테스트는 패키지가 예상대로 도는지 검증하며, 우리가 패키지를 익히게 해주고, 새 버전이 나올 때마다 우리 코드와 호환되는지를 검사한다. 경계 테스트가 없으면 버전 마이그레이..

Try-Catch-Finally 문부터 작성하라 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. -> 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하고, 이를 기반으로 나머지 논리를 추가하는 방법을 권장한다. (try 블록의 트랜잭션 본질을 유지하기 쉬움) 미확인 예외를 사용하라 자바에는 확인된 예외라는 게 있는데, 이는 OCP를 위반하므로 일반적인 애플리케이션에서는 쓰지 않는 게 좋다. 예외에 의미를 제공하라 예외를 던질 때 충분한 정보를 넘겨준다. 호출자를 고려해 예외 클래스를 정의하라 예외에 대응하는 방식이 거의 동일할 경우엔, 래퍼 클래스를 하나 정의해서 중복 코드를 줄일 수 있다. 정상 흐름을 정의하라 예외 처리를 활용..

디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙. => C 클래스의 메서드 f는 다음 객체의 메서드만 호출해야 한다는 법칙 - 클래스 C - f가 생성한 객체 - f 인수로 넘어온 객체 - C 인스턴스 변수에 저장된 객체 예를 들어, final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath() 위 코드는 객체의 메서드를 두 번 중첩해서 호출하므로 디미터 법칙을 어김. 위와 같은 코드는 기차 충돌이라 부르며, 일반적으로 피하는 편이 좋다. 객체라면 내부 구조를 숨겨야 하므로 디미터 법칙이 적용되지만, 자료 구조는 기본적으로 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다. 즉 다음과 같은 코드는 디미터..

들여쓰기 범위로 이뤄진 소스 계층을 표현하기 위해 코드를 들여씀 => 들여쓰기는 가독성을 향상시킨다. 들여쓰기 무시하기 if, while문을 쓰면서 한 행에 범위를 뭉뚱그리는 것은 좋지 않다. 가짜 범위 빈 while문이나 빈 for 문은 피한다. 팀 규칙 팀은 한 가지 규칙에 합의해야 하고, 모든 팀원은 그 규칙을 따라야 한다. => 소프트웨어가 일관적인 스타일을 보일 수 있도록. 객체와 자료 구조 자료 추상화 구현을 감추려면 추상화가 필요함 형식 논리에 치우쳐 getter/setter로 변수를 다룬다고 클래스가 되지는 않음 => 추상 인터페이스를 사용해 구현을 몰라도 자료의 핵심을 조작할 수 있어야 진정한 클래스. 아무 생각 없이 getter/setter를 추가하는 방법은 나쁘다. 자료/객체 비대칭 ..

인스턴스 변수 인스턴스 변수는 클래스 맨 처음에 선언하고, 변수 간에 세로로 거리를 두지 않는다. => 언어마다 인스턴스 변수를 선언하는 위치는 다를 수 있지만, 잘 알려진 위치에 인스턴스 변수를 모은다는 점은 같으며 그 점이 중요하다. 종속 함수 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치하며, 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. => 프로그램이 자연스럽게 읽히기 위함 + 규칙을 일관적으로 적용하면 독자는 방금 호출한 함수가 잠시 후에 정의되리라는 사실을 예측한다. 개념적 유사성 개념적인 친화도가 높을수록 코드를 가까이 배치한다. 친화도가 높은 경우 : 한 함수가 다른 함수를 호출할 때(종속성), 변수와 그 변수를 사용하는 함수, 비슷한 동작을 수행하는 일군..

형식 맞추기 형식을 맞추는 목적 코딩하기 전에 코드 형식을 맞추기 위한 규칙을 정하는 것이 좋다. -> 코드가 바뀌어도 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수에 계속 영향을 미친다. 좋은 코드 형식 적절한 행 길이를 유지하기 큰 파일보다 작은 파일이 이해하기 쉽다. 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있음 신문 기사처럼 작성하기 이름은 간단하면서도 설명 가능하게 짓기 소스 파일 첫 부분은 고차원 개념과 알고리즘, 아래로 내려갈수록 저차원 함수와 세세하게 묘사하는 코드 -> 위에서 아래로 읽을 수 있게 하기(기사에서 첫 문단이 전체 기사 내용을 요약하고, 세세한 사실은 내려갈수록 드러나듯이) 다양한 파일로 구성하기 - 신문은 다양한 기사로 이뤄진다. 개념은 빈 행으로 분..

나쁜 주석 함수나 변수로 표현할 수 있는 주석 : 주석을 통해 코드를 이해시키기보다, 주석이 필요하지 않도록 코드를 개선하는 편이 좋다. 위치를 표시하는 주석 : 배너 역할을 하는 주석. 배너를 남용하면 흔한 잡음으로 여겨지므로, 반드시 필요할 때만 드물게 사용하라. 닫는 괄호에 다는 주석 : 닫는 괄호 뒤에 어떤 블록이었는지 표시하는 주석. } // while, } // try 같은 것들. 중첩이 심하고 장황한 함수라면 도움이 될지도 모르지만 작게 잘 나누어진 함수들에선 잡음이다. 그러므로 닫는 괄호에 주석을 달기보다 함수를 쪼개고 줄여 보자. 공로를 돌리거나 저자를 표시하는 주석 : 소스 코드 관리 시스템에 저장하자. 주석으로 처리한 코드 : 좋지 않은 관행이다. 주석으로 처리한 코드는 다른 사람들이..

좋은 주석 중요성을 강조하는 주석 공개 API에서 Javadocs 나쁜 주석 대다수 주석이 나쁜 주석이다. 주절거리는 주석 : 특별한 이유 없이 의무감으로 마지못해 주석을 다는 경우. 다른 사람들에게 그 의미가 잘 전해지지 않는 주석. 이해가 안 되어 다른 모듈을 뒤져야 하는 주석. 같은 이야기를 중복하는 주석 : 코드 내용을 그대로 중복하는 주석. 코드보다 주석을 읽는 시간이 오래 걸릴 수 있다. 주석은 코드보다 더 많은 정보를 제공해야 한다. 오해할 여지가 있는 주석 : 중의적이거나, 모호하거나… 의무적으로 다는 주석 : 필요가 없는데도 모든 변수에 주석이 달려 있거나 한 경우. 코드를 복잡하게 만들고, 코드 업데이트를 주석이 따라가지 못해 잘못된 정보를 제공할 수 있다. 이력을 기록하는 주석 : 소..