Роберт Гласс. Факты и заблуждения профессионального программирования

[alexdjachenko]

Очень разумная книжка по практике программирования, проектирования ПО и управления программными проектами. В книге собраны эмпирические закономерности разработки ПО в виде 55 фактов и 10 заблуждений.

Среди них:

• Наиболее важный фактор в разработке ПО - это сами программисты.
• Лучший программист работает в 28 раз быстрее худшего и с лучшим качеством.
• Если проект не укладывается в сроки, то добавление программистов замедляет его еще больше ("закон Брукса")
• Продуктивность и качество работы программистов сильно зависит от условий труда.
• Результаты почти всех методик и инструментов гораздо скромнее обещанного и дают улучшение качества и производительности на 5-35%.
• Внедрение новой методики или инструмента всегда сначала снижает производительность и качество.
• Разработчики любят и приобретают новые инструменты, но почти не пользуются ими.
• Чаще всего, основной причиной неуправляемости проекта является плохая оценка сроков.
• Большинство оценок делаются раньше, чем окончательно формируется список требований и ТЗ.
• Оценки обычно делают неспециалисты (топ-менеджеры или маркетологи), которые не представляют, как оценить трудоемкость разработки ПО.
• Почти никогда оценки не уточняются и не пересматриваются.
• Несмотря на неправильную оценку, всех беспокоит, что сроки не соблюдаются.
• Менеджеры и программисты не имеют согласованного мнения о том, какой проект успешный, а какой - провальный.
• Анализ осуществимости проекта почти никогда не дает отрицательного результата.
• Повторное использование "в миниатюре" (в виде библиотек подпрограмм) появилось 50 лет назад и успешно используется.
• Задача повторного использования в крупном масштабе остается нерешенной, хотя все признают ее важной.
• Более-менее успешно применять повторное использование в крупном масштабе удается только в родственных (однотипных) проектах.
• "Правила трех" в повторном использовании
  • Многократно используемые компоненты в три раза более трудоемки.
  • Многократно используемый компонент должен быть опробован в трех различных проложениях
• Модификация повторно-используемого кода чревата ошибками. Если требуется изменить более 20-25% кода, то проще написать с нуля.
• Повторное использование паттернов проектирования - решение проблем, сопутствующих повторному использованию кода.
• Увеличение сложности задачи на четверть приводит к двухкратному усложнения программы.
• 80% работы по созданию ПО приходится на интеллектуальную деятельность, остальное - это рутина по записи решения и только она поддается автоматизации с помощью инструментов.
• Вторая причина неуправляемости проекта - это изменчивые требования.
• Исправление ошибок в требованиях обходится дороже всего, если они обнаружатся после внедрения.
• Труднее всего обнаружить ошибку в виде отсутствующих важных требований.
• Производные требования (не заявленные прямо клиентов, а подразумеваемые или вытекающие из задачи) могут составлять 95% всех требований.
• Большинство задач допускают множество одинаково хороших программных решений.
• Проектирование - это сложный итеративный (многократно повторяющийся и уточняющийся) процесс.
• Проектировщик заканчивает проектирование, когда дойдет до уровня примитивов, знакомых программистам. Важно, чтобы проектировщик и программисты мыслили одинаковыми примитивами.
• Фаза устранения ошибок - самая трудоемкая.
• "Тщательно протестированное" ПО содержит до 45% непроверенных ни разу логических путей. Специальные инструменты позволяют увеличить покрытие до 90%. 100% покрытие недостижимо.
• Даже 100% покрытие не дало бы результата, так как 35% дефектов вызвано пропущенными логическими путями, а еще 40% - с уникальными комбинациями этих путей.
• Качественно отладить продукт без с специальных инструментов практически невозможно.
• Значительная часть тестов не поддается автоматизации.
• Для тестирования очень важен встроенный отладочный код.
• До 90% ошибок могут быть устранены в результате инспекции кода (построчного разбора и анализа) другим программистом.
• Однако, тщательные инспекции все же не могут полностью заменить тестирование, а только дополняют его.
• Ретроспективные разборы проектов очень полезны, но почти никем не делаются.
• Инспекция кода требует тщательности, легко упустить что-то важное, поэтому рекомендуются опросники.
• Стоимость сопровождения может быть в 5 раз больше стоимости первоначальной разработки. Однако, только 17% ее идет на устранение ошибок, а остальное на доработку и портирование. Сопровождение - это такая же часть жизненного цикла, как и остальные. Нельзя подходить к ней как к расходам - это дополнительная полезная работа, нужная заказчику, а не "гарантийное обслуживание".
• 30% расходов на сопровождение приходится на работу по чтению кода и изучению продукта (даже если сопровождение выполняют авторы продукта).
• Улучшение качества разработки ПО увеличивает количество пользователей, срок использования и потенциальные возможности по доработке, что увеличивает (а не уменьшает) стоимость сопровождения.
• Качество ПО состоит из: переносимости, надежности, эффективности, удобства в использовании, понятности и модифицируемости.
• Качество не определяется удовлетворением пользователя, соответствия требованиям, ценой, сроками и надежностью. Они важны, но не имеют прямого отношения к качеству ПО.
• Программисты предрасположены к определенным ошибкам из-за особенностей человеческого мышления. Например, ошибка на 1 при индексировании или выполнении цикла.
• Ошибки чаще группируются и образуют скопления, чем встречаются по одиночке.
• Ошибки неизбежны. Нет единого лучшего подхода для устранения ошибок. Их можно только свести к минимуму.
• Эффективность больше зависит от качества проектирования, чем от качества программирования.
• Чем сложнее система, тем больше эффективность кода на языке высокого уровня по сравнению с ассемблером, потому что человек способен охватить только определенный уровень сложности.
• Уменьшение объема необходимой памяти ухудшает производительность и, наоборот, улучшение производительности увеличивает расход памяти.
• Большинство ученых в теории программировании больше защищают свои теории, нежели занимаются исследованием. В результате у нас много разрекламированных, но неэффективных методик и инструментов.