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

Александр Шитик

Пишу свои посты и книги, делаю обзоры на фильмы и книги. Эксперт в области космологии и астрономии, IT, продуктивности и планирования.

Роберт Гласс

Жанры: Программирование

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

Год прочтения: 2020

Моя оценка: Наивысшая

Количество прочтений: 1

Количество страниц: 233

Конспект (страниц): 0

Первоначальный язык издания: Английский

Переводы на другие языки: Русский, Китайский

Общая информация

Книга 2008 года, состоящая из 55 фактов и 10 заблуждений о разработчиках и программировании в целом. Все материалы разделены на определённые группы, например: менеджмент, разработка и другие.

Сразу стоит оговориться, что почти все темы и вопросы, рассматриваемые автором, весьма спорные (холиварные), и у разных читателей может быть сильно отличающееся мнение. Для экономии времени и места я не собираюсь описывать своё мнение и видение по каждому из пунктов. Здесь я лишь бегло перечислю все факты и заблуждения, а в конце дам общую оценку книге. Каждый факт или заблуждение изложен примерно в объёме средней статьи, поэтому, если вам интересно, вы можете прочитать не всю книгу, а выбрать конкретные темы. Перед тем как перечислить все факты и заблуждения, также отмечу, что автор придерживается чёткой структуры в подаче материала:

• Сначала он обсуждает сам факт или заблуждение.
• Затем описывает споры и дебаты вокруг него.
• В конце приводит источники информации, относящиеся к теме.

Факты программирования

Человеческий фактор

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. Людей можно научить программированию, показывая им, как писать программы.

Заключение

Несмотря на то, что книга была написана в далёком 2008 году, я всё же рекомендую её к прочтению тем, кто изучает программирование. Из минусов первое, что бросается в глаза — трудно подтвердить или опровергнуть проценты и цифры, которые автор приводит в отдельных фактах. Также есть несколько фактов, которые на сегодняшний день уже утратили актуальность. В остальном же подавляющее большинство материала остаётся актуальным, и с ним будет полезно ознакомиться не только разработчикам, но и менеджерам.