• 어떤 코드건 작성하기 전에 실패하는 자동화된 테스트를 작성하라 • 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성하라 • 중복을 제거하라 📌 TDD 리듬 재빨리 테스트를 하나 추가한다. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다. 코드를 조금 바꾼다. 모든 테스트를 실행하고 전부 성공하는지 확인한다. 리팩토링을 통해 중복을 제거한다. ✒️ 프로그래밍 순서 1. 빨강: 실패하는 작은 테스트를 작성하라. 처음에는 컴파일조차 되지 않을 수 있다. 2. 초록: 빨리 테스트가 통과하게끔 한다. 이를 위해 어떠한 죄악을 저질러도 좋다. 3. 리팩토링: 일단 테스트를 통과하게만 하는 와중에 생긴 모든 중복을 제거하라. 📌 As-is 다음과 같은 보고서가 있다고 하자. 종목 주 가격 합..

✨ 핵심 정리 • 일반적으로 매개변수 수가 같을 때는 다중 정의를 피하는 게 좋다. • 어쩔 수 없는 경우(ex. 생성자)라면 헷갈릴만한 매개변수는 형변환하라. • 불가능하다면 같은 객체를 입력받는 다중 정의 메서드들이 모두 동일하게 동작하게 만들어라. 📌 Overriding 💡 재정의한 메서드는 동적으로 선택되고, 다중정의한 메서드는 정적으로 선택된다. class Wine { String name() { return "포도주"; } } class SparklingWine extends Wine { @Override String name() { return "발포성 포도주"; } } class Champagne extends SparklingWine { @Override String name() { re..

📕 목차 1. 형식을 맞추는 목적 2. 적절한 행 길이를 유지하라 • 신문 기사처럼 작성하라 • 개념은 빈 행으로 분리하라 • 세로 밀집도 • 수직 거리 • 세로 순서 3. 가로 형식 맞추기 • 가로 공백과 밀집도 • 가로 정렬 • 들여쓰기 • 가짜 범위 4. 팀 규칙 1. 형식을 맞추는 목적 코드 형식은 너무나 중요하기 때문에, 융툥성 없이 맹목적으로 따르면 안 된다. 코드 형식은 의사소통의 일환이며, 의사소통은 전문 개발자의 일차적 의무다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울지라도, 맨 처음 잡은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 2. 적절한 행 길이를 유지하라 위 표를 통해, 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 ..

이번 챕터는 개별 Item으로 두기 애매한 API 설계 요령들에 대한 내용들이다. 그냥 지금까지 했던 내용들 복습하는 느낌으로 읽어도 무방 메서드 이름을 신중히 짓자 항상 표준 명명 규칙(Item 68)을 따르라. 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관성을 지켜라 긴 이름은 피하되, 의미를 명확히 밝힐 수 없다면 차라리 긴 게 낫다. 개발자 커뮤니티에서 널리 받아지는 이름과 자바 라이브러리 API를 참조하라. 편의 메서드를 너무 많이 만들지 말자 메서드가 너무 많은 클래스나 인터페이스는 사용하고, 익히고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두어라. 확신이 서지 않으면 만들지 마라. 매개변수 목록은 짧게 유지하다 (4개 이하) 여..