커피 브레이크 #103. “클린 코드” 방어: 시대를 초월한 100가지 팁

출처: Robert C. Martin이 쓴 Hackernoon “Clean Code”는 역대 가장 추천되는 프로그래밍 책입니다. "소프트웨어 개발자를 위한 최고의 책"이라는 검색어를 사용하여 책을 검색하면 검색 결과에 이 책이 거의 확실하게 표시됩니다. 그리고 일부 사람들은 클린 코드에 주목할 가치가 없다고 생각하지만, 나는 그러한 감정이 심각한 착각이라고 주장하고 싶습니다. 예, 책에 나오는 조언 중 일부는 의심스럽습니다. 예, 일부 콘텐츠가 오래된 것 같습니다. 예, 일부 예는 혼란스럽습니다. 모두 사실입니다. 하지만 이 책이 제공하는 많은 유용한 팁을 너무 성급하게 무시해서는 안 됩니다! 단순히 몇 가지 나쁜 아이디어 때문에 클린 코드를 완전히 무시하는 것은 최선의 해결책이 아닙니다. 그럼 더 이상 고민하지 말고 Clean Code가 제공하는 최고의 팁을 살펴보겠습니다! 우리는 Bob 삼촌과 그의 공동 저자가 제공하는 아이디어를 요약하면서 각 장을 살펴보겠습니다.

1장: 깔끔한 코드

1. 전체적인 혼란의 양은 시간이 지남에 따라 증가합니다.

2. 오래된 시스템을 처음부터 복원하는 것은 매우 어렵습니다. 이를 위해서는 리팩토링과 점진적인 개선이 최선의 선택이 될 것입니다.

3. 지저분한 코드베이스에서는 몇 시간 밖에 걸리지 않는 작업을 완료하는 데 며칠 또는 몇 주가 걸릴 수 있습니다.

4. 시간을 내어 신속하게 행동하십시오.

5. 클린 코드는 한 가지 일을 잘 수행합니다. 나쁜 코드는 너무 많은 일을 하려고 합니다.

6. 깨끗한 코드는 잘 테스트되었습니다.

7. 잘 작성된 코드를 읽을 때 각 함수는 대략적으로 예상한 대로 작동합니다.

8. 수년 간의 경험을 가진 사람이 가르친 원리에 동의하지 않는다면, 무시하기 전에 최소한 그 사람의 관점을 고려해 보아야 합니다.

9. 코드는 작성된 것보다 훨씬 더 자주 읽혀집니다.

10. 읽기 쉬운 코드는 변경하기도 쉽습니다.

11. 코드베이스를 처음 찾았을 때보다 더 좋게 남겨두세요(보이스카우트 규칙).

2장: 이름의 의미

1. 변수 이름을 신중하게 선택하세요.

2. 좋은 이름을 선택하는 것은 어렵습니다.

3. 변수나 함수의 이름은 그것이 무엇인지, 어떻게 사용되는지를 나타내야 합니다.

4. 루프의 카운터 변수인 i와 같이 일반적으로 사용되는 이름을 제외하고 단일 문자 변수 이름을 사용하지 마십시오.

5. 변수 이름에 약어를 사용하지 마십시오.

6. 변수 이름은 발음 가능해야 변수에 대해 이야기하고 큰 소리로 말할 수 있습니다.

7. 찾기 쉬운 변수 이름을 사용하세요.

8. 클래스와 객체에는 명사 형태의 이름이 있어야 합니다.

9. 메소드 및 함수 이름은 동사 또는 동사-명사 쌍이어야 합니다.

3장: 기능

1. 함수는 작아야 합니다.

2. 함수는 하나의 작업을 수행해야 합니다.

3. 함수에는 설명이 포함된 이름이 있어야 합니다.

4. if/else 본문에서 코드를 추출하거나 명령문을 명확한 이름의 함수로 전환하세요.

5. 함수가 취하는 인수의 수를 제한합니다.

6. 함수에 많은 구성 인수가 필요한 경우 이를 단일 구성 매개변수 변수로 결합하는 것이 좋습니다.

7. 함수는 순수해야 합니다. 즉, 부작용이 없고 입력 인수를 수정하지 않아야 합니다.

8. 함수는 명령 또는 쿼리여야 하지만 동시에 둘 다일 수는 없습니다(명령 쿼리 분리).

9. 코드에 오류를 남기는 것보다 코드에서 오류와 예외를 제거하는 것이 더 좋습니다.

10. 중복 코드를 명확한 이름의 함수로 추출합니다(반복하지 마세요).

11. 단위 테스트를 사용하면 리팩토링이 더 쉬워집니다.

