Недавно попалась мне на глаза очень занимательная книга “Факты и заблуждения профессионального программирования”. Очень интересный, теоретически обоснованный, список утверждений о современном процессе создания ПО. Все факты имеют достаточно детальное разъяснение, которое дается без специальных терминов и не привязано к определенному языку программирования. Даже беглый просмотр глав, дает очень много интересной информации и желание ознакомится с полным текстом книги. Здесь я приведу список глав этой книги.
Факты:
1. Самый важный фактор в разработке ПО– это не методы и средства, применяемые программистами, а сами программисты.
2. По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть, что оплата их труда никогда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО.
3. Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
4. Условия труда оказывают сильное влияние на продуктивность и качество
результата.
5. Рекламный звон вокруг инструментов и методов это чума индустрии ПО. Большая часть усовершенствований средств и методов приводит к увеличению производительности и качества примерно на 5–35%. Но многие изэтих усовершенствований были заявлены как дающие преимущество «на порядок».
6. Изучение нового метода или средства сначала понижает производительность программистов и качество продукта. Пользу из обучения можно извлечь только после того, как пройдена кривая обучения. Поэтому вводить новые методы и средства имеет смысл, только если а) видеть их реальную
ценность и б) проявлять терпение в ожидании выигрыша.
7. Разработчики много говорят об инструментальных средствах. Они пробуютдовольно многие, приобретают их в достаточном количестве, но практически не работают с ними.
8. Чаще всего одной из причин неуправляемости проекта является плохая оценка. (Второй причине посвящен Факт23.)
9. Большинство оценок в проектах ПО делается в начале жизненного цикла. Иэто не смущает нас, пока мы не понимаем, что оценки получены раньше, чем определены требования, и соответственно раньше, чем задача изучена. Следовательно, оценка обычно делается не вовремя.
10. Большинство оценок в проектах ПО делают либо топ-менеджеры, либо сотрудники, занимающиеся маркетингом, а вовсе не те, кто будет создавать ПО, или их руководители. Таким образом, оценку делают не те люди.
11. Оценки в проектах ПО редко уточняются впоследствии. Другими словами, оценки, сделанные не теми людьми и не в то время, как правило, не корректируются.
12. Раз оценки настолько неправильны, то не так уж много причин беспокоиться о том, что программные проекты не завершаются в сроки, задаваемые оценками. Однако всех это беспокоит.
13. Между менеджерами и программистами нет контакта. В одном исследовании, посвященном проекту, в котором не были соблюдены параметры, заданные на основании оценки, и который рассматривался руководством как неудачный, говорится, что технические исполнители отозвались о нем как о самом удачном проекте, над которым они когда либо работали.
14. Анализ осуществимости проекта почти всегда дает ответ «да».
15. Повторное использование «в миниатюре» (в библиотеках подпрограмм) появилось почти 50 лет назад, и решение этой задачи отработано хорошо.
16. Задача повторного использования «в крупном масштабе» (в компонентах) остается по большей части нерешенной, хотя все согласны с тем, что сделать это очень важно.
17. Успех повторного использования в крупном масштабе бывает максимальным в семействах родственных систем и потому зависит от предметной области. Это сужает потенциальную применимость повторного использования в крупном масштабе.
18. В практике повторного использования есть два «правила трех»: а) многократно используемые компоненты в три раза более трудоемки, чем одноразовые компоненты; и б) многократно используемый компонент должен быть
испробован в трех различных приложениях, прежде чем его можно будет считать достаточно общим, чтобы допустить в библиотеку компонентов.
19. Модификация повторно используемого кода крайне чревата ошибками. Если надо изменить более 20-25% кода компонента, то лучше переписать его с самого начала.
20. Повторное использование паттернов проектирования– это решение проблем, сопутствующих повторному использованию кода.
21. Увеличение сложности задачи на 25% приводит к усложнению программного решения на 100%. Это не условие, которое можно попытаться изменить (хотя сложность всегда желательно свести к минимуму), это реальное
положение дел.
22. Восемьдесят процентов работ по созданию ПО приходится на интеллектуальную деятельность. Изрядную долю последней можно смело отнести ккреативной. Илишь небольшую часть– к технической.
23. Одной из двух самых распространенных причин неуправляемости проектов являются изменчивые требования. (Другая причина рассмотрена в Факте 8.)
24. Исправление ошибок в требованиях обходится дороже всего, если они обнаружены на этапе эксплуатации, и дешевле всего, если это происходит наранних этапах разработки.
25. Требования, которых нет,– это такая ошибка, исправить которую труднее всего.
26. По мере продвижения от начальных требований к архитектуре на нас обрушивается шквал «производных требований» (требований к конкретному проектному решению), вызванный сложностью процесса. Список этих производных требований часто в 50 раз длиннее изначального.
27. Лучшее проектное решение задачи программирования редко бывает единственным.
28. Проектирование– это сложный итеративный процесс. Первоначальное проектное решение, скорее, всего окажется неверным и, безусловно, не оптимальным.
29. Программисты переходят от проектирования к кодированию тогда, когда задача разобрана до уровня «примитивов», которыми владеет проектировщик. Если кодировщик и проектировщик– это разные люди, то примитивы проектировщика, вероятно, не будут совпадать с примитивами кодировщика и это приведет к неприятностям.
30. COBOL– это очень плохой язык, но все остальные (для обработки бизнесданных) гораздо хуже.
31. Фаза устранения ошибок– самая трудоемкая в жизненном цикле.
32. Оказывается, что в ПО, о котором типичный программист думает, что оно тщательно протестированно, нередко проверено выполнение лишь 55–60% логических путей. Применение автоматизированных средств, таких как
анализаторы покрытия, позволяет повысить эту долю примерно до 85–90%. Протестировать 100% логических путей ПО практически невозможно.
33. Даже если бы 100%%тестовое покрытие было возможно, оно не годилось бы на роль критерия достаточности тестирования. Примерно 35% дефектов ПО вызвано пропущенными логическими путями иеще 40% связаны с выполнением уникальной комбинации логических путей. Их не выявить при 100% покрытии тестами.
34. Без инструментальных средств почти невозможно качественно проделать работу по устранению ошибок. Широко применяются отладчики – в отличие от других инструментов, например анализаторов тестового покрытия.
35. Тесты редко автоматизируются. То есть определенные процессы тестирования могут и должны быть автоматизированы. Но значительную часть работы, связанной с тестированием, автоматизировать нельзя.
36. Важным дополнением к инструментам тестирования является созданный программистом встроенный отладочный код, желательно, включаемый вобъектный код в зависимости от директив компиляции.
37. Тщательные инспекции позволяют устранить до 90% ошибок из программного продукта до того, как будет запущен первый эталонный тест.
38. Тщательные инспекции дают множество выгод, но они не могут заменить тестирование.
39. Общепризнано, что обзоры, сделанные постфактум (их также называют ретроспективными), важны как с точки зрения интересов потребителя (пользователя ПО), так и с точки зрения совершенствования процесса. Однако в большинстве организаций ретроспективные обзоры не делаются.
40. В инспекциях наряду с техническими факторами присутствует и социальный. Уделять большее внимание чему-то одному в ущерб другому – прямой путь к катастрофе.
41. Стоимость сопровождения обычно составляет от 40 до 80% (в среднем 60%) стоимости ПО. Следовательно, эта фаза его жизненного цикла, возможно, самая важная.
42. Примерно 60% расходов на сопровождение приходится на улучшение кода и около 17% – на исправление ошибок. Таким образом, в основном сопровождение и поддержка ПО заключается в добавлении в него новых возможностей, а не в его исправлении.
43. Сопровождение– это решение, а не проблема.
44. Если сравнивать задачи разработки и сопровождения ПО, то они по большей части одинаковы,– за исключением дополнительной задачи сопровождения, формулируемой как «изучение сопровождаемого продукта». Она занимает примерно 30% времени, уходящего на сопровождение в целом, иэтот вид деятельности преобладает в сопровождении. Таким образом, можно сказать, что сопровождение более трудоемко, чем разработка.
45. Улучшение качества разработки ПО приводит к тому, что сопровождения становится больше, а не меньше.
46. Качество есть совокупность свойств.
47. Качество не определяется удовлетворением пользователя, соответствием требованиям заказчика, приемлемостью цены и соблюдением сроков сдачи продукта или надежностью.
48. Есть такие ошибки, к которым предрасположено большинство программистов.
49. Ошибки имеют тенденцию образовывать скопления.
50. Для устранения ошибок еще не выработан какой-то один, лучший подход.
51. От ошибок никуда не деться. Цель состоит в том, чтобы избежать критических ошибок или свести их к минимуму.
52. Эффективность больше зависит от качественного проектирования приложения, чем от качественного программирования.
53. Эффективность кода на языке высокого уровня, компилированного с соответствующими параметрами оптимизации, может достигать 90% эффективности функционально сравнимого ассемблерного кода. А в некоторых сложных современных архитектурах она может быть даже выше.
54. Существуют компромиссы между оптимизацией по размеру и оптимизацией по скорости. Нередко улучшение первого показателя вызывает ухудшение второго.
55. Многие ученые, работающие в индустрии программирования, склонны скорее защищать свои теории, чем заниматься исследованиями. Результат: а)ценность некоторых пропагандируемых теорий намного меньше, чем
думают сами пропагандисты; б)мало исследований, призванных помочь определить, какова же истинная ценность этих теорий.
Заблуждения:
1. Невозможно управлять тем, что невозможно измерить.
2. Менеджмент может сделать программный продукт качественным.
3. Программирование может и должно быть обезличенным.
4. Инструменты и технологии универсальны.
5. Программирование нуждается в большем количестве методологий.
6. Чтобы оценить затраты и определить сроки, сначала сосчитайте строки кода.
7. Использование случайных входных данных– хороший способ оптимизировать тестирование.
8. «Все ошибки становятся заметными, если на них обращено достаточно много глаз».
9. Зная, во что обошлась поддержка в предыдущем случае, можно предсказать, во что она обойдется в будущем, и принять решение о целесообразности замены продукта.
10. Людей можно научить программированию, показывая им, как писать программы.