Facebook Pixel
Searching...
Русский
EnglishEnglish
EspañolSpanish
简体中文Chinese
FrançaisFrench
DeutschGerman
日本語Japanese
PortuguêsPortuguese
ItalianoItalian
한국어Korean
РусскийRussian
NederlandsDutch
العربيةArabic
PolskiPolish
हिन्दीHindi
Tiếng ViệtVietnamese
SvenskaSwedish
ΕλληνικάGreek
TürkçeTurkish
ไทยThai
ČeštinaCzech
RomânăRomanian
MagyarHungarian
УкраїнськаUkrainian
Bahasa IndonesiaIndonesian
DanskDanish
SuomiFinnish
БългарскиBulgarian
עבריתHebrew
NorskNorwegian
HrvatskiCroatian
CatalàCatalan
SlovenčinaSlovak
LietuviųLithuanian
SlovenščinaSlovenian
СрпскиSerbian
EestiEstonian
LatviešuLatvian
فارسیPersian
മലയാളംMalayalam
தமிழ்Tamil
اردوUrdu
Clean Code

Clean Code

A Handbook of Agile Software Craftsmanship
автор Robert C. Martin 2007 464 страниц
4.37
22k+ оценки
Слушать
13 минут
Слушать

ключевых вывода

1. Пишите чистый код, который легко читать и поддерживать

Единственная допустимая мера качества кода: WTFs/минута

Читаемость превыше всего. Чистый код должен быть легко понятен другим разработчикам. Он должен быть простым, элегантным и свободным от лишнего. Стремитесь писать код, который ясно выражает свои намерения без необходимости в обширных комментариях. Используйте значимые имена переменных и функций, держите функции маленькими и сфокусированными, и логически организуйте код.