4장: 설명

1. 댓글이 정확하지 않을 수 있습니다. 처음에는 잘못되었을 수도 있고, 처음에는 정확했지만 시간이 지나면서 코드가 변경되면서 오래된 것이 될 수도 있습니다.

2. 무슨 일이 일어나고 있는지 설명하기보다는 주석을 사용하여 왜 그렇게 작성되었는지 설명하세요.

3. 명확한 이름의 변수를 사용하고 코드 섹션을 명확한 이름의 함수로 추출하면 주석을 피할 수 있는 경우가 많습니다.

4. TODO 주석에 일관된 접두사를 붙여서 쉽게 찾을 수 있도록 하세요. TODO 주석을 주기적으로 검토하고 정리하세요.

5. 단지 Javadoc을 사용하기 위한 목적으로만 사용하지 마십시오. 메서드가 수행하는 작업, 인수, 반환 내용을 설명하는 주석은 잘해야 중복되고 최악의 경우 오해의 소지가 있습니다.

6. 의견에는 독자에게 필요한 모든 관련 정보와 맥락이 포함되어야 합니다. 댓글을 작성할 때 게으르지 마십시오.

7. 버전 제어 및 Git 비난으로 인해 로그 주석 및 파일 작성자 주석이 필요하지 않습니다.

8. 데드 코드를 주석 처리하지 마세요. 그냥 삭제하세요. 미래에 코드가 필요할 것이라고 생각한다면, 그것이 바로 버전 제어의 목적입니다.

5장: 서식 지정

1. 팀으로서 코드 형식을 지정하기 위한 규칙 세트를 선택한 다음 해당 규칙을 일관되게 적용하십시오. 어떤 규칙에 동의하든 합의에 도달해야 합니다.

2. 자동 코드 서식 지정 및 코드 분석기를 사용하세요. 모든 서식 오류를 수동으로 찾아서 수정하는 데 사람에게 의존하지 마세요. 이는 코드를 검토할 때 비효율적이고 비생산적이며 시간 낭비입니다.

3. 관련 코드 블록을 시각적으로 구분하려면 코드 줄 사이에 세로 공백을 추가하세요. 필요한 것은 그룹 사이에 하나의 새로운 줄을 만드는 것입니다.

4. 작은 파일은 큰 파일보다 읽고 이해하고 이동하기가 더 쉽습니다.

5. 변수는 사용되는 위치 근처에서 선언되어야 합니다. 작은 함수의 경우 이는 일반적으로 함수의 맨 위에 있습니다.

6. 짧은 함수나 if 문의 경우에도 한 줄에 작성하는 대신 올바른 형식을 지정하세요.

6장: 객체와 데이터 구조

1. 객체의 구현 세부정보는 객체 인터페이스 뒤에 숨겨져 있어야 합니다. 객체 소비자가 사용할 인터페이스를 제공하면 나중에 주요 변경 사항을 발생시키지 않고 구현 세부 사항을 리팩토링하기가 더 쉬워집니다. 추상화를 사용하면 리팩토링이 더 쉬워집니다.

2. 주어진 코드 조각은 그것이 작동하는 객체의 내부에 대한 지식이 없어야 합니다.

3. 개체로 작업할 때는 개체에게 내부 내용을 묻는 것이 아니라 명령이나 쿼리를 수행하도록 요구해야 합니다.

7장: 오류 수정

1. 오류 처리는 모듈의 나머지 코드를 방해해서는 안 됩니다.

2. 코드에 오류를 남기는 것보다 코드에서 오류와 예외를 제거하는 것이 더 좋습니다.

3. 오류가 있는 테스트를 작성하여 코드에서 오류를 식별하고 놓치지 않도록 하세요.

4. 오류 메시지는 정보를 제공해야 하며 누군가가 효과적으로 문제를 해결하는 데 필요할 수 있는 모든 필수 컨텍스트를 포함해야 합니다.

5. 얇은 추상화 계층으로 타사 API를 래핑하면 나중에 하나의 라이브러리를 다른 라이브러리로 쉽게 교체할 수 있습니다.

6. 얇은 추상화 계층으로 타사 API를 래핑하면 테스트 중에 라이브러리를 더 쉽게 모의할 수 있습니다.

7. 특정 데이터가 존재하지 않는 경우와 같은 예외적인 동작을 처리하려면 특수 사례 패턴 또는 Null 개체 패턴을 사용합니다.

8장: 경계

1. 타사 라이브러리는 다양한 작업을 아웃소싱할 수 있도록 하여 제품 제공 속도를 높이는 데 도움이 됩니다.

