Цена на сайте Бомбора указана без учета персональных скидок
Надежный код на Java с помощью инструментов статического анализа.

• Как писать лучшие программы на Java.
• Как распознавать распространенные ошибки и избегать их.
• Как экономить время на отладке и тестировании.
• Как использовать статические анализаторы для улучшения кода.

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

«Разбор полетов» по каждой ошибке:
• Иллюстративный пример кода.
• Объяснение причин ошибки.
• Раздел «Как этого избежать».

Об авторе:
Тагир ВАЛЕЕВ — технический руководитель компании JetBrains и чемпион Java (2020 г.). Его основной исследовательский интерес — статический анализ и рефакторинг кода. Разработал множество проверок кода для IntelliJ IDEA и FindBugs.

Год издания: 2025

Издание: Первое

Артикул: ITD000000001405476

ISBN: 978-5-04-207668-8

Возрастное ограничение: 12+

Кол-во страниц: 352

Размер: 162x235 мм

Толщина: 22 мм

Импринт: БОМБОРА

Бумага: офсетная 72/80

Подробнее о книге
Слушать аннотацию

Над книгой работали

Отзывы

Всего: 1
asmelik30 января 2025  |  LiveLib
Если вы программируете на Java, то эта книга для вас. В ней сконцентрирован колоссальный опыт поиска, анализа и исправления ошибок, которым удавалось годами скрываться под толщей кодовой базы, ускользая от многочисленных тестов и самых тщательных ревью. Я честно пытался найти в этой книге недостатки, чтобы снизить оценку. Но, к сожалению, то, что мне таки удалось обнаружить, выглядит скорее как субъективные придирки, чем как реальные проблемы.Статический анализатор.SonarLint — бесплатный статический анализатор от платформы Sonar, доступный как плагин к IDE и поддерживающий множество языков, в том числе и Java. (Глава 1, страница 33)Сейчас этот плагин называется "SonarQube for IDE"Конкатенация.Избегайте пользоваться конкатенацией строк, применяйте методы форматирования String.format() или, начиная с Java 15, String.formatted(). (Глава 2, страница 66)Конкатенация строк работает гораздо быстрее форматирования. При конкатенации используется StringBuilder без парсинга формата, без поддержки переменного количества аргументов, без внутренней проверки типов, без локализации. Это дает прирост производительности в 10-50 раз. Справедливости ради стоит сказать, что автор далее упоминает, что форматирование работает значительно медленнее, чем конкатенация.Ссылка на метод.Ошибка № 13. Связать ссылку на метод с неверным методом. contents .computeIfAbsent(fileName, StringBuilder::new) .append(line) .append("//n"); (Глава 2, страница 105)Ошибка № 14. Использование неверного метода в ссылке на метод. list.sort(Integer::max); (Глава 2, страница 110)Ошибка номер 13 связана с ссылкой на неправильный конструктор, а ошибка номер 14 описывает ссылку на неправильный метод. Везде ссылка указывает не на то, на что надо. Хочется задать вопрос автору: почему же это разные ошибки? До сотни не хватало, что ли?Загрузчик классов.Такого не случается в простых программах на Java, поскольку в них для всех классов используется один и тот же загрузчик. (Глава 5, страница 241)На самом деле любая программа на Java использует как минимум три загрузчика классов: Application ClassLoader, Platform ClassLoader и Bootstrap ClassLoader, которые загружают классы совместно по принципу делегирования загрузки родителю. Загрузчик Application делегирует загрузку класса загрузчику Platform, который делегирует загрузку класса загрузчику Bootstrap. Если загрузчик Bootstrap не нашел класс, то его пытается загрузить Platform, а если и он не смог найти класс, то в дело вступает загрузчик Application. Эта цепочка загрузчиков не может загрузить более одного класса с одним и тем же именем. Так что правильнее говорить не об одном и том же загрузчике, а об одной и той же цепочке загрузчиков.Эмодзи.По возможности отдавайте предпочтение API, основанным не на символах, а на кодовых точках, если существует вероятность появления произвольных символов в строках. (Глава 6, страница 258)Даже если рассматривать текст как последовательность кодовых точек, то при разбиении на строки это не даст гарантии, что все эмодзи сохранятся, ведь эмодзи может быть представлен двумя кодовыми точками.Красно-черное дерево.Итак, мы создаем 40 объектов StringBuilder и добавляем их в HashSet, заставляя его переключиться в реализацию красно-черного дерева. Далее мы создаем еще один объект StringBuilder, чей хэш-код полностью совпадает с одним из тех, которые у нас уже есть (для скорости мы использовали отсортированный массив хэш-кодов и алгоритм бинарного поиска). Этот объект StringBuilder сохраняется в переменной sb. Когда мы добавляем его к HashSet и затем изменяем, HashSet больше не может найти объект: метод contains возвращает false. (Глава 8, страница 161)Автор изменил хэш-код объекта, который уже был в одной из корзин хэш-таблицы. Где гарантия, что новый хэш-код будет соответствовать той же самой корзине? Скорее всего новый хэш-код заставит хэш-таблицу искать объект в другой корзине. Зачем тогда автору потребовалось переключаться на реализацию красно-черного дерева? Ведь дерево появилось только в одной корзине, а поиск скорее всего ведется в другой, где дерева нет.Перевод. По переводу у меня практически не
Читать полностью
Оценка *
Имя *
Email *
Комментарий *
Укажите символы с картинки*