Поддерживаемость позволяет эволюционировать. Код, который трудно изменить, становится обузой. Проектируйте свой код так, чтобы он был гибким и модульным, чтобы он мог адаптироваться к изменяющимся требованиям. Следуйте принципам, таким как DRY (Don't Repeat Yourself) и SOLID, чтобы создавать слабо связанные, высоко когерентные системы. Безжалостно рефакторите, чтобы улучшить структуру кода без изменения его поведения.

Чистый код окупается. Хотя написание чистого кода требует больше усилий на начальном этапе, это экономит значительное время и избавляет от головной боли в долгосрочной перспективе. Чистый код легче отлаживать, расширять и поддерживать. Он позволяет разработчикам работать более эффективно и снижает риск внесения ошибок при изменениях. Сделайте чистый код основой своей практики разработки.

2. Следуйте значимым соглашениям о наименованиях

Имя переменной, функции или класса должно отвечать на все важные вопросы. Оно должно объяснять, почему оно существует, что оно делает и как используется.

Используйте имена, раскрывающие намерения. Выбирайте имена, которые ясно передают цель и поведение переменных, функций и классов. Избегайте однобуквенных имен или криптографических сокращений. Используйте произносимые имена, которые легко искать. Например:

  • Плохо: d (время в днях)
  • Хорошо: elapsedTimeInDays

Будьте последовательны и точны. Используйте последовательные соглашения о наименованиях по всему коду. Будьте точны, чтобы избежать двусмысленности - например, используйте значимые различия, такие как getActiveAccounts() и getActiveAccountInfo(). Избегайте кодировок или префиксов, которые добавляют шум без ценности. Имена классов должны быть существительными, имена методов - глаголами.

Длина имени должна соответствовать области видимости. Используйте более длинные, описательные имена для переменных и функций с большой областью видимости. Короткие имена допустимы для небольших, локальных областей. Длина имени должна быть пропорциональна его области использования. Оптимизируйте для читаемости и понимания в контексте, где используется имя.

3. Держите функции маленькими и сфокусированными

Функции должны делать одно дело. Они должны делать это хорошо. Они должны делать только это.

Маленькое - это красиво. Функции должны быть маленькими - обычно 5-10 строк. Они должны помещаться на один экран и быть мгновенно понятными. Выносите код в хорошо названные вспомогательные функции, а не пишите длинные, сложные функции. Маленькие функции легче понять, тестировать и поддерживать.

Делайте одно дело хорошо. Каждая функция должна иметь одну, четкую цель. Если функция делает несколько вещей, вынесите их в отдельные функции. Признаки того, что функция делает слишком много, включают:

  • Несколько уровней абстракции
  • Несколько секций или блоков кода
  • Многочисленные параметры

Поддерживайте один уровень абстракции. Операторы внутри функции должны быть на одном уровне абстракции. Не смешивайте высокоуровневую логику с низкоуровневыми деталями. Выносите низкоуровневые операции в отдельные функции. Это улучшает читаемость, удерживая функции сфокусированными и концептуально простыми.

4. Практикуйте правильное форматирование и организацию

Форматирование кода - это о коммуникации, а коммуникация - это первоочередная задача профессионального разработчика.

Последовательное форматирование имеет значение. Используйте последовательные отступы, разрывы строк и пробелы по всему коду. Это улучшает читаемость и снижает когнитивную нагрузку. Согласуйте стандарты форматирования с вашей командой и используйте автоматические инструменты для их соблюдения. Основные рекомендации по форматированию включают:

  • Правильные отступы
  • Последовательное размещение скобок
  • Логические разрывы строк
  • Соответствующие пробелы

Организуйте код логически. Группируйте связанный код вместе и разделяйте несвязанный код. Используйте пустые строки для создания "абзацев" между логическими секциями. Размещайте связанные функции рядом друг с другом. Держите файлы сфокусированными на одной концепции или компоненте. Разбивайте большие файлы на меньшие, более сфокусированные, когда это уместно.

Следуйте стандартным соглашениям. Соблюдайте стандартные соглашения для вашего языка и сообщества. Это делает ваш код более знакомым и доступным для других разработчиков. Например, в Java:

  • Имена классов используют PascalCase
  • Имена методов используют camelCase
  • Константы используют ALL_CAPS

5. Управляйте зависимостями и избегайте дублирования

Дублирование может быть корнем всех зол в программном обеспечении.

Устраняйте дублирование. Дублированный код - это упущенная возможность для абстракции. Когда вы видите дублирование, выносите общий код в переиспользуемую функцию или класс. Это улучшает поддерживаемость, централизуя логику и снижая риск несогласованных изменений. Типы дублирования, на которые следует обращать внимание:

  • Идентичные блоки кода
  • Похожие алгоритмы с небольшими вариациями
  • Повторяющиеся цепочки switch/case или if/else

Управляйте зависимостями осторожно. Минимизируйте зависимости между модулями, чтобы уменьшить связность. Используйте внедрение зависимостей и инверсию управления, чтобы сделать код более модульным и тестируемым. Следуйте принципу инверсии зависимостей - зависеть от абстракций, а не от конкретных реализаций. Это делает ваш код более гибким и легким для изменения.

Используйте принцип наименьшего знания. Модуль не должен знать о внутренностях объектов, с которыми он работает. Это уменьшает связность между модулями. Например, используйте Закон Деметры - метод должен вызывать методы только на:

  • Своем собственном объекте
  • Объектах, переданных в качестве параметров
  • Объектах, которые он создает
  • Своих прямых компонентах

6. Обрабатывайте ошибки аккуратно

Обработка ошибок важна, но если она затеняет логику, это неправильно.

Используйте исключения вместо кодов ошибок. Исключения чище и не загромождают основную логику вашего кода. Они позволяют отделить обработку ошибок от основной логики. При использовании исключений:

  • Создавайте информативные сообщения об ошибках
  • Предоставляйте контекст с исключениями
  • Определяйте классы исключений на основе потребностей вызывающего кода

Не возвращайте null. Возврат null приводит к исключениям null pointer и загромождает код проверками на null. Вместо этого:

  • Возвращайте пустые коллекции вместо null для списков
  • Используйте паттерн Null Object
  • Используйте Optional в Java или Maybe в функциональных языках

Пишите try-catch-finally сначала. Начинайте с try-catch-finally при написании кода, который может выбросить исключения. Это помогает определить область и ожидания для вызывающего кода. Это гарантирует, что ресурсы правильно управляются и освобождаются, даже в сценариях ошибок.

7. Пишите тщательные модульные тесты

Тестовый код так же важен, как и производственный код.

Следуйте трем законам TDD. Разработка через тестирование (TDD) улучшает качество и дизайн кода:

  1. Напишите неудачный тест перед написанием любого производственного кода
  2. Напишите только столько теста, чтобы продемонстрировать неудачу
  3. Напишите только столько производственного кода, чтобы пройти тест

Держите тесты чистыми и поддерживаемыми. Применяйте те же стандарты качества кода к вашим тестам, что и к производственному коду. Регулярно рефакторите и улучшайте тестовый код. Хорошо структурированные тесты служат документацией и позволяют без страха рефакторить производственный код.

Стремитесь к всестороннему покрытию тестами. Пишите тесты, которые охватывают крайние случаи, граничные условия и сценарии ошибок - не только счастливый путь. Используйте инструменты покрытия кода, чтобы выявить пробелы в покрытии тестами. Помните, что 100% покрытие не гарантирует отсутствие ошибок, но оно дает уверенность в рефакторинге и изменениях.

8. Постоянно рефакторите код

Оставляйте лагерь чище, чем вы его нашли.

Рефакторите оппортунистически. Улучшайте структуру кода всякий раз, когда работаете с ним. Следуйте правилу бойскаутов: оставляйте код лучше, чем вы его нашли. Маленькие, постепенные улучшения накапливаются со временем и предотвращают гниение кода. Общие техники рефакторинга включают:

  • Выделение методов или классов
  • Переименование для ясности
  • Упрощение сложных условий
  • Удаление дублирования

Рефакторите безопасно с тестами. Всегда имейте надежный набор тестов перед рефакторингом. Делайте маленькие, постепенные изменения и часто запускайте тесты. Это дает уверенность, что ваши изменения не ломают существующую функциональность. Используйте автоматические инструменты рефакторинга, когда это возможно, чтобы снизить риск внесения ошибок.

Балансируйте рефакторинг с доставкой ценности. Хотя постоянный рефакторинг важен, не позволяйте ему парализовать прогресс. Стремитесь к "достаточно хорошему", а не к совершенству. Сосредоточьтесь на рефакторинге самых проблемных или часто изменяемых областей кода. Объясняйте ценность рефакторинга заинтересованным сторонам, чтобы обеспечить поддержку для постоянного улучшения кода.

9. Применяйте принципы объектно-ориентированного и функционального программирования

Объекты скрывают свои данные за абстракциями и предоставляют функции, которые работают с этими данными. Структуры данных раскрывают свои данные и не имеют значимых функций.

Используйте принципы объектно-ориентированного программирования с умом. Применяйте принципы, такие как инкапсуляция, наследование и полиморфизм, чтобы создавать гибкие, модульные дизайны. Следуйте принципам SOLID:

  • Принцип единственной ответственности
  • Принцип открытости/закрытости
  • Принцип подстановки Лисков
  • Принцип разделения интерфейсов
  • Принцип инверсии зависимостей

Используйте концепции функционального программирования. Даже в объектно-ориентированных языках техники функционального программирования могут привести к более чистому коду:

  • Чистые функции без побочных эффектов
  • Неизменяемые данные
  • Функции высшего порядка
  • Композиция функций

Выбирайте правильный подход для задачи. Объектно-ориентированные и функциональные парадигмы имеют свои сильные и слабые стороны. Используйте объектно-ориентированный дизайн, когда нужно моделировать сложные домены с поведением. Используйте функциональные подходы для преобразования данных и обработки потоков. Многие современные языки поддерживают гибридный подход, позволяя использовать лучший инструмент для каждой части системы.

10. Внимательно рассматривайте вопросы параллелизма

Параллелизм - это стратегия разъединения. Он помогает нам разъединить то, что делается, от того, когда это делается.

Понимайте проблемы параллелизма. Параллельное программирование вводит сложность и потенциальные тонкие ошибки. Общие проблемы включают:

  • Гонки условий
  • Взаимные блокировки
  • Пропущенные сигналы
  • Проблемы видимости памяти

Разделяйте проблемы параллелизма. Держите ваш код, связанный с параллелизмом, отдельно от остального кода. Это делает его легче для понимания и тестирования. Используйте абстракции, такие как Executors, Futures и Actors, для управления параллелизмом, а не работайте с сырыми потоками.

Предпочитайте неизменяемость и чистые функции. Неизменяемые объекты и чистые функции по своей природе потокобезопасны. Они устраняют многие проблемы параллелизма, избегая общего изменяемого состояния. Когда изменяемое состояние необходимо, используйте правильные техники синхронизации и рассмотрите использование атомарных переменных или конкурентных коллекций.

Последнее обновление:

FAQ

What's "Clean Code: A Handbook of Agile Software Craftsmanship" about?

  • Focus on Clean Code: "Clean Code" by Robert C. Martin emphasizes writing code that is easy to read, understand, and maintain.
  • Professionalism in Coding: It argues that clean code is a hallmark of professionalism in software development.
  • Practical Advice: The book provides guidelines, examples, and case studies to help developers write clean and efficient code.

Why should I read "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • Improve Coding Skills: It teaches how to write code that is clean, efficient, and maintainable.
  • Learn from Experts: Part of the Robert C. Martin series, known for its technical and pragmatic approach.
  • Long-term Benefits: Writing clean code reduces maintenance costs and makes you a more valuable developer.

What are the key takeaways of "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • Code Readability: Emphasizes that code should be easy to read and understand.
  • Single Responsibility Principle: Advocates for each class or function to have one reason to change.
  • Continuous Improvement: Encourages developers to continuously improve their code, following the Boy Scout Rule.

How does "Clean Code: A Handbook of Agile Software Craftsmanship" define clean code?

  • Elegance and Efficiency: Clean code is described as elegant and efficient, with minimal dependencies.
  • Readable and Maintainable: It should read like well-written prose, making the designer's intent clear.
  • Focused and Single-minded: Each function, class, and module should have a single, clear purpose.

What is the Single Responsibility Principle in "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • One Reason to Change: A class or module should have one, and only one, reason to change.
  • Improves Cohesion: Ensures that classes are cohesive, with closely related methods and variables.
  • Facilitates Maintenance: Makes the code easier to maintain and extend, reducing the impact of changes.

What is the "Boy Scout Rule" mentioned in "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • Continuous Improvement: Suggests leaving the codebase cleaner than you found it.
  • Small, Incremental Changes: Encourages making small improvements, like renaming variables or breaking up functions.
  • Professional Responsibility: Presented as a professional responsibility to ensure maintainability.

How does "Clean Code: A Handbook of Agile Software Craftsmanship" approach Test-Driven Development (TDD)?

  • Fundamental Discipline: TDD is crucial for writing clean, reliable code.
  • Three Laws of TDD: Write a failing test first, write code to pass the test, then refactor.
  • Benefits: Helps catch bugs early and improves code design.

What are "code smells" according to "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • Definition: Indicators of potential problems that hinder readability or maintainability.
  • Examples: Long methods, large classes, and duplicated code.
  • Addressing Smells: Provides heuristics and refactoring techniques to improve code quality.

How does "Clean Code: A Handbook of Agile Software Craftsmanship" suggest handling exceptions?

  • Prefer Exceptions: Use exceptions instead of error codes for better context and management.
  • Provide Context: Include meaningful messages and context when throwing exceptions.
  • Avoid Checked Exceptions: Suggests using unchecked exceptions for cleaner code.

What role do unit tests play in "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • Ensure Code Quality: Unit tests ensure code works as intended and remains maintainable.
  • Test-Driven Development: Advocates writing tests before production code.
  • Clean and Readable Tests: Tests should be as clean and readable as production code.

What is the role of refactoring in "Clean Code: A Handbook of Agile Software Craftsmanship"?

  • Continuous Improvement: Refactoring improves code structure and readability without changing functionality.
  • Techniques: Provides techniques like Extract Method and Rename Variable to enhance code quality.
  • Fearless Refactoring: With comprehensive tests, developers can refactor confidently.

What are the best quotes from "Clean Code: A Handbook of Agile Software Craftsmanship" and what do they mean?

  • "Clean code does one thing well." Emphasizes focus and clarity in code.
  • "Leave the campground cleaner than you found it." Encourages continuous improvement of the codebase.
  • "You know you are working on clean code when each routine you read turns out to be pretty much what you expected." Highlights the importance of readability and predictability.

Отзывы

4.37 из 5
Средняя оценка на основе 22k+ оценки с Goodreads и Amazon.

Чистый код получает в основном положительные отзывы за свои принципы написания читаемого и поддерживаемого кода. Читатели ценят практические советы по именованию, функциям и тестированию. Основные критические замечания касаются акцента на Java и некоторых чрезмерно строгих рекомендаций. Многие считают эту книгу обязательной для чтения разработчиками, хотя некоторые находят её менее полезной для опытных программистов. Примеры из практики и примеры рефакторинга хвалят одни, но критикуют другие за излишнюю детализацию. В целом, рецензенты сходятся во мнении, что книга предлагает ценные идеи по качеству кода, даже если не все предложения универсально применимы.

Об авторе

Роберт Сесил Мартин, известный как Дядя Боб, является признанным инженером-программистом и консультантом. Он выступает за методы Agile-разработки и является президентом компании Object Mentor Inc. Экспертиза Мартина охватывает Объектно-Ориентированное Проектирование, Паттерны, UML и eXtreme Programming. Он работал с клиентами по всему миру, делясь своими знаниями через консультации и выступления. Мартин был главным редактором журнала C++ Report с 1996 по 1999 год. Он является видной фигурой в сообществе разработчиков программного обеспечения, часто выступая на международных конференциях и выставках. Его влияние выходит за рамки консультационной работы благодаря его книгам и статьям о мастерстве программирования и лучших практиках.

Other books by Robert C. Martin

0:00
-0:00
1x
Dan
Andrew
Michelle
Lauren
Select Speed
1.0×
+
200 words per minute
Create a free account to unlock:
Requests: Request new book summaries
Bookmarks: Save your favorite books
History: Revisit books later
Ratings: Rate books & see your ratings
Try Full Access for 7 Days
Listen, bookmark, and more
Compare Features Free Pro
📖 Read Summaries
All summaries are free to read in 40 languages
🎧 Listen to Summaries
Listen to unlimited summaries in 40 languages
❤️ Unlimited Bookmarks
Free users are limited to 10
📜 Unlimited History
Free users are limited to 10
Risk-Free Timeline
Today: Get Instant Access
Listen to full summaries of 73,530 books. That's 12,000+ hours of audio!
Day 4: Trial Reminder
We'll send you a notification that your trial is ending soon.
Day 7: Your subscription begins
You'll be charged on Feb 28,
cancel anytime before.
Consume 2.8x More Books
2.8x more books Listening Reading
Our users love us
50,000+ readers
"...I can 10x the number of books I can read..."
"...exceptionally accurate, engaging, and beautifully presented..."
"...better than any amazon review when I'm making a book-buying decision..."
Save 62%
Yearly
$119.88 $44.99/year
$3.75/mo
Monthly
$9.99/mo
Try Free & Unlock
7 days free, then $44.99/year. Cancel anytime.
Settings
Appearance
Black Friday Sale 🎉
$20 off Lifetime Access
$79.99 $59.99
Upgrade Now →