1장: 깔끔한 코드
-
전체적인 혼란의 양은 시간이 지남에 따라 증가합니다.
-
오래된 시스템을 처음부터 복원하는 것은 매우 어렵습니다. 이를 위해서는 리팩토링과 점진적인 개선이 최선의 선택이 될 것입니다.
-
지저분한 코드베이스에서는 몇 시간 밖에 걸리지 않는 작업을 완료하는 데 며칠 또는 몇 주가 걸릴 수 있습니다.
-
시간을 내어 신속하게 행동하십시오.
-
클린 코드는 한 가지 일을 잘 수행합니다. 나쁜 코드는 너무 많은 일을 하려고 합니다.
-
깨끗한 코드는 잘 테스트되었습니다.
-
잘 작성된 코드를 읽을 때 각 함수는 대략적으로 예상한 대로 작동합니다.
-
수년 간의 경험을 가진 사람이 가르친 원리에 동의하지 않는다면, 무시하기 전에 최소한 그 사람의 관점을 고려해 보아야 합니다.
-
코드는 작성된 것보다 훨씬 더 자주 읽혀집니다.
-
읽기 쉬운 코드는 변경하기도 쉽습니다.
-
코드베이스를 처음 찾았을 때보다 더 좋게 남겨두세요(보이스카우트 규칙).
2장: 이름의 의미
-
변수 이름을 신중하게 선택하세요.
-
좋은 이름을 선택하는 것은 어렵습니다.
-
변수나 함수의 이름은 그것이 무엇인지, 어떻게 사용되는지를 나타내야 합니다.
-
루프의 카운터 변수인 i와 같이 일반적으로 사용되는 이름을 제외하고 단일 문자 변수 이름을 사용하지 마십시오.
-
변수 이름에 약어를 사용하지 마십시오.
-
변수 이름은 발음 가능해야 변수에 대해 이야기하고 큰 소리로 말할 수 있습니다.
-
찾기 쉬운 변수 이름을 사용하세요.
-
클래스와 객체에는 명사 형태의 이름이 있어야 합니다.
-
메소드 및 함수 이름은 동사 또는 동사-명사 쌍이어야 합니다.
3장: 기능
-
함수는 작아야 합니다.
-
함수는 하나의 작업을 수행해야 합니다.
-
함수에는 설명이 포함된 이름이 있어야 합니다.
-
if/else 본문에서 코드를 추출하거나 명령문을 명확한 이름의 함수로 전환하세요.
-
함수가 취하는 인수의 수를 제한합니다.
-
함수에 많은 구성 인수가 필요한 경우 이를 단일 구성 매개변수 변수로 결합하는 것이 좋습니다.
-
함수는 순수해야 합니다. 즉, 부작용이 없고 입력 인수를 수정하지 않아야 합니다.
-
함수는 명령 또는 쿼리여야 하지만 동시에 둘 다일 수는 없습니다(명령 쿼리 분리).
-
코드에 오류를 남기는 것보다 코드에서 오류와 예외를 제거하는 것이 더 좋습니다.
-
중복 코드를 명확한 이름의 함수로 추출합니다(반복하지 마세요).
-
단위 테스트를 사용하면 리팩토링이 더 쉬워집니다.
4장: 설명
-
댓글이 정확하지 않을 수 있습니다. 처음에는 잘못되었을 수도 있고, 처음에는 정확했지만 시간이 지나면서 코드가 변경되면서 오래된 것이 될 수도 있습니다.
-
무슨 일이 일어나고 있는지 설명하기보다는 주석을 사용하여 왜 그렇게 작성되었는지 설명하세요.
-
명확한 이름의 변수를 사용하고 코드 섹션을 명확한 이름의 함수로 추출하면 주석을 피할 수 있는 경우가 많습니다.
-
TODO 주석에 일관된 접두사를 붙여서 쉽게 찾을 수 있도록 하세요. TODO 주석을 주기적으로 검토하고 정리하세요.
-
단지 Javadoc을 사용하기 위한 목적으로만 사용하지 마십시오. 메서드가 수행하는 작업, 인수, 반환 내용을 설명하는 주석은 잘해야 중복되고 최악의 경우 오해의 소지가 있습니다.
-
의견에는 독자에게 필요한 모든 관련 정보와 맥락이 포함되어야 합니다. 댓글을 작성할 때 게으르지 마십시오.
-
버전 제어 및 Git 비난으로 인해 로그 주석 및 파일 작성자 주석이 필요하지 않습니다.
-
데드 코드를 주석 처리하지 마세요. 그냥 삭제하세요. 미래에 코드가 필요할 것이라고 생각한다면, 그것이 바로 버전 제어의 목적입니다.
5장: 서식 지정
-
팀으로서 코드 형식을 지정하기 위한 규칙 세트를 선택한 다음 해당 규칙을 일관되게 적용하십시오. 어떤 규칙에 동의하든 합의에 도달해야 합니다.
-
자동 코드 서식 지정 및 코드 분석기를 사용하세요. 모든 서식 오류를 수동으로 찾아서 수정하는 데 사람에게 의존하지 마세요. 이는 코드를 검토할 때 비효율적이고 비생산적이며 시간 낭비입니다.
-
관련 코드 블록을 시각적으로 구분하려면 코드 줄 사이에 세로 공백을 추가하세요. 필요한 것은 그룹 사이에 하나의 새로운 줄을 만드는 것입니다.
-
작은 파일은 큰 파일보다 읽고 이해하고 이동하기가 더 쉽습니다.
-
변수는 사용되는 위치 근처에서 선언되어야 합니다. 작은 함수의 경우 이는 일반적으로 함수의 맨 위에 있습니다.
-
짧은 함수나 if 문의 경우에도 한 줄에 작성하는 대신 올바른 형식을 지정하세요.
6장: 객체와 데이터 구조
-
객체의 구현 세부정보는 객체 인터페이스 뒤에 숨겨져 있어야 합니다. 객체 소비자가 사용할 인터페이스를 제공하면 나중에 주요 변경 사항을 발생시키지 않고 구현 세부 사항을 리팩토링하기가 더 쉬워집니다. 추상화를 사용하면 리팩토링이 더 쉬워집니다.
-
주어진 코드 조각은 그것이 작동하는 객체의 내부에 대한 지식이 없어야 합니다.
-
개체로 작업할 때는 개체에게 내부 내용을 묻는 것이 아니라 명령이나 쿼리를 수행하도록 요구해야 합니다.
7장: 오류 수정
-
오류 처리는 모듈의 나머지 코드를 방해해서는 안 됩니다.
-
코드에 오류를 남기는 것보다 코드에서 오류와 예외를 제거하는 것이 더 좋습니다.
-
오류가 있는 테스트를 작성하여 코드에서 오류를 식별하고 놓치지 않도록 하세요.
-
오류 메시지는 정보를 제공해야 하며 누군가가 효과적으로 문제를 해결하는 데 필요할 수 있는 모든 필수 컨텍스트를 포함해야 합니다.
-
얇은 추상화 계층으로 타사 API를 래핑하면 나중에 하나의 라이브러리를 다른 라이브러리로 쉽게 교체할 수 있습니다.
-
얇은 추상화 계층으로 타사 API를 래핑하면 테스트 중에 라이브러리를 더 쉽게 모의할 수 있습니다.
-
특정 데이터가 존재하지 않는 경우와 같은 예외적인 동작을 처리하려면 특수 사례 패턴 또는 Null 개체 패턴을 사용합니다.
8장: 경계
-
타사 라이브러리는 다양한 작업을 아웃소싱할 수 있도록 하여 제품 제공 속도를 높이는 데 도움이 됩니다.
-
타사 라이브러리를 올바르게 사용하고 있는지 확인하는 테스트를 작성하세요.
-
어댑터 패턴을 사용하여 타사 라이브러리의 API와 원하는 API 사이의 격차를 해소하세요.
-
얇은 추상화 계층으로 타사 API를 래핑하면 나중에 하나의 라이브러리를 다른 라이브러리로 쉽게 교체할 수 있습니다. (7장부터 반복)
-
얇은 추상화 계층으로 타사 API를 래핑하면 테스트 중에 라이브러리를 더 쉽게 모의할 수 있습니다. (7장부터 반복)
-
타사 라이브러리의 세부 정보에 대해 너무 많은 정보를 애플리케이션에 알려주지 마십시오.
-
당신이 통제하지 않는 것보다 당신이 통제하는 것에 의존하는 것이 더 낫습니다.
9장: 단위 테스트
-
테스트 코드는 프로덕션 코드만큼 깨끗해야 합니다(일반적으로 메모리나 효율성과 관련된 일부 예외가 있음).
-
프로덕션 코드가 변경되면 테스트 코드도 변경됩니다.
-
테스트는 프로덕션 코드를 유연하고 유지 관리 가능하게 유지하는 데 도움이 됩니다.
-
테스트를 통해 변경 사항을 적용할 수 있으므로 스스로 눈치채지 못할 염려 없이 자신 있게 리팩토링할 수 있습니다.
-
배열-작동-어설션(Build-Operate-Check, Setup-Exercise-Verify 또는 Give-When-Then이라고도 함) 패턴을 사용하여 테스트를 구성합니다.
-
도메인별 기능을 사용하여 테스트를 더 쉽게 작성하고 읽을 수 있습니다.
-
테스트 당 하나의 개념을 채점하십시오.
-
테스트는 빨라야 합니다.
-
테스트는 독립적이어야 합니다.
-
테스트는 반복 가능해야 합니다.
-
테스트에는 확인이 필요하지 않습니다.
-
테스트는 몇 달 후가 아니라 프로덕션 코드가 작성되기 직전이나 직후에 적시에 작성되어야 합니다.
-
테스트가 좋지 않으면 코드에 버그가 있을 수 있습니다.
10장: 클래스
-
수업은 작아야합니다.
-
클래스는 한 가지에만 책임을 져야 하며 변경 이유는 하나만 있어야 합니다(단일 책임 원칙).
-
수업의 명확한 이름을 생각해 낼 수 없다면 아마도 너무 클 것입니다.
-
작업할 코드 조각이 있다고 해서 작업이 끝나지는 않습니다. 다음 단계는 코드를 리팩터링하고 정리하는 것입니다.
-
애플리케이션에서 여러 개의 큰 클래스 대신 여러 개의 작은 클래스를 사용하면 개발자가 특정 작업을 수행할 때 이해해야 하는 정보의 양이 줄어듭니다.
-
좋은 테스트 스위트가 있으면 큰 클래스를 작은 클래스로 나눌 때 자신 있게 리팩터링할 수 있습니다.
-
수업은 확장을 위해 열려야 하고 수정을 위해 닫혀 있어야 합니다(개방-폐쇄 원칙).
-
인터페이스와 추상 클래스는 테스트를 더 쉽게 만드는 이음새를 만듭니다.
11장: 시스템
-
종속성 주입을 사용하면 개발자가 적절한 인터페이스가 있는 개체를 다른 클래스에 전달할 수 있는 유연성을 제공할 수 있습니다.
-
테스트를 더 쉽게 만들기 위해 종속성 주입을 사용하여 애플리케이션의 개체 간 인터페이스를 만듭니다.
-
소프트웨어 시스템은 미리 설계해야 하는 건물과 다릅니다. 그들은 시간이 지남에 따라 현재의 요구에 적응하면서 성장하고 확장하는 도시에 가깝습니다.
-
마지막 중요한 순간까지 결정을 연기하십시오.
-
도메인 전문가와 개발자가 동일한 용어를 사용할 수 있도록 도메인별 언어를 사용합니다.
-
시스템을 지나치게 복잡하게 만들지 마십시오. 작동하는 가장 간단한 것을 사용하십시오.
12장: 배포
-
테스트할 수 없는 시스템은 검증할 수 없으며, 검증할 수 없는 시스템은 배포해서는 안 됩니다.
-
테스트하기 쉬운 코드는 종속성 주입, 인터페이스 및 추상화를 사용하는 경우가 많기 때문에 테스트를 작성하면 더 나은 디자인이 됩니다.
-
좋은 테스트 세트는 리팩토링 중에 애플리케이션이 손상될 것이라는 두려움을 없애줍니다.
-
코드를 복제하면 코드에서 변경할 수 있는 부분이 더 많고 오류가 숨겨질 수 있는 부분이 더 많기 때문에 더 많은 위험이 발생합니다.
-
지금 작성하는 코드는 코드를 이해하는 데 깊이 관여하기 때문에 이해하기가 더 쉽습니다. 다른 사람들이 같은 수준의 이해에 빨리 도달하는 것은 쉽지 않습니다.
-
소프트웨어 프로젝트 비용의 대부분은 장기 유지 관리와 관련이 있습니다.
-
테스트는 애플리케이션이 어떻게 작동해야 하는지(그리고 실제로 작동하는지)에 대한 살아있는 문서 역할을 합니다.
-
코드가 작동하면 더 이상 움직이지 마십시오. 더 명확하고 이해하기 쉽게 만드는 데 시간을 투자하세요.
-
가까운 시일 내에 귀하의 코드를 읽을 다음 사람은 귀하일 가능성이 높습니다. 이해하기 쉬운 코드를 작성하여 미래의 자신에게 친절하세요.
-
도그마에 저항하세요. 실용주의를 받아들이세요.
-
정말 훌륭한 소프트웨어 엔지니어가 되려면 수십 년이 걸립니다. 주변 전문가로부터 배우고 일반적으로 사용되는 디자인 패턴을 학습하면 학습 속도를 높일 수 있습니다.
13장: 병렬성
-
병렬 코드를 작성하는 것은 어렵습니다.
-
재현하기 어려운 가끔 발생하는 버그와 문제는 동시성 문제인 경우가 많습니다.
-
테스트를 한다고 해서 애플리케이션에 버그가 없다고 보장할 수는 없지만 위험은 최소화됩니다.
-
일반적인 동시성 문제와 가능한 해결 방법에 대해 알아보세요.
14장: 순차적 개선
-
클린 코드는 일반적으로 백지상태에서 시작되지 않습니다. 먼저 대략적인 솔루션을 작성한 다음 리팩터링하여 더 깔끔하게 만듭니다.
-
코드 작업이 시작된 후에 작업을 중단하는 것은 실수입니다. 이미 작동하고 있는 후에는 시간을 들여 더 나은 결과를 얻으십시오.
-
불안은 점차 커지고 있습니다.
-
기능 추가가 너무 어렵거나 시간이 너무 오래 걸리는 상황에 처했다면 기능 작성을 중단하고 리팩토링을 시작하세요.
-
점진적인 변경은 처음부터 다시 구축하는 것보다 더 나은 경우가 많습니다.
-
TDD(테스트 기반 개발)를 사용하여 아주 작은 변경 사항을 많이 적용하세요.
-
좋은 소프트웨어 설계에는 코드의 문제를 분리하고 코드를 더 작은 모듈, 클래스 및 파일로 분리하는 것이 포함됩니다.
-
나중에 청소하는 것보다 엉망진창을 만든 후에 즉시 청소하는 것이 더 쉽습니다.
15장: JUnit 내부
-
음수 변수 이름이나 조건식은 양수 변수 이름보다 이해하기가 조금 더 어렵습니다.
-
리팩토링은 시행착오로 가득 찬 반복 프로세스입니다.
-
코드베이스를 처음 찾았을 때보다 더 좋게 남겨두세요(보이스카우트 규칙). (1장에서 반복)
16장: SerialDate 리팩토링
-
코드 리뷰와 우리 코드에 대한 비평은 우리를 더 좋게 만들고, 우리는 그것을 환영해야 합니다.
-
먼저 코드를 작동시킨 다음 수정하세요.
-
모든 코드 줄에 테스트가 필요한 것은 아닙니다.
17장: 냄새와 휴리스틱
-
클린 코드는 일련의 규칙이 아니라 작업의 품질을 결정하는 가치 체계입니다.
GO TO FULL VERSION