В своей сфере производства программного обеспечения я работаю от шести месяцев до двух лет над созданием и выпуском новой компьютерной игры. Я могу продавать продолжения или наборы расширения, но обычно я не могу продавать комплекты расширения так же, как другое программное обеспечение. Когда я выпускаю новую игру, я должен убедиться в том, что она очень высокого качества, потому что мои покупатели не должны думать о поиске программного усовершенствования. Из-за короткой продолжительности жизни большинства компьютерных игр и их зависимости от быстро сменяющихся технологий мои возможности улучшить выпущенный продукт на основе отзывов покупателей минимальны. Чтобы разобраться с этими вопросами, я постепенно заимствовал систему практики контроля качества, которая позволила мне значительно повысить качество продукта, а также сократить время разработки.
Понимаемая не как «безошибочная», Zero-Defect Software Development (ZDSD) является практикой разработки программного обеспечения, которая поддерживается на высоком уровне качества в течение всего процесса разработки. «Погрешности» - это аспекты развивающегося программного обеспечения, которые были бы непригодны для конечного продукта как такового. Это ёмкое определение включает в себя ошибки, а также нежелательные отклонения от желаемого конечного результата. К погрешностям разработки компьютерной игры относятся неотшлифованная картинка, неприемлемо низкая скорость фреймов в целевой системе; уровни, которые недостаточно увлекательны либо какое угодно число недоработанных возможностей.
Основной принцип ZDSD таков: поддерживайте продукт на таком уровне качества в течение всего процесса разработки, который вы считаете лишённым погрешностей. Это звучит просто, но на практике это делается редко. Самый распространённый подход – это отложить главное тестирование до завершающей фазы контроля качества разработки программного обеспечения, где дефекты зачастую обнаруживаются впервые. Большинство ошибок не выявляется или не исправляется ещё долго после их введения. Чем дольше дефект остаётся невыявленным, тем труднее его исправить. У крупных продуктов программного обеспечения каждая стадия разработки, на которой дефект сохраняется, будет повышать цену его исправления в 10-50 раз. Исправление дефекта, введённого на этапе конструкции, может стоить в сотни раз больше на испытательном этапе, чем в случае его исправления сразу после введения.
Фокусируясь на качестве продукта на протяжении всего цикла разработки, вы фактически дорабатываете продукты быстрее, чем если бы вы не обращали на это внимания вплоть до завершения проекта. Общее правило качества программного обеспечения контринтуитивно: повышение качества фактически сокращает время разработки. Это происходит потому, что вы исключаете трату времени на исправление ошибок и переработку кода, что может составлять 50% стоимости разработки крупного проекта. Типичный программист пишет от восьми до двадцати строк кода в день; оставшуюся часть дня он, как правило, тратит на устранение ошибок. ZDSD сокращает график работы, исключая трату времени на устранение ошибок. Обширные исследования, проведённые в NASA, IBM и других организациях, показали, что улучшение контроля качества ведёт к сокращению рабочего расписания. Из исследования IBM следует, что у проектов, в которых качество становится высшим приоритетом, самые краткосрочные расписания, самая высокая продуктивность и даже самые лучшие показатели продаж. Вот десять основных правил ZDSD.
1. Испытывайте свой продукт каждый день, пока занимаетесь его разработкой, и исправляйте дефекты сразу после обнаружения.
Ежедневно проводите испытания сборки. В конце каждого дня, пока вы работаете над своим проектом, создавайте текущую версию вашего программного обеспечения и испытывайте её на основную функциональность. Корпорация Microsoft усиленно внедряет эту политику, используя большие команды для сборки каждого проекта на ежедневной основе. Программисту, чьё кодирование приводит сборку в неисправность, могут позвонить в середине ночи и заставить вернуться к работе, чтобы немедленно устранить проблему. Разработчикам, занятым в небольших проектах, исполнять это правило гораздо проще. В конце каждого дня испытывайте вашу программу в течение как минимум десяти минут. Составьте список всего, что вы бы сочли за «погрешность» и возьмите за правило исправлять все дефекты, прежде чем вводить в работу новые возможности. Когда вы находите дефект, его исправление становится вашим приоритетом № 1, и вы не пишете новый код до тех пор, пока погрешность на 100% не устранена.
2. Регулярно просматривайте ваш код.
Большинство людей думает о контроле качества как о тестировании, но на самом деле тестирование является одной из наименее рентабельных стратегий обнаружения ошибок. При самом строгом тестировании обычно удаётся обнаружить менее 60% всех ошибок в программе, а некоторые виды недочётов вообще редко удаётся выявить тестированием. Согласно исследованиям, проведённым во многих крупных организациях, занимающихся программным обеспечением, проверка кода – куда более рентабельная методика, нежели тестирование. Исследование, проведённое NASA, показало, что чтение кода выявляет за час почти вдвое больше дефектов, чем тестирование. Когда бы вы ни добавили несколько сотен строк нового кода к вашему проекту, выделите час или два на то, чтобы перечитать работу и выяснить, нет ли в ней ошибок. Один час просмотра кода заменяет два или более часа методичного тестирования. Пока вы только приобретаете опыт, ведите список дефектов, которые вы обнаруживаете, и прибегайте к нему всякий раз, как просматриваете новый код. Чтобы найти ещё больше недочётов, попросите также кого-нибудь другого прочитать ваш код.
3. Переписывайте модули низкого качества.
Не всякий ли раз, когда вы обнаруживаете новый неизвестный дефект, вы восклицаете: «О, нет! Пожалуйста, пусть только это будет не в этом модуле!»? Все мы наследуем чудовищные модули кода, которые были написаны в ту пору, когда мы ещё не были столь опытными программистами, каковыми являемся сейчас. Не пугайтесь их – переписывайте их. Часто решение о более разумном подходе лишь тогда становится чётким, когда неполноценное решение проблемы уже отработано. Это совершенно справедливо в отношении Джона Кармэка, который использовал дюжины различных подходов при написании кода для разработки Quake, прежде чем нашёл тот единственный, который соответствовал его критериям. Дефекты не будут равномерно распределены в вашем коде. Обычно вы будете обнаруживать, что 20% вашей практики ответственно за 80% ваших ошибок. В моих программах более всего подвержены дефектам обычно модули, которые взаимодействуют с аппаратурой или с драйверами третьих лиц, особенно DirectX. Повысьте ваши стандарты для тех модулей, которые, как вам кажется, производят нескончаемый поток дефектов, и найдите время на то, чтобы переписать их с нуля. Вы можете заметить, как в результате другие нерегулярные ошибки совершенно исчезают.
4. Принимайте всю ответственность за каждую ошибку на себя.
95% всех погрешностей программного обеспечения возникает по вине программиста. Только 1% дефектов – это ошибки аппаратуры, а оставшиеся 4% вызваны компилятором, OS или другим программным обеспечением. Никогда не отклоняйте потенциальную ошибку; выясняйте точную причину возникновения всякого отклонения. Когда в ходе одной миссии на Марс во время полёта произошли серьёзные нарушения в работе программного обеспечения, выяснилось, что такое же нарушение имело место лишь однажды при испытаниях на земле, но инженеры списали его на временный перебой аппаратуры. Если ваша аппаратура не пьёт газировку, с ней не случается перебоев.
5. Вносите изменения эффективно.
Вы всегда будете думать о том, чтобы добавить новые большие возможности после того, как приступили к кодировке. Тщательно взвесьте в уме, как каждое нововведение может повлиять на предшествующий вариант кода. Неумелое объединение непредвиденных возможностей – главная причина возникновения дефектов.
6. Переписывайте весь макетный код с нуля.
Иногда вы можете быстро создать макет новой возможности, чтобы выяснить, будет ли она жизнеспособной. Делается это зачастую в ущерб качеству кода и во имя скорой разработки. Если вы окончательно решили сохранить данную возможность, существует большой соблазн проверить макетный код только на наличие базисных ошибок. Не попадайтесь в эту ловушку. Если вы с самого начала писали код без ориентации на качество, удалите макетный код и реализовывайте возможность с нуля. Наскоро спланированные возможности, попадающие в конечный продукт, - главный источник ошибок, так как они не подлежат тем же стандартам качества, что и остальная часть кода.
7. Ставьте цели контроля качества в начале каждого проекта.
Исследования показали, что разработчики, которые ставят разумные цели контроля качества, обычно добиваются их. Решите заранее, должен ли ваш проект быть скоростным, компактным, с богатыми возможностями, рассчитанным на интуицию, со ступенчатой структурой и т. д. Затем распределите приоритеты этих целей. Когда я проектировал код интерфейса для Dweep, я решил, что тремя моими главными приоритетами при создании интерфейса будут ориентация на интуицию начинающих, скорость и увлекательность – в таком порядке соответственно. Интерфейс Dweep не так богат на графику, как другие игры, но зато проще в использовании и обладает чрезвычайно быстрой реакцией, и я был доволен результатами. Когда бы вам ни пришлось принимать решение в отношении дизайна, держите свои цели в уме. Если вы не поставите чёткие цели контроля качества, вы обречены на получение случайных результатов.
8. Не торопите работу по устранению ошибок.
Полных 50% всех исправлений ошибок сделано в первый раз неправильно, часто с попутным введением новых ошибок. Никогда не экспериментируйте, изменяя "x-1" на "x+1", просто чтобы посмотреть, сработает ли это. Не щадите времени на то, чтобы выяснить источник ошибки. Много лет назад, когда я был мальчишкой-скаутом и в мои обязанности входило тушение костра, предводитель скаутов частенько проверял мою добросовестность тем, что просил положить руку в золу. Я быстро выучился тушить костёр так хорошо, чтобы быть абсолютно уверенным в том, что он на 100% погашен. Когда вы обнаруживаете дефект, это означает, что ваш код горит. Пока дефект не устранён, любой новый код, написанный вами, будет только подливать масла в этот огонь. Всякий раз, как вы находите дефект, бросайте всё, чтобы исправить его и не двигайтесь с места, пока не будете стопроцентно уверены в том, что исправление сделано грамотно. Если вы пожалеете времени на то, чтобы сделать это правильно с первого раза, то когда вы отыщете время, чтобы это переделать?
9. Поставьте качество вашего кода на тот же уровень значимости, что и качество самого продукта.
Оцените ваш код по десятибалльной шкале на качество в целом. Когда я впервые сделал это, я оценил свой проект на 30 000 строк на 4 балла. Я переписывал худшие фрагменты кода до тех пор, пока не достиг 8 баллов. Это было одним из лучших вложений времени, когда-либо сделанных мной, так как я сумел тогда добавить новые возможности и удвоить предыдущую оценку. Качество вашего кода во многом свидетельствует о качестве вашего продукта. Вы можете, так же, как и я, обнаружить, что самые продаваемые продукты получают также и самые высокие оценки по качеству кода.
10. Учитесь на каждой своей ошибке; она представляет собой недочёт, допущенный вами.
Выясните, почему вы допустили ту или иную ошибку, и разберитесь, можете ли вы изменить что-то в практике вашей разработки, чтобы устранить её. За годы работы я усвоил много приёмов кодирования, которые позволяют мне избегать самых общих ошибок, обычно досаждавших мне в прошлом. Со многими видами ошибок я больше уже никогда не сталкиваюсь, потому что мой стиль кодировки исключает физическую возможность того, что я их допущу.
Каждое из этих правил представляет собой простое понятие, но их объединённые преимущества значительны. Вы будете достигать видимости большего прогресса, избегая такой ситуации, когда сделано 99% работы за последние 80% отведённого времени. Более высокое качество облегчит обслуживание вашего продукта и сделает менее дорогостоящей его поддержку. Вы будете тратить меньше времени на устранение ошибок старого кода и больше времени на написание нового кода. А самое главное, написание высококачественного кода фактически занимает меньше времени, чем написание кода низкого качества, так что вы сэкономите в целом гораздо больше времени при разработке. Если вы никогда не занимались разработкой, руководствуясь философией ZDSD с первого дня, то её принятие может сократить вам время разработки новых продуктов до 30% или более и одновременно повысить качество продукта.
