Итак, давайте без лишних слов рассмотрим лучшие советы, которые предлагает нам книга Clean Code! Мы пройдемся по каждой главе, суммируя идеи, которые предлагает дядя Боб и его соавторы.
Глава 1: Чистый код
Общее количество беспорядка со временем увеличивается.
Восстановить устаревшую систему с нуля очень сложно. Рефакторинг и постепенные улучшения станут лучшим для этого вариантом.
В запутанной кодовой базе на выполнение задач, которые должны занимать всего несколько часов, могут уйти дни или недели.
Найдите время, чтобы действовать быстро.
Чистый код хорошо справляется с одной задачей. Плохой код пытается сделать слишком много.
Чистый код хорошо протестирован.
При чтении хорошо написанного кода каждая функция делает примерно то, что вы ожидали.
Если вы не согласны с принципом, который преподает кто-то с многолетним опытом, вам следует хотя бы рассмотреть его точку зрения, прежде чем игнорировать ее.
Код читают гораздо чаще, чем пишут.
Код, который легче читать, легче изменить.
Оставьте кодовую базу в лучшем виде, чем когда вы ее нашли (Правило бойскаута).
Глава 2: Значение имен
Тщательно выбирайте имена переменных.
Выбирать хорошие имена сложно.
Имя переменной или функции должно указывать на то, что это такое и как используется.
Избегайте использования односимвольных имен переменных, за исключением часто используемых имен, например, i для переменной счетчика в цикле.
Избегайте использовать сокращение в именах переменных.
Имена переменных должны быть произносимыми, чтобы вы могли говорить о них и произносить их вслух.
Используйте имена переменных, которые легко найти.
Классы и объекты должны иметь имена в виде существительных.
Имена методов и функций должны быть глаголами или парами глагол-существительное.
Глава 3: Функции
Функции должны быть небольшими.
Функция должна выполнять одно действие.
Функции должны иметь описательные имена.
Извлеките код в теле if / else или переключите операторы в четко названные функции.
Ограничьте количество аргументов, которые принимает функция.
Если функции требуется много аргументов конфигурации, рассмотрите возможность объединения их в одну переменную параметров конфигурации.
Функции должны быть чистыми, что означает, что они не имеют побочных эффектов и не изменяют свои входные аргументы.
Функция должна быть командой или запросом, но не тем и другим сразу (Command Query Separation — Разделение запросов команд).
Лучше удалить из кода ошибки и исключения, чем оставить ошибки в коде.
Извлеките дублированный код в четко названные функции (Don't Repeat Yourself).
Модульные тесты упрощают рефакторинг.
Глава 4: Комментарии
Комментарии могут быть неверными. Они могут быть неправильными с самого начала или могут быть изначально точными, а затем со временем устареть по мере изменения кода.
Используйте комментарии, чтобы описать, почему это написано так, как оно есть, а не объяснять, что происходит.
Комментариев часто можно избежать, используя четко названные переменные и извлекая разделы кода в четко названные функции.
Добавляйте к комментариям TODO единообразные префиксы, чтобы упростить их поиск. Периодически просматривайте и очищайте свои TODO-комментарии.
Не используйте Javadocs только ради их использования. Комментарии, описывающие, что делает метод, какие аргументы он принимает и что возвращает, в лучшем случае избыточны, а в худшем — вводят в заблуждение.
Комментарии должны включать всю соответствующую информацию и контекст, который понадобится читателю. Не ленитесь, когда пишете комментарий.
Комментарии журнала и комментарии автора файла не нужны из-за контроля версий и git blame.
Не комментируйте мертвый код. Просто удалите его. Если вы думаете, что код вам понадобится в будущем, то для этого и нужен контроль версий.
Глава 5: Форматирование
В команде выберите набор правил для форматирования кода, а затем последовательно применяйте эти правила. Неважно, с какими правилами вы согласны, вам нужно прийти к соглашению.
Используйте автоматическое форматирование кода и анализатор кода. Не полагайтесь на то, что люди вручную найдут и исправят каждую ошибку форматирования. Это неэффективно, непродуктивно и пустая трата времени при проверке кода.
Добавьте вертикальные пробелы между строками кода, чтобы визуально разделить связанные блоки кода. Все, что вам нужно — это сделать одну новую строку между группами.
Небольшие файлы легче читать, понимать и перемещать, чем крупные файлы.
Переменные следует объявлять рядом с тем, где они используются. Для небольших функций это обычно вверху функции.
Даже для коротких функций или операторов if все равно форматируйте их правильно, а не записывайте в одной строке.
Глава 6: Объекты и структуры данных
Детали реализации в объекте должны быть скрыты за интерфейсом объекта. Предоставляя интерфейс для использования потребителями объекта, вы упрощаете последующий рефакторинг деталей реализации, не вызывая критических изменений. Абстракции упрощают рефакторинг.
Любой данный фрагмент кода не должен знать о внутреннем устройстве объекта, с которым он работает.
При работе с объектом вы должны требовать от него выполнения команды или запроса, а не спрашивать его о его внутреннем устройстве.
Глава 7: Исправление ошибок
Обработка ошибок не должна мешать остальному коду в модуле.
Лучше удалить из кода ошибки и исключения, чем оставить ошибки в коде.
Напишите тесты с ошибками, чтобы убедиться, что ваш код идентифицирует их, а не пропускает.
Сообщения об ошибках должны быть информативными, со всем необходимым контекстом, который может понадобиться кому-то для эффективного устранения неполадок.
Обертывание сторонних API-интерфейсов тонким слоем абстракции упрощает замену одной библиотеки на другую в будущем.
Обертывание сторонних API-интерфейсов тонким слоем абстракции упрощает имитацию библиотеки во время тестирования.
Используйте шаблон Special Case или шаблон Null Object для обработки исключительного поведения, например, когда определенные данные не существуют.
Глава 8: Границы
Сторонние библиотеки помогают ускорить доставку продукта, позволяя передать на аутсорсинг различные задачи.
Напишите тесты, чтобы убедиться, что вы правильно используете стороннюю библиотеку.
Используйте шаблон адаптера, чтобы преодолеть разрыв между API сторонней библиотеки и API, который вы хотели бы иметь.
Обертывание сторонних API-интерфейсов тонким слоем абстракции упрощает замену одной библиотеки на другую в будущем. (Повторяется из главы 7)
Обертывание сторонних API-интерфейсов тонким слоем абстракции упрощает имитацию библиотеки во время тестирования. (Повторяется из главы 7)
Старайтесь не сообщать вашему приложению слишком много информации о деталях какой-либо сторонней библиотеки.
Лучше зависеть от того, что вы контролируете, чем от того, что вы не контролируете.
Глава 9: Модульные тесты
Тестовый код должен быть таким же чистым, как и производственный код (за некоторыми исключениями, обычно связанными с памятью или эффективностью).
По мере изменения производственного кода изменяется и тестовый код.
Тесты помогают сохранить ваш производственный код гибким и поддерживаемым.
Тесты позволяют вносить изменения, позволяя вам уверенно выполнять рефакторинг, не опасаясь, что вы сами этого не заметите.
Структурируйте свои тесты с помощью шаблона Arrange-Act-Assert (также известного как Build-Operate-Check, Setup-Exercise-Verify или Given-When-Then).
Используйте зависящие от предметной области функции, чтобы упростить написание и чтение тестов.
Оцените одну концепцию за тест.
Тесты должны быть быстрыми.
Тесты должны быть независимыми.
Тесты должны быть повторяемыми.
Тесты не должны требовать подтверждений.
Тесты должны быть написаны своевременно, незадолго до или после написания производственного кода, а не через несколько месяцев.
Если ваши тесты будут неправильными, ожидайте, что в вашем коде будут ошибки.
Глава 10: Классы
Классы должны быть небольшими.
Классы должны отвечать только за одну вещь и должны иметь только одну причину для изменения (принцип единой ответственности).
Если вы не можете придумать четкое название для класса, вероятно, он слишком велик.
Ваша работа не заканчивается на том, что вы заставите часть кода работать. Следующим шагом станет рефакторинг и очистка кода.
Использование множества небольших классов вместо нескольких больших классов в вашем приложении сокращает объем информации, которую разработчик должен понимать при работе над любой заданной задачей.
Наличие хорошего набора тестов позволяет с уверенностью выполнять рефакторинг, когда вы разбиваете большие классы на более мелкие.
Классы должны быть открыты для расширения, но закрыты для модификации (принцип открытости-закрытости).
Интерфейсы и абстрактные классы создают стыки (seams), которые упрощают тестирование.
Глава 11: Системы
Используйте внедрение зависимостей, чтобы дать разработчикам гибкость для передачи любого объекта с соответствующим интерфейсом в другой класс.
Используйте внедрение зависимостей для создания стыков объектов в приложении, чтобы упростить тестирование.
Программные системы не похожи на здание, которое нужно проектировать заранее. Они больше похожи на города, которые со временем растут и расширяются, адаптируясь к текущим потребностям.
Отложите принятие решения до последнего ответственного момента.
Используйте предметно-ориентированный язык, чтобы эксперты и разработчики в предметной области использовали одну и ту же терминологию.
Не усложняйте свою систему слишком сильно. Используйте самое простое, что работает.
Глава 12: Развертывание
Системы, которые нельзя тестировать, нельзя проверить, а системы, которые нельзя проверить, никогда не следует развертывать.
Написание тестов приводит к лучшему дизайну, потому что код, который легко тестировать, часто использует внедрение зависимостей, интерфейсы и абстракцию.
Хороший набор тестов избавит вас от страха сломать приложение во время рефакторинга.
Дублирование кода создает больший риск, поскольку в коде есть больше мест, которые можно изменить, и еще больше мест, где ошибки могут быть скрыты.
Код, который вы пишете сейчас, легче понять, потому что вы глубоко вовлечены в его понимание. Другим непросто быстро достичь такого же уровня понимания.
Большая часть стоимости программного проекта связана с долгосрочным обслуживанием.
Тесты служат живой документацией того, как ваше приложение должно (и ведет себя) вести себя.
Не двигайтесь дальше, как только ваш код заработает. Найдите время, чтобы сделать его более понятным и понятным.
Следующим, кто прочитает ваш код в ближайшем будущем, скорее всего, будете вы. Будьте добры к себе в будущем, написав простой для понимания код.
Сопротивляйтесь догмам. Примите прагматизм.
Чтобы стать действительно хорошим специалистом в области разработки программного обеспечения, требуются десятилетия. Вы можете ускорить процесс обучения, изучая опыт окружающих вас экспертов и изучая часто используемые шаблоны проектирования.
Глава 13: Параллелизм
Писать параллельный код сложно.
Случайные ошибки и проблемы, которые трудно воспроизвести, часто являются проблемами параллелизма.
Тестирование не гарантирует отсутствие ошибок в вашем приложении, но минимизирует риск.
Узнайте об общих проблемах параллелизма и их возможных решениях.
Глава 14: Последовательное уточнение
Чистый код обычно не начинается с чистого листа. Сначала вы пишете черновое решение, а затем реорганизуете его, чтобы сделать его более чистым.
Ошибочно прекращать работу над кодом, когда он “заработал”. Найдите время, чтобы сделать его еще лучше после того, как он уже работает.
Беспорядки нарастают постепенно.
Если вы оказались в затруднительном положении, когда добавление функций слишком сложно или занимает слишком много времени, прекратите писать функции и начните рефакторинг.
Постепенные изменения часто лучше, чем восстановление с нуля.
Используйте разработку через тестирование (Test-Driven Development — TDD), чтобы внести большое количество очень мелких изменений.
Хороший дизайн программного обеспечения предполагает разделение проблем в вашем коде и разделение кода на более мелкие модули, классы и файлы.
Легче убрать беспорядок сразу после того, как вы его создали, чем убирать позже.
Глава 15: Внутреннее устройство JUnit
Отрицательные имена переменных или условные выражения немного труднее понять, чем положительные.
Рефакторинг — это итеративный процесс, полный проб и ошибок.
Оставьте кодовую базу в лучшем виде, чем когда вы ее нашли (Правило бойскаута). (Повторяется из главы 1)
Глава 16: Рефакторинг SerialDate
Проверки кода и критика нашего кода делают нас лучше, и мы должны приветствовать это.
Сначала заставьте код работать, затем исправьте.
Не каждую строчку кода требуется тестирование.
Глава 17: Запахи и эвристика
Чистый код — это не набор правил, а скорее система ценностей, определяющих качество вашей работы.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