2. 타사 라이브러리를 올바르게 사용하고 있는지 확인하는 테스트를 작성하세요.

3. 어댑터 패턴을 사용하여 타사 라이브러리의 API와 원하는 API 사이의 격차를 해소하세요.

4. 얇은 추상화 계층으로 타사 API를 래핑하면 나중에 하나의 라이브러리를 다른 라이브러리로 쉽게 교체할 수 있습니다. (7장부터 반복)

5. 얇은 추상화 계층으로 타사 API를 래핑하면 테스트 중에 라이브러리를 더 쉽게 모의할 수 있습니다. (7장부터 반복)

6. 타사 라이브러리의 세부 정보에 대해 너무 많은 정보를 애플리케이션에 알려주지 마십시오.

7. 당신이 통제하지 않는 것보다 당신이 통제하는 것에 의존하는 것이 더 낫습니다.

9장: 단위 테스트

1. 테스트 코드는 프로덕션 코드만큼 깨끗해야 합니다(일반적으로 메모리나 효율성과 관련된 일부 예외가 있음).

2. 프로덕션 코드가 변경되면 테스트 코드도 변경됩니다.

3. 테스트는 프로덕션 코드를 유연하고 유지 관리 가능하게 유지하는 데 도움이 됩니다.

4. 테스트를 통해 변경 사항을 적용할 수 있으므로 스스로 눈치채지 못할 염려 없이 자신 있게 리팩토링할 수 있습니다.

5. 배열-작동-어설션(Build-Operate-Check, Setup-Exercise-Verify 또는 Give-When-Then이라고도 함) 패턴을 사용하여 테스트를 구성합니다.

6. 도메인별 기능을 사용하여 테스트를 더 쉽게 작성하고 읽을 수 있습니다.

7. 테스트 당 하나의 개념을 채점하십시오.

8. 테스트는 빨라야 합니다.

9. 테스트는 독립적이어야 합니다.

10. 테스트는 반복 가능해야 합니다.

11. 테스트에는 확인이 필요하지 않습니다.

12. 테스트는 몇 달 후가 아니라 프로덕션 코드가 작성되기 직전이나 직후에 적시에 작성되어야 합니다.

13. 테스트가 좋지 않으면 코드에 버그가 있을 수 있습니다.

10장: 클래스

1. 수업은 작아야합니다.

2. 클래스는 한 가지에만 책임을 져야 하며 변경 이유는 하나만 있어야 합니다(단일 책임 원칙).

3. 수업의 명확한 이름을 생각해 낼 수 없다면 아마도 너무 클 것입니다.

4. 작업할 코드 조각이 있다고 해서 작업이 끝나지는 않습니다. 다음 단계는 코드를 리팩터링하고 정리하는 것입니다.

5. 애플리케이션에서 여러 개의 큰 클래스 대신 여러 개의 작은 클래스를 사용하면 개발자가 특정 작업을 수행할 때 이해해야 하는 정보의 양이 줄어듭니다.

6. 좋은 테스트 스위트가 있으면 큰 클래스를 작은 클래스로 나눌 때 자신 있게 리팩터링할 수 있습니다.

7. 수업은 확장을 위해 열려야 하고 수정을 위해 닫혀 있어야 합니다(개방-폐쇄 원칙).

8. 인터페이스와 추상 클래스는 테스트를 더 쉽게 만드는 이음새를 만듭니다.

11장: 시스템

1. 종속성 주입을 사용하면 개발자가 적절한 인터페이스가 있는 개체를 다른 클래스에 전달할 수 있는 유연성을 제공할 수 있습니다.

2. 테스트를 더 쉽게 만들기 위해 종속성 주입을 사용하여 애플리케이션의 개체 간 인터페이스를 만듭니다.

3. 소프트웨어 시스템은 미리 설계해야 하는 건물과 다릅니다. 그들은 시간이 지남에 따라 현재의 요구에 적응하면서 성장하고 확장하는 도시에 가깝습니다.

4. 마지막 중요한 순간까지 결정을 연기하십시오.

5. 도메인 전문가와 개발자가 동일한 용어를 사용할 수 있도록 도메인별 언어를 사용합니다.

6. 시스템을 지나치게 복잡하게 만들지 마십시오. 작동하는 가장 간단한 것을 사용하십시오.

12장: 배포

1. 테스트할 수 없는 시스템은 검증할 수 없으며, 검증할 수 없는 시스템은 배포해서는 안 됩니다.

2. 테스트하기 쉬운 코드는 종속성 주입, 인터페이스 및 추상화를 사용하는 경우가 많기 때문에 테스트를 작성하면 더 나은 디자인이 됩니다.

