Сообщений 13 
Оценка 983
[+7/-0]
Оценить 
| Сообщений 13 Оценка 983
[+7/-0]
Оценить
|
Занимая свою нишу в индустрии разработки программного обеспечения, я трачу от шести месяцев до нескольких лет, чтобы выпустить компьютерную игру. Затем я могу продавать ее продолжения и пакеты расширения, но я не имею возможности продавать для нее исправления. Когда я выпускаю новую игру, я должен быть уверен в ее качестве, т.к. мои клиенты даже и не подумают о том, чтобы искать апгрейды. Из-за короткого времени жизни большинства компьютерных игр и их зависимости от недолговечных технологий, мои возможности по улучшению выпущенных продуктов, на основе откликов клиентов, минимальны. Чтобы справляться с этими проблемами, я постепенно перешел на использование практик системы гарантии качества (Quality Assurance). Это позволило мне существенно увеличить качество моих программ, одновременно уменьшив время их разработки.
Разработка Бездефектного Программного Обеспечения (Zero-Defect Software Development, ZDSD) не означает “разработка без ошибок”. Это практика, которая подразумевает наилучшее качество ПО на протяжении всего процесса разработки. “Дефекты” – это аспекты поведения программы, которые не годятся для конечного продукта. Такое достаточно широкое определение включает в себя как ошибки в программе, так и нежелательные отклонения от желаемого результата. Дефекты в разработке компьютерной игры могут включать в себя неотшлифованную графику, недопустимо низкую частоту обновления экрана, недостаточно интересные уровни или любые другие недоработки.
Основной принцип ZDSD гласит: “Поддерживайте состояние своего продукта в таком положении, чтобы быть уверенным в отсутствии в нем дефектов на протяжении всего процесса разработки”. Это просто звучит, но редко встречается. Чаще основное тестирование откладывается до финальной стадии разработки. В результате некоторые ошибки впервые обнаруживаются только когда проект уже должен заканчиваться. Большинство ошибок не обнаруживают или не исправляют достаточно долгое время после того, как их сделали. И чем больше времени проходит от совершения ошибки до ее обнаружения, тем сложнее ее исправить. В больших проектах каждая стадия разработки, которую переживает ошибка, увеличивает стоимость ее устранения в 10-50 раз. Исправление дефекта, допущенного во время дизайна системы и обнаруженного на стадии тестирования, может обойтись в сотни раз дороже, чем если бы он был обнаружен сразу.
Концентрируясь на качестве продукта на протяжении всего цикла разработки, вы, возможно, завершите ее быстрее, чем если бы вы не уделяли внимания качеству до конца проекта. Основное правило, касающееся качества ПО, не очень понятно интуитивно: улучшение качества кода уменьшает время разработки. Это происходит вследствие уменьшения расхода времени на исправление ошибок и переработку кода, в больших проектах достигающего 50% общего времени разработки. Типичный программист пишет от восьми до двадцати строк кода в день, а оставшуюся часть времени проводит в отладке. ZDSD сокращает график работ, устраняя большую часть этого “отладочного” времени. Обширные исследования, проведенные NASA, IBM и кое-где еще показали, что более хорошее качество порождает меньший объем работ. Исследования IBM также доказали, что проекты, в которых качество имеет высокий приоритет, обычно разрабатываются за более короткие сроки, имеют более высокую продуктивность и даже более успешные продажи.
Ниже представлены
Используйте ежедневные сборки и smoke-тесты. В конце каждого рабочего дня собирайте текущую версию и тестируйте ее основную функциональность. Microsoft сделала эту политику своим стандартом и собирает проекты каждый день, используя большие команды разработчиков. Программист, чей код нарушил сборку, может быть поднят посреди ночи и вызван на работу, чтобы исправить проблему немедленно. Для разработчиков, работающих над маленькими проектами, все намного проще. В конце каждого дня тестируйте свою программу как минимум 10 минут. Ведите список того, что можно назвать ошибками, и всегда исправляйте их перед тем, как добавить в программу новые возможности. Если вы нашли ошибку – ее исправление должно стать первоочередным занятием. Вы должны избегать написания нового кода до тех пор, пока она не будет исправлена.
Большинство людей, думая о качестве, подразумевает тестирование. Однако в действительности тестирование является одной из самых неэффективных стратегий поиска ошибок. Даже с помощью очень строгого тестирования обычно удается найти не более 60% ошибок в программе. Кроме того, существуют виды ошибок, которые очень редко обнаруживаются с помощью тестирования. Изучая управление во многих больших организациях, производящих программное обеспечение, я пришел к выводу, что просмотр кода гораздо эффективнее тестирования. Исследования NASA обнаружили, что чтение кода обнаруживает почти в два раза больше ошибок, нежели тестирование. Добавив несколько сотен строк нового кода в проект, остановитесь на час или два, чтобы заново прочитать то, что вы написали и поискать там ошибки. По мере приобретения опыта, вы можете составить список ошибок, которые вы обычно делаете, и сверяться с ним каждый раз, когда вы просматриваете код. Вы можете также привлечь кого-нибудь еще, чтобы он прочитал ваш код.
Иногда, обнаруживая новую непонятную ошибку, мы молимся: “Только бы причина была не в этом коде!”. У всех нас есть монстроидальные модули, написанные в то время, когда мы еще не были такими хорошими программистами, как сейчас. Не бойтесь этого: переписывайте старые модули. Очень часто лучшие способы решения задач обнаруживаются только тогда, когда реализованы модули низкого уровня. По крайней мере, так считает Джон Кармак (John Carmack), который перепробовал не один десяток различных подходов прежде чем получил желаемое, когда писал движок Quake. Ошибки не распределяются равномерно по всему коду. Скорее всего, вы обнаружите, что 20% кода порождает 80% ошибок. Для моих программ абсолютно нормально, что модули, взаимодействующие со сторонними драйверами, а особенно с DirectX, глючат больше всего. Поднимите свои стандарты качества для тех модулей, которые, как кажется, являются неиссякаемыми источниками ошибок, и выделите время, чтобы переписать их заново. Вы можете обнаружить, что некоторые редко проявляющиеся ошибки в результате исчезнут.
95% всех ошибок в программе делается программистом. Только 1% ошибок происходят из-за аппаратной части, а оставшиеся 4% приходятся на дефекты компилятора, операционной системы и другого ПО. Никогда не упускайте потенциальную ошибку; всегда находите точную причину аномалии. Когда в зонде, отправленном на Марс, обнаружилась серьезная программная ошибка, оказалось, что она возникала еще при тестировании, но программисты посчитали ее случайным сбоем в железе.
С того момента, как вы начали писать код, вы всегда думаете о новых возможностях, которые туда следует добавить. Аккуратно проверяйте, как новые изменения повлияют на уже существующий код. Слабая интеграция изначально не ожидаемых нововведений – это основная причина ошибок в программе.
Иногда можно быстро написать прототип новой функциональности только для того, чтобы посмотреть, жизнеспособна ли она. Зачастую качество кода приносится в жертву во имя быстрой разработки. И если вы вдруг все же решили сохранить этот код, возникает соблазн просто проверить прототип на наличие явных ошибок. Не попадайтесь в эту ловушку! Если вы не заботились о качестве изначально, выкиньте код прототипа и реализуйте функциональность заново. Разработанные на скорую руку и попавшие в конечный продукт вещи - один из главных источников ошибок, поскольку они с самого начала не соответствовали стандартам качества остального кода.
Исследования показывают, что те разработчики, которые устанавливают некие стандарты качества, обычно их достигают. Заранее решите, что ваш продукт должен быть быстрым, маленьким по размеру, многофункциональным, интуитивно понятным, расширяемым и т.д. Затем расставьте приоритеты этих целей. Когда я разрабатывал код Dweep (http://www.dexterity.com/dweep/), я решил, что приоритетными целями будут интуитивная понятность, быстрота и забавность, именно в таком порядке. В результате пользовательский интерфейс Dweep’а оказался не таким красивым, как в других играх, зато он был проще в использовании и работал быстро. Таким образом, я был удовлетворен результатом. Всякий раз, когда вам приходится принимать решение относительно дизайна программы, держите эти цели у себя на виду. Если вы не поставите четких целей, вы будете обречены принять результат таким, каким он получится.
Почти 50% всех ошибок первый раз исправляется неправильно. При этом процесс исправления часто порождает новые ошибки. Никогда не экспериментируйте, просто меняя “x-1” на “x+1”, чтобы посмотреть, не произойдет ли чуда. Потратьте время на поиск и понимание источника ошибки. Много лет назад, когда я был бойскаутом и должен был тушить лагерный костер, вожатый иногда проверял тщательность моих усилий, прося меня положить руку на золу. Я очень быстро научился гасить огонь так, чтобы иметь полную уверенность в его полном исчезновении. Когда вы находите ошибку, это значит, что ваш код горит. И пока ошибка остается, новый код только добавит бензина в этот огонь. Как только вы находите ошибку, бросайте все, что вы сейчас делаете, чтобы устранить ее, и не продвигайтесь дальше до тех пор, пока не будете полностью уверены, что ваше исправление правильно. Если вы не потратили время, чтобы сделать это правильно в первый раз, где вы его возьмете, чтобы делать это снова?
Оценивайте свой код по десятибалльной шкале. Первый раз, когда я это сделал, мой код из 30000 строк получил оценку четыре. Я переписал его худшую часть, чтобы поставить себе восьмибалльную оценку. Это было одним из лучших капиталовложений, которые я когда-либо делал, поскольку после этого я получил возможность добавлять новую функциональность за время, в два раза меньшее, чем до этого. Качество кода – это наиболее четкий показатель качества продукта. Вы можете обнаружить, как и я в свое время, что наиболее удачно продаваемые продукты получают наивысшие оценки за качество.
Обнаружив ошибку, постарайтесь понять, почему вы ее сделали, и попробуйте изменить что-нибудь в своем стиле разработки, чтобы предотвратить ее повторное появление. За годы работы я научился многим простым приемам программирования, которые позволяют мне избегать ошибок, часто допускаемых мной до этого. Есть очень много ошибок, которых я сейчас никогда не делаю просто потому, что мой стиль программирования просто физически не позволяет этого.
Каждое из вышеприведенных правил может показаться простым, однако эффективность достигается за счет их совместного использования. Следуя данным правилам, вы получите четкий процесс разработки, и будете избегать состояния “на 99% сделано” для 80% времени реализации ваших проектов. Высокое качество кода сделает ваши программы легкими в обслуживании и дешевыми в сопровождении. Вы будете тратить гораздо больше времени на написание нового кода, нежели на отладку старого. И, что еще важнее, время необходимое для написания качественного кода, существенно меньше, чем некачественного. Если вы никогда не разрабатывали программы на основе бездефектного программирования, его внедрение позволит вам уменьшить время разработки программных продуктов на 30% или даже больше, одновременно улучшая их качество.
| Сообщений 13 Оценка 983
[+7/-0]
Оценить
|
