Глава 1. Добро пожаловать
Существует мнение, что от 40 до 80 процентов стоимости любого проекта разработки ПО приходится на сопровождение (эксплуатацию? или только сопровождение кода?). Согласно этому же мнению, около 60 процентов вносимых в рамках поддержки изменений являются реальными улучшениями, а не просто исправлениями дефектов. При этом основная задача, стоящая перед разработчиками при поддержке, - это понимание существующего кода. Исходя из этого автор книги делает вывод, что основная задача программистов - не писать код, а понимать его.
Часть 1. Эволюционирующий код
Статический анализ кода предоставляет всего лишь снимок текущего состояния. Для всестороннего и по-настоящему полезного анализа кода необходимо учитывать еще и историю изменений.
Главы 2-3. Код как место преступления, поиск подозреваемых
Поддержка ПО - сложное и дорогое занятие. Соответственно, чтобы повысить эффективность поддержки и развития ПО, необходимо снизить сложность кода и привести его в такое состояние, в котором изменения можно вносить с легкостью. Это прямо перекликается с одним из направлений, которое должна обеспечить хорошая архитектура приложения (Критерии качества архитектуры ПО).
Решение о том, где именно вносить изменения, должно учесть следующие факторы:
- необходимость упростить излишне сложные элементы;
- необходимость снизить плотность дефектов в особенно уязвимых модулях;
- необходимость облегчить внесение изменений в те классы, с которыми более вероятно предстоит работать в будущем.
Учесть все эти факторы и расставить приоритеты очень сложно.
Одним из надежных способов найти места, где внесение изменений окажется наиболее эффективным, является соотнесение размера классов с частотой их изменения (статика + динамика), один из инструментов - CodeCity. Он представляет текущее состояние кода в виде “зданий” и “кварталов” города. Кварталы - это пакеты, отдельные здания - это классы. Площадь основания здания - это количество полей, а высота здания - количество методов в классе.
Суть в том, что ООП-объекты, которые имеют много методов и полей, а также часто изменяются, скорее всего, содержат слишком много логики и нарушают как минимум Single Responsibility Principle.
Глава 4.
Связи и ссылки
- Упоминает книгу “Facts and Fallacies of Software Engineering”, #ГлассРоберт