3. 좋은 테스트 세트는 리팩토링 중에 애플리케이션이 손상될 것이라는 두려움을 없애줍니다.

4. 코드를 복제하면 코드에서 변경할 수 있는 부분이 더 많고 오류가 숨겨질 수 있는 부분이 더 많기 때문에 더 많은 위험이 발생합니다.

5. 지금 작성하는 코드는 코드를 이해하는 데 깊이 관여하기 때문에 이해하기가 더 쉽습니다. 다른 사람들이 같은 수준의 이해에 빨리 도달하는 것은 쉽지 않습니다.

6. 소프트웨어 프로젝트 비용의 대부분은 장기 유지 관리와 관련이 있습니다.

7. 테스트는 애플리케이션이 어떻게 작동해야 하는지(그리고 실제로 작동하는지)에 대한 살아있는 문서 역할을 합니다.

8. 코드가 작동하면 더 이상 움직이지 마십시오. 더 명확하고 이해하기 쉽게 만드는 데 시간을 투자하세요.

9. 가까운 시일 내에 귀하의 코드를 읽을 다음 사람은 귀하일 가능성이 높습니다. 이해하기 쉬운 코드를 작성하여 미래의 자신에게 친절하세요.

10. 도그마에 저항하세요. 실용주의를 받아들이세요.

11. 정말 훌륭한 소프트웨어 엔지니어가 되려면 수십 년이 걸립니다. 주변 전문가로부터 배우고 일반적으로 사용되는 디자인 패턴을 학습하면 학습 속도를 높일 수 있습니다.

13장: 병렬성

1. 병렬 코드를 작성하는 것은 어렵습니다.

2. 재현하기 어려운 가끔 발생하는 버그와 문제는 동시성 문제인 경우가 많습니다.

3. 테스트를 한다고 해서 애플리케이션에 버그가 없다고 보장할 수는 없지만 위험은 최소화됩니다.

4. 일반적인 동시성 문제와 가능한 해결 방법에 대해 알아보세요.

14장: 순차적 개선

1. 클린 코드는 일반적으로 백지상태에서 시작되지 않습니다. 먼저 대략적인 솔루션을 작성한 다음 리팩터링하여 더 깔끔하게 만듭니다.

2. 코드 작업이 시작된 후에 작업을 중단하는 것은 실수입니다. 이미 작동하고 있는 후에는 시간을 들여 더 나은 결과를 얻으십시오.

3. 불안은 점차 커지고 있습니다.

4. 기능 추가가 너무 어렵거나 시간이 너무 오래 걸리는 상황에 처했다면 기능 작성을 중단하고 리팩토링을 시작하세요.

5. 점진적인 변경은 처음부터 다시 구축하는 것보다 더 나은 경우가 많습니다.

6. TDD(테스트 기반 개발)를 사용하여 아주 작은 변경 사항을 많이 적용하세요.

7. 좋은 소프트웨어 설계에는 코드의 문제를 분리하고 코드를 더 작은 모듈, 클래스 및 파일로 분리하는 것이 포함됩니다.

8. 나중에 청소하는 것보다 엉망진창을 만든 후에 즉시 청소하는 것이 더 쉽습니다.

15장: JUnit 내부

1. 음수 변수 이름이나 조건식은 양수 변수 이름보다 이해하기가 조금 더 어렵습니다.

2. 리팩토링은 시행착오로 가득 찬 반복 프로세스입니다.

3. 코드베이스를 처음 찾았을 때보다 더 좋게 남겨두세요(보이스카우트 규칙). (1장에서 반복)

16장: SerialDate 리팩토링

1. 코드 리뷰와 우리 코드에 대한 비평은 우리를 더 좋게 만들고, 우리는 그것을 환영해야 합니다.

2. 먼저 코드를 작동시킨 다음 수정하세요.

3. 모든 코드 줄에 테스트가 필요한 것은 아닙니다.

17장: 냄새와 휴리스틱

1. 클린 코드는 일련의 규칙이 아니라 작업의 품질을 결정하는 가치 체계입니다.

[이 장에서 Bob 삼촌은 자신의 코드와 경험적 방법에 대한 66가지 변형을 더 나열하며 그 중 많은 부분이 책의 나머지 부분에서 다루어졌습니다. 여기서 재현한다는 것은 본질적으로 각 항목의 이름을 복사하여 붙여넣는 것이므로 그렇게 하지 않았습니다. 대신 책을 읽어보시길 권합니다!]

결론

시작한 곳에서 끝내겠습니다. Robert C. Martin의 Clean Code는 역대 가장 추천되는 프로그래밍 책입니다. 여기에는 그럴만한 이유가 있습니다.