- Артикул:00-01098225
- Автор: Мартин Р.
- ISBN: 978-5-4461-0960-9
- Тираж: 7000 экз.
- Обложка: Мягкая обложка
- Издательство: Питер (все книги издательства)
- Город: Санкт-Петербург
- Страниц: 464
- Формат: 70х100/16(~168x240 мм)
- Год: 2024
- Вес: 1160 г
Развернуть ▼
Плохой код может работать, но он будет мешать развитию проекта и компании-разработчика, требуя дополнительные ресурсы на поддержку и «укрощение».
Каким же должен быть код? Эта книга полна реальных примеров, позволяющих взглянуть на код с различных направлений: сверху вниз, снизу вверх и даже изнутри. Вы узнаете много нового о коде. Более того, научитесь отличать хороший код от плохого, узнаете, как писать хороший код и как преобразовать плохой код в хороший.
Книга состоит из трех частей. Сначала вы познакомитесь с принципами, паттернами и приемами написания чистого кода. Затем приступите к практическим сценариям с нарастающей сложностью - упражнениям по чистке кода или преобразованию проблемного кода в менее проблемный. И только после этого перейдете к самому важному - концентрированному выражению сути этой книги - набору эвристических правил и «запахов кода». Именно эта база знаний описывает путь мышления в процессе чтения, написания и чистки кода.
Содержание
Предисловие
Введение
Глава 1. Чистый код
Да будет код
Плохой код
Расплата за хаос
Грандиозная переработка
Отношение
Основной парадокс
Искусство чистого кода?
Что такое "чистый код"?
Мы - авторы
Правило бойскаута
Предыстория и принципы
Заключение
Литература
Глава 2. Содержательные имена (Тим Оттингер)
Имена должны передавать намерения программиста
Избегайте дезинформации
Используйте осмысленные различия
Используйте удобопроизносимые имена
Выбирайте имена, удобные для поиска
Избегайте схем кодирования имен
Венгерская запись
Префиксы членов классов
Интерфейсы и реализации
Избегайте мысленных преобразований
Имена классов
Имена методов
Избегайте остроумия
Выберите одно слово для каждой концепции
Воздержитесь от каламбуров
Используйте имена из пространства решения
Используйте имена из пространства задачи
Добавьте содержательный контекст
Не добавляйте избыточный контекст
Несколько слов напоследок
Глава 3. Функции
Компактность!
Блоки и отступы
Правило одной операции
Секции в функциях
Один уровень абстракции на функцию
Чтение кода сверху вниз: правило понижения
Команды switch
Используйте содержательные имена
Аргументы функций
Стандартные унарные формы
Аргументы-флаги
Бинарные функции
Тернарные функции
Объекты как аргументы
Списки аргументов
Глаголы и ключевые слова
Избавьтесь от побочных эффектов
Выходные аргументы
Разделение команд и запросов
Используйте исключения вместо возвращения кодов ошибок .
Изолируйте блоки try /catch
Обработка ошибок как одна операция
Магнит зависимостей Error.java
Не повторяйтесь
Структурное программирование
Как научиться писать такие функции?
Завершение
Литература
Глава 4. Комментарии
Комментарии не компенсируют плохого кода
Объясните свои намерения в коде
Хорошие комментарии
Юридические комментарии
Информативные комментарии
Представление намерений
Прояснение
Предупреждения о последствиях
Комментарии TODO
Усиление
Комментарии Javadoc в общедоступных API
Плохие комментарии
Бормотание
Избыточные комментарии
Недостоверные комментарии
Обязательные комментарии
Журнальные комментарии
Шум
Опасный шум
Не используйте комментарии там, где можно использовать функцию или переменную
Позиционные маркеры
Комментарии за закрывающей фигурной скобкой
Ссылки на авторов
Закомментированный код
Комментарии HTML
Нелокальная информация
Слишком много информации
Неочевидные комментарии
Заголовки функций
Заголовки Javadoc во внутреннем коде
Пример
Литература
Глава 5. Форматирование
Цель форматирования
Вертикальное форматирование
Газетная метафора
Вертикальное разделение концепций
Вертикальное сжатие
Вертикальные расстояния
Вертикальное упорядочение
Горизонтальное форматирование
Горизонтальное разделение и сжатие
Горизонтальное выравнивание
Отступы
Вырожденные области видимости
Правила форматирования в группах
Правила форматирования от дядюшки Боба
Глава 6. Объекты и структуры данных
Абстракция данных
Антисимметрия данных/объектов
Закон Деметры
Крушение поезда
Гибриды
Скрытие структуры
Объекты передачи данных
Активные записи
Заключение
Литература
Глава 7. Обработка ошибок (Майк Физерс)
Используйте исключения вместо кодов ошибок
Начните с написания команды try-catch-finally
Обязательные комментарии
Журнальные комментарии
Шум
Опасный шум
Не используйте комментарии там, где можно использовать функцию
или переменную
Позиционные маркеры
Комментарии за закрывающей фигурной скобкой
Ссылки на авторов
Закомментированный код
Комментарии HTML
Нелокальная информация
Слишком много информации
Неочевидные комментарии
Заголовки функций
Заголовки Javadoc во внутреннем коде
Пример
Литература
Глава 5. Форматирование
Цель форматирования
Вертикальное форматирование
Газетная метафора
Вертикальное разделение концепций
Вертикальное сжатие
Вертикальные расстояния
Вертикальное упорядочение
Горизонтальное форматирование
Горизонтальное разделение и сжатие
Горизонтальное выравнивание
Отступы
Вырожденные области видимости
Правила форматирования в группах
Правила форматирования от дядюшки Боба
Глава 6. Объекты и структуры данных
Абстракция данных
Антисимметрия данных/объектов
Закон Деметры
Крушение поезда
Гибриды
Скрытие структуры
Объекты передачи данных
Активные записи
Заключение
Литература
Глава 7. Обработка ошибок (Майк Физерс)
Используйте исключения вместо кодов ошибок
Начните с написания команды try-catch-finally
Используйте непроверяемые исключения
Передавайте контекст с исключениями
Определяйте классы исключений в контексте потребностей вызывающей стороны
Определите нормальный путь выполнения
Не возвращайте null
Не передавайте null
Заключение
Литература
Глава 8. Границы (Джеймс Гренинг)
Использование стороннего кода
Исследование и анализ границ
Изучение log4j
Учебные тесты: выгоднее, чем бесплатно
Использование несуществующего кода
Чистые границы
Литература
Глава 9. Модульные тесты
Три закона TDD
О чистоте тестов
Тесты как средство обеспечения изменений
Чистые тесты
Предметно-ориентированный язык тестирования
Двойной стандарт
Одна проверка на тест
Одна концепция на тест
F.I.R.S.T
Заключение
Литература
Глава 10. Классы (совместно с Джеффом Лангром)
Строение класса
Инкапсуляция
Классы должны быть компактными!
Принцип единой ответственности (SRP)
Связность
Поддержание связности приводит к уменьшению классов
Структурирование с учетом изменений
Изоляция изменений
Литература
Глава 11. Системы (Кевин Дин Уомплер)
Как бы вы строили город?
Отделение конструирования системы от ее использования
Отделение main
Фабрики
Внедрение зависимостей
Масштабирование
Поперечные области ответственности
Посредники
АОП-инфраструктуры на "чистом " Java
Аспекты AspectJ
Испытание системной архитектуры
Оптимизация принятия решений
Применяйте стандарты разумно, когда они приносят очевидную пользу
Системам необходимы предметно-ориентированные языки
Заключение
Литература
Глава 12. Формирование архитектуры
Четыре правила
Правило № 1: выполнение всех тестов
Правила № 2-4: переработка кода
Отсутствие дублирования
Выразительность
Минимум классов и методов
Заключение
Литература
Глава 13. Многопоточность (Бретт Л. Шухерт)
Зачем нужна многопоточность?
Мифы и неверные представления
Трудности
Защита от ошибок многопоточности
Принцип единой ответственности
Следствие: ограничивайте область видимости данных
Следствие: используйте копии данных
Следствие: потоки должны быть как можно более независимы
Знайте свою библиотеку
Потоково-безопасные коллекции
Знайте модели выполнения
Модель "производители-потребители"
Модель "читатели-писатели "
Модель "обедающих философов "
Остерегайтесь зависимостей между синхронизированными методами
Синхронизированные секции должны иметь минимальный размер
О трудности корректного завершения
Тестирование многопоточного кода
Рассматривайте непериодические сбои как признаки возможных проблем многопоточности
Начните с отладки основного кода, не связанного с многопоточностью
Реализуйте переключение конфигураций многопоточного кода
Обеспечьте логическую изоляцию конфигураций многопоточного кода
Протестируйте программу с количеством потоков, превышающим
количество процессоров
Протестируйте программу на разных платформах
Применяйте инструментовку кода для повышения вероятности сбоев
Ручная инструментовка
Автоматизированная инструментовка
Заключение
Литература
Глава 14. Последовательное очищение
Реализация Args
Как я это сделал?
Args: черновик
На этом я остановился
О постепенном усовершенствовании
Аргументы String
Заключение
Глава 15. Внутреннее строение JUnit
Инфраструктура JUnit
Заключение
Глава 16. Переработка SerialDate
Прежде всего - заставить работать
...Потом очистить код
Заключение
Литература
Глава 17. Запахи и эвристические правила
Комментарии
С1: Неуместная информация
С2: Устаревший комментарий
СЗ: Избыточный комментарий
С4: Плохо написанный комментарий
С5: Закомментированный код
Рабочая среда
Е1: Построение состоит из нескольких этапов
Е2: Тестирование состоит из нескольких этапов
Функции
F1: Слишком много аргументов
F2: Выходные аргументы
F3: Флаги в аргументах
F4: Мертвые функции
Разное
G1: Несколько языков в одном исходном файле
G2: Очевидное поведение не реализовано
G3: Некорректное граничное поведение
G4: Отключенные средства безопасности
G5: Дублирование
G6: Код на неверном уровне абстракции
G7: Базовые классы, зависящие от производных
G8: Слишком много информации
G9: Мертвый код
G10: Вертикальное разделение
G11: Непоследовательность
G12: Балласт
G13: Искусственные привязки
G14: Функциональная зависть
G15: Аргументы-селекторы
G16: Непонятные намерения
G17: Неверное размещение
G18: Неуместные статические методы
G19: Используйте пояснительные переменные
G20: Имена функций должны описывать выполняемую операцию
G21: Понимание алгоритма
G22: Преобразование логических зависимостей в физические
G23: Используйте полиморфизм вместо if/Else или switch/Case
G24: Соблюдайте стандартные конвенции
G25: Заменяйте «волшебные числа» именованными константами
G26: Будьте точны
G27: Структура важнее конвенций
G28: Инкапсулируйте условные конструкции
G29: Избегайте отрицательных условий
G30: Функции должны выполнять одну операцию
G31: Скрытые временные привязки
G32: Структура кода должна быть обоснована
G33: Инкапсулируйте граничные условия
G34: Функции должны быть написаны на одном уровне абстракции
G35: Храните конфигурационные данные на высоких уровнях
G36: Избегайте транзитивных обращений
Java
J1: Используйте обобщенные директивы импорта
J2: Не наследуйте от констант
J3: Константы против перечислений
Имена
N1: Используйте содержательные имена
N2: Выбирайте имена на подходящем уровне абстракции
N3: По возможности используйте стандартную номенклатуру
N4: Недвусмысленные имена
N5: Используйте длинные имена для длинных областей видимости
N6: Избегайте кодирования
N7: Имена должны описывать побочные эффекты
Тесты
Т1: Нехватка тестов
Т2: Используйте средства анализа покрытия кода
Т3: Не пропускайте тривиальные тесты
Т4: Отключенный тест как вопрос
Т5: Тестируйте граничные условия
Т6: Тщательно тестируйте код рядом с ошибками
Т7: Закономерности сбоев часто несут полезную информацию
Т8: Закономерности покрытия кода часто несут полезную информацию
T9: Тесты должны работать быстро
Заключение
Литература
Приложение А. Многопоточность II
Пример приложения "клиент/сервер"
Знайте свои библиотеки
Зависимости между методами могут нарушить работу многопоточного кода
Повышение производительности
Взаимная блокировка
Тестирование многопоточного кода
Средства тестирования многопоточного кода
Полные примеры кода
Приложение Б. org.jfree.date.SerialDate
Приложение В. Перекрестные ссылки
Эпилог
Алфавитный указатель
Рекомендуем
