Что не следует делать при создании программного продукта

Это перевод Things not to do when writing software. Автор: Ларри Остерман.

Я решил начать со старой боевой истории. ДЕЙСТВИТЕЛЬНО старой истории. Из далёких дней Windows 1.0. Что-то такое, что никогда не случится в эти дни.

Примерно 2 месяца до выхода Windows 1.0 в свет (так что сейчас на дворе август/сентябрь 1985-го). Microsoft объявила о Windows за 18 месяцев до этой точки, и мы попали в тиски прессы о vaporware. Поэтому команда разработчиков была под огромным давлением, чтобы выпустить Windows так быстро, как это вообще возможно в человеческих силах и с максимальным набором функций.

Во всяком случае, как я уже сказал, было около 2 месяцев до времени отгрузки коробок. А разработчик, который был ответственен за менеджер памяти Windows, вошёл в понедельник утром и объявил, что он только что сделал commit новой версии менеджера памяти, которая поддерживает сброс перемещаемых блоков памяти с данными на диск (до этого момента Windows имела возможность удалить сегмент кода из памяти при её нехватке и перезагрузить его позже, если в нём будет необходимость - но не было аналогичной возможности для сегментов данных).

Стив Балмер, который был главным разработчиком проекта в тот момент, мог только сказать: “Ok, я хочу уволить SOB. Я ОЧЕНЬ хочу уволить SOB, но нам нужна эта возможность”. (прим.пер.: понятия не имею, как переводится SOB. В голову не приходит ничего лучше SOB = Son of a bitch = "этого сукиного сына").

Что не следует делать при создании программного продукта, часть 2

(Сначала я хотел сделать это отдельным постом, но потом решил объединить всё в один пост, потому что это покажет обратную сторону монеты).

Вот ещё одна история о Windows 1.0. В этот раз - о системе печати. Разработчик системы печати, видимо, был впечатлён примером выше, поэтому он решил переписать систему печати в Windows за 2 недели до отправки в производство.

Тогда чаще всего разработчик тестировал печать открытием файла в Блокноте, печати его на матричном принтере Epson MX-80 в своём офисе, и, если это работало, он делал commit изменения. Но Windows 1.0 поддерживала много возможностей шрифтов, которые Блокнот не использовал. Вещи вроде шрифтов с переменной шириной. Жирный текст и курсив. И подчёркивание. Соответственно, ничего из этого обычно не тестировалось.

Ну, Linne’ Puller, глава тестирования печати в Windows, был просто в ужасе, когда он узнал об этом изменении и молил, чтобы ему дали возможность протестировать его прежде, чем изменение войдёт в финальный исходный код Windows. Разработчик системы печати согласился, но он не видел в этом смысла - ведь он уже хорошо протестировал своё изменение.

Linne и Valorie Holden (другой тестер системы печати в Windows) работали всю ночь, а на следующее утро они вошли в кабинет разработчика и плюхнули ему на стол стопку бумаги высотой в фут (около 30 см).

“Ага, это результаты тестов, да? Это ж огромная куча бумаги - вы не могли выбрать отсюда только примеры с ошибками?”

“Нет, потому что всё это - и ЕСТЬ ошибки”.

“Ой”.

Разумеется, это изменение не вошло в финальную версию. В очередной раз тестеры спасли разработчиков.

И теперь - полный отказ от ответственности, прежде чем мой пост будет взят в качестве доказательства, что в Microsoft не умеют работать: это старая боевая история. Ей уже больше двадцати лет. Команда Windows в те времена была известна как группа ковбоев (что, на самом деле, и является причиной, почему Стив Баллмер в итоге оказался отвечающим за группу).

Microsoft стала намного лучше в разработке программного обеспечения за эти двадцать лет. Даже в тот момент было очевидно, что обе ситуации - это примеры того, что люди не должны делать, а не примеры фактов, которые случаются постоянно.

Сегодня, задолго до того, как проект попадает в состояние, которое было тогда в Windows, проект ПЛОТНО блокируется. Все новые функции и возможности рассматриваются советом по DCR (Design Change Request - запрос на изменение дизайна), который состоит из разработчиков, управленцев И тестировщиков. И все три должны поставить своё согласие до начала кодирования новой функции.

Кроме того, команда тестирования принимает непосредственное участие в разработке новых функций. Как минимум, до того, как значительные изменения будет внесено в исходники, происходит процесс, который прошли Linne и Valorie. Теперь он официально закреплен в то, что мы теперь называем "smoke tests". Каждая группа в Microsoft имеет свою версию этих тестов (и некоторые называют их по-своему: buddy build или private tests), но все они имеют некоторую форму процесса, который позволяет команде тестировщиков наложить вето или комментарий на качество изменения. Возможно, потом я напишу, как выглядит у нас “обычный” день изнутри...

Обязательное личное замечание: Valorie Holden была летним стажёром, чья стажировка растянулась до декабря - она была моей подругой в колледже, которая пришла на летнюю подработку в Microsoft тестировщиком. Мы обручились в декабре 1985 года. И мы счастливо женаты на протяжении последних 17-ти лет.