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