Магазинов: 3, Цена: от 731 руб. посмотреть все

Даже плохой программный код может работать. Однако если код не является \"чистым\", это всегда будет мешать развитию проекта и компании-разработчика, отнимая значительные ресурсы на его поддержку и \"укрощение\". Эта книга посвящена...

  Читай-Город - 731 руб.   Буквоед - 965 руб.

  Литрес - 599 руб.

Бьёрн Страуструп, создатель C++ и автор книги «The C++ Programming Language»
Я люблю, чтобы мой код был элегантным и эффективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, чтобы упростить сопровождение; обработка ошибок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу.

Грэди Буч, автор книги «Object Oriented Analysis and Design with Applications»
Чистый код прост и прямолинеен. Чистый код читается, как хорошо написанная проза. Чистый код никогда не затемняет намерения проектировщика; он полон четких абстракций и простых линий передачи управления.

«Большой» Дэйв Томас, основатель OTI, крестный отец стратегии Eclipse
Чистый код может читаться и усовершенствоваться другими разработчиками, кроме его исходного автора. Для него написаны модульные и приемочные тесты. В чистом коде используются содержательные имена. Для выполнения одной операции в нем используется один путь (вместо нескольких разных). Чистый код обладает минимальными зависимостями, которые явно определены, и четким, минимальным API. Код должен быть грамотным, потому что в зависимости от языка не вся необходимая информация может быть четко выражена в самом коде.

Майкл Физерс, автор книги «Working Effectively with Legacy Code»
Я мог бы перечислить все признаки, присущие чистому коду, но существует один важнейший признак, из которого следуют все остальные. Чистый код всегда выглядит так, словно его автор над ним тщательно потрудился. Вы не найдете никаких очевидных возможностей для его улучшения. Все они уже были продуманы автором кода. Попытавшись представить возможные усовершенствования, вы снова придете к тому, с чего все началось: вы рассматриваете код, тщательно продуманный и написанный настоящим мастером, небезразличным к своему ремеслу.

Уорд Каннингем, создатель Wiki, создатель Fit, один из создателей экстремального программирования. Вдохновитель написания книги «Design Patterns». Духовный лидер Smalltalk и объектно-ориентированного подхода. Крестный отец всех, кто тщательно относится к написанию кода.
Вы работаете с чистым кодом, если каждая функция делает примерно то, что вы ожидали. Код можно назвать красивым, если у вас также создается впечатление, что язык был создан специально для этой задачи.

А как насчет меня (Дядюшка Боб)? Что я думаю по поводу чистого кода? Эта книга расскажет вам во всех подробностях, что я и мои соратники думаем о чистом коде. Вы узнаете, как, по нашему мнению, должно выглядит чистое имя переменной, чистая функция, чистый класс и т. д. Мы излагаем свои мнения в виде беспрекословных истин и не извиняемся за свою категоричность. Для нас, на данном моменте наших карьер, они являются беспрекословными истинами. Они составляют нашу школу мысли в области чистого кода. Мастера боевых искусств не достигли единого мнения по поводу того, какой из видов единоборств является лучшим, а какие приемы — самыми эффективными. Часто ведущие мастера создают собственную школу и набирают учеников. Так появилась школа дзю-дзюцу Грейси, основанная семьей Грейси в Бразилии. Так появилась школа дзю-дзюцу Хаккорю, основанная Окуямой Рюхо в Токио. Так появилась школа Джит Кун-до, основанная Брюсом Ли в Соединенных Штатах. Ученики этих разных школ погружаются в учение основателя школы. Они посвящают себя изучению того, чему учит конкретный мастер, часто отказываясь от учений других мастеров. Позднее, когда уровень их мастерства возрастет, они могут стать учениками другого мастера, чтобы расширить свои познания и проверить их на практике. Некоторые переходят к совершенствованию своих навыков, открывают новые приемы и открывают собственные школы. Ни одна из этих разных школ не обладает абсолютной истиной. Тем не менее в рамках конкретной школы мы действуем так, будто ее учение и арсенал приемов верны. Именно так и следует тренироваться в школе Хаккорю или Джит Кун-до. Но правильность принципов в пределах одной школы не делает ошибочными учения других школ. Считайте, что эта книга является описанием Школы учителей Чистого кода. В ней представлены те методы и приемы, которыми мы сами пользуемся в своем искусстве. Мы утверждаем, что если вы последуете нашему учению, то это принесет вам такую же пользу, как и нам, и вы научитесь писать чистый и профессиональный код. Но не стоит думать, что наше учение «истинно» в каком-то абсолютном смысле. Существуют другие школы и мастера, которые имеют ничуть не меньше оснований претендовать на профессионализм. Не упускайте возможности учиться у них. В самом деле, многие рекомендации в этой книге противоречивы. Вероятно, вы согласитесь не со всеми из них. Возможно, против некоторых вы будете яростно протестовать. Это нормально. Мы не претендуем на абсолютную истину. С другой стороны, приведенные в книге рекомендации являются плодами долгих,непростых размышлений. Мы пришли к ним после десятилетий практической работы, непрестанных проб и ошибок. Независимо от того, согласитесь вы с нами или нет, нашу точку зрения стоит по крайней мере узнать и уважать.

