클래스 체계 변수 목록이 가장 먼저 나온다. → 정적 공개 상수가 있다면 맨 처음에 나온다. 비공개 인스턴스 변수가 나온다. 공개 함수가 나온다. 클래스는 작아야 한다 하나의 클래스가 많은 책임을 가지면 안 된다. (SOLID 법칙 중 SRP 위반) 클래스 이름은 해당 클래스 책임을 기술해야 한다. 큰 클래스 몇 개가 아니라 작은 클래스 녀럿으로 이루어진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유 역시 하나다. 변경하기 쉬운 클래스 대다수의 시스템은 지속적인 변경이 가해진다. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. (OCP 원칙) 결합도와 응집도 시스템의 결합도를 낮추면 유연성과 재사용성이 더욱 높아진다. 결합도가 ..
TDD로 구현해 본 경험이 없지만 정리하면서 이해하고자 했다. TDD 법칙 세 가지 실제 코드를 짜기 전 단위 테스트부터 짜라고 요구한다. 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 이 법칙을 지키면 사실상 실제 코드를 전부 테스트하는 테스트 케이스가 나온다. 깨끗한 테스트 코드 유지하기 실제 코드가 진화하면 테스트 코드도 변해야 한다. 하지만 테스트 코드가 지저분할수록 변경하기 어려워진다. 악순환 지저분한 테스트 코드로 인해 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다. 그래서 테스트 코..
외부 코드 사용하기 외부 코드를 내 코드에서 호출하는 부분을 경계라고 한다. (아는 코드와 모르는 코드를 분리하는 것도 경계라고 한다.) 예를 들어 Map 인터페이스가 변할 경우 수정할 코드가 상당히 많아진다. Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다. Map 인스턴스를 공개 APi의 인수로 넘기거나 반환값으로 사용하지 않는다. 학습 테스트는 공짜 이상이다. 학습 테스트란 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것을 말한다. 학습 테스트는 비용이 들지 않으며, 필요한 지식만 확보할 수 있다. 깨끗한 경계 경계에 위치하는 코드는 깔끔히 분리한다. 기대치를 정의하는 테스트 케이스도 작성한다. 통제 불가능한 외부 패키지보다..
오류 코드보다 예외를 사용하라 오류 코드를 사용하면 호출자 코드가 복잡해진다. 반면 예외를 던지게 되면 논리와 오류 처리 코드가 뒤섞이지 않아 깔끔해진다. Try-Catch-Finally 문부터 작성하라 try 블록은 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. 미확인 예외를 사용하라 확인된 예외는 OCP를 위반한다. → 대규모 시스템의 경우 최하위 단계에서 최상위 단계까지 연쇄적인 수정 발생 확인된 예외는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다. 확인된 예외와 미확인된 예외의 차이는 아래 글에서 확인할 수 있다. ht..
자료 추상화 구현을 감추려면 추상화가 필요하다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 한다. public interface Vehicle { double getFuelTankCapacityInGallons(); double getGallonsOfGasoline(); } 위 인터페이스는 자동차 연료 상태를 구체적인 숫자 값으로 알려준다. 두 함수가 변숫값을 읽어 반환할 뿐이라는 사실이 거의 확실하다. public interface Vehicle { double getPercentFuelRemaining(); } 반면에 위 인터페이스는 자동차 연료 상태를 백분율이라는 추상적인 개념으로 알려준다. 정보가 어디서 오는지 전혀 드러나지 않는다. 자료를 세세하게 공개하기..
형식을 맞추는 목적 지금 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 지금 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 적절한 행 길이를 유지하라 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. 여러 프로젝트를 조사해 보면 평균 파일 크기는 약 65줄이다. 신문 기사처럼 작성하라 첫 문단은 전체 기사 내용을 요약한다. 쭉 읽으며 내려가면 세세한 사실이 조금씩 드러난다. 소스 파일 이름은 간단하면서도 설명이 가능하게 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 마지막에..
나쁜 코드에는 주석을 달지 마라. 새로 짜라 - 브라이언 W. 커니핸, P.J. 플라우거 주석이 안 좋은 이유 주석은 오래될수록 코드에서 멀어진다. 주석을 유지하고 보수하기란 현실적으로 불가능하다. 처음부터 주석이 없는 방향으로 코드를 구현하는 것이 좋다. 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 그러므로 우리는 주석을 가능한 줄이도록 노력해야 한다. 주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 이유는 코드의 품질이 나쁘기 때문이다. 난장판으로 어질러 놓은 코드를 주석으로 설명할 시간에 난장판을 깨끗이 치우자 코드로 의도를 표현하자 // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if ((employee.flags & HOURLY_FLAG) && (employee.ag..
어떤 프로그램이든 가장 기본적인 단위는 함수이다. 때문에 함수를 잘 만드는 것은 매우 중요하다! 작게 만들어라 일반적으로 5줄보다 짧아야 한다. 하지만 5줄로 함수를 구현하는 것은 쉽지 않기 때문에 연습해야 한다. 중첩 구조가 생길 만큼 함수가 커져서는 안 된다. 한 가지만 해라 함수는 한 가지를 해야 하며, 그 한 가지를 잘해야 한다. 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행해야 한다. 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하고 있는 것이다. 추상화 수준은 하나로 함수가 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 근본 개념과 세부사항이 한 번 뒤섞이면 함수에 세부사항이 끝없이 추가된다. 하나의 함수를 구현하고 난 뒤..