Предисловие 14
Введение 20
Глава 1. Чистый код 23
Да будет код
Плохой код
Расплата за хаос
Грандиозная переработка
Отношение
Основной парадокс
Искусство чистого кода?
Что такое «чистый код»?
Мы — авторы
Правило бойскаута
Предыстория и принципы
Заключение
Литература
Глава 2. Содержательные имена (Тим Оттингер) 39
Имена должны передавать намерения программиста
Избегайте дезинформации
Используйте осмысленные различия
Используйте удобопроизносимые имена
Выбирайте имена, удобные для поиска
Избегайте схем кодирования имен
Венгерская запись
Префиксы членов классов
Интерфейсы и реализации
Избегайте мысленных преобразований
Имена классов
Имена методов
Избегайте остроумия
Выберите одно слово для каждой концепции
Воздержитесь от каламбуров
Используйте имена из пространства решения
Используйте имена из пространства задачи
Добавьте содержательный контекст 51
Не добавляйте избыточный контекст 53
Несколько слов напоследок 53
Глава 3. Функции 55
Компактность! 58
Блоки и отступы 59
Правило одной операции 59
Секции в функциях 60
Один уровень абстракции на функцию 61
Чтение кода сверху вниз: правило понижения 61
Команды switch 62
Используйте содержательные имена 64
Аргументы функций 64
Стандартные унарные формы 65
Аргументы-флаги 66
Бинарные функции 66
Тернарные функции 67
Объекты как аргументы 68
Списки аргументов 68
Глаголы и ключевые слова 68
Избавьтесь от побочных эффектов 69
Выходные аргументы 70
Разделение команд и запросов 70
Используйте исключения вместо возвращения кодов ошибок 71
Изолируйте блоки try/catch 72
Обработка ошибок как одна операция 72
Магнит зависимостей Error.java 73
Не повторяйтесь 73
Структурное программирование 74
Как научиться писать такие функции? 74
Завершение 75
Литература 78
Глава 4. Комментарии 79
Комментарии не компенсируют плохого кода 81
Объясните свои намерения в коде 81
Хорошие комментарии 81
Юридические комментарии 82
Информативные комментарии 82
Представление намерений 82
Прояснение 83
Предупреждения о последствиях 84
Комментарии TODO 85
Усиление 85
Комментарии Javadoc в общедоступных API 86
Плохие комментарии 86
Бормотание 86
Избыточные комментарии 87
Недостоверные комментарии 89
Обязательные комментарии 90
Журнальные комментарии 90
Шум 91
Опасный шум 93
Не используйте комментарии там, где можно использовать функцию или переменную 93
Позиционные маркеры 94
Комментарии за закрывающей фигурной скобкой 94
Ссылки на авторов 95
Закомментированный код 95
Комментарии HTML 96
Нелокальная информация 96
Слишком много информации 97
Неочевидные комментарии 97
Заголовки функций 97
Заголовки Javadoc во внутреннем коде 98
Пример 98
Литература 101
Глава 5. Форматирование 102
Цель форматирования
Вертикальное форматирование
Газетная метафора
Вертикальное разделение концепций
Вертикальное сжатие
Вертикальные расстояния
Вертикальное упорядочение
Горизонтальное форматирование
Горизонтальное разделение и сжатие
Горизонтальное выравнивание
Отступы
Вырожденные области видимости
Правила форматирования в группах
Правила форматирования от дядюшки Боба
Глава 6. Объекты и структуры данных 121
Абстракция данных
Антисимметрия данных/объектов
Закон Деметры
Крушение поезда
Гибриды
Скрытие структуры
Объекты передачи данных
Активные записи
Заключение
Литература
Глава 7. Обработка ошибок (Майк Физерс) 131
Используйте исключения вместо кодов ошибок 132
Начните с написания команды try-catch-finally 133
Используйте непроверяемые исключения
Передавайте контекст с исключениями
Определяйте классы исключений в контексте потребностей вызывающей стороны
Определите нормальный путь выполнения
Не возвращайте null
Не передавайте null
Заключение
Литература
Глава 8. Границы (Джеймс Гренинг) 142
Использование стороннего кода
Исследование и анализ границ
Изучение log4j
Учебные тесты: выгоднее, чем бесплатно
Использование несуществующего кода
Чистые границы
Литература
Глава 9. Модульные тесты 150
Три закона TTD
О чистоте тестов
Тесты как средство обеспечения изменений
Чистые тесты
Предметно-ориентированный язык тестирования
Двойной стандарт
Одна проверка на тест
Одна концепция на тест
F.I.R.S.T
Заключение
Литература
Глава 10. Классы (совместно с Джеффом Лангром) 164
Строение класса
Инкапсуляция
Классы должны быть компактными!
Принцип единой ответственности (SRP)
Связность
Поддержание связности приводит к уменьшению классов
Структурирование с учетом изменений
Изоляция изменений
Литература
Глава 11. Системы (Кевин Дин Уомплер) 181
Как бы вы строили город?
Отделение конструирования системы от ее использования
Отделение main
Фабрики
Внедрение зависимостей
Масштабирование
Поперечные области ответственности
Посредники
АОП-инфраструктуры на «чистом» Java
Аспекты AspectJ
Испытание системной архитектуры
Оптимизация принятия решений
Применяйте стандарты разумно, когда они приносят очевидную пользу
Системам необходимы предметно-ориентированные языки
Заключение
Литература
Глава 12. Формирование архитектуры 200
Четыре правила
Правило No 1: выполнение всех тестов
Правила No 2–4: переработка кода
Отсутствие дублирования
Выразительность
Минимум классов и методов
Заключение
Литература
Глава 13. Многопоточность (Бретт Л. Шухерт) 207
Зачем нужна многопоточность?
Мифы и неверные представления
Трудности
Защита от ошибок многопоточности
Принцип единой ответственности
Следствие: ограничивайте область видимости данных
Следствие: используйте копии данных
Следствие: потоки должны быть как можно более независимы
Знайте свою библиотеку
Потоково-безопасные коллекции
Знайте модели выполнения
Модель «производители-потребители»
Модель «читатели-писатели»
Модель «обедающих философов»
Остерегайтесь зависимостей между синхронизированными методами
Синхронизированные секции должны иметь минимальный размер
О трудности корректного завершения
Тестирование многопоточного кода
Рассматривайте непериодические сбои как признаки возможных проблем многопоточности
Начните с отладки основного кода, не связанного с многопоточностью
Реализуйте переключение конфигураций многопоточного кода
Обеспечьте логическую изоляцию конфигураций многопоточного кода
Протестируйте программу с количеством потоков, превышающим количество процессоров
Протестируйте программу на разных платформах
Применяйте инструментовку кода для повышения вероятности сбоев
Ручная инструментовка
Автоматизированная инструментовка
Заключение
Библиография
Глава 14. Последовательное очищение 225
Реализация Args
Как я это сделал?
Args: черновик
На этом я остановился
О постепенном усовершенствовании
Аргументы String
Заключение
Глава 15. Внутреннее строение JUnit 287
Инфраструктура JUnit 288
Заключение 302
Глава 16. Переработка SerialDate 303
Прежде всего — заставить работать
...Потом очистить код
Заключение
Библиография
Глава 17. Запахи и эвристические правила 322
Комментарии
C1: Неуместная информация
C2: Устаревший комментарий
C3: Избыточный комментарий
C4: Плохо написанный комментарий
C5: Закомментированный код
Рабочая среда
E1: Построение состоит из нескольких этапов
E2: Тестирование состоит из нескольких этапов
Функции
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: Имена должны описывать побочные эффекты
Тесты
T1: Нехватка тестов
T2: Используйте средства анализа покрытия кода
T3: Не пропускайте тривиальные тесты
T4: Отключенный тест как вопрос
T5: Тестируйте граничные условия
T6: Тщательно тестируйте код рядом с ошибками
T7: Закономерности сбоев часто несут полезную информацию
T8: Закономерности покрытия кода часто несут полезную информацию
T9: Тесты должны работать быстро
Заключение
Библиография
Приложение А. Многопоточность II 357
Пример приложения «клиент/сервер»
Знайте свои библиотеки
Зависимости между методами могут нарушить работу многопоточного кода
Повышение производительности
Взаимная блокировка
Тестирование многопоточного кода
Средства тестирования многопоточного кода
Полные примеры кода
Приложение Б. org.jfree.date.SerialDate 390
Приложение В. Перекрестные ссылки 455
Эпилог 458
Алфавитный указатель 459