tестирование dot com

пании должны проходить инспекции кода (code inspection).

Это может быть еженедельное совещание, например, следующего

формата: менеджер программистов распечатывает код любого из

программистов, и последний в присутствии коллег рассказывает,

что, как и почему. Будет ли программист писать код, понятный

только ему, если на совещании его обязательно спросят: "Това-

рищ, а что это вы здесь написали?"

4. СТАНДАРТЫ ПРОГРАММИРОВАНИЯ

С пунктом 3 перекликается идея создания стандартов програм-

мирования.

92

Тестирование Дот Ком. Часть 1

Пример

Вспомним Вавилонскую башню, а вернее, ТОТ момент строительства,

когда все вдруг стали говорить на разных языках (множественность

стандартов). Последствия печальны: проект был начисто заброшен,

название кинокомедии "Some like it hot" перевели как "В джазе только

девушки" и японские фанатки "Тагу" убеждены, что "Мальчигей" — это

название места для романтических свиданий нетрадиционных девушек

на Красной площади.

Такая же катавасия творится в компании, когда программисты

вроде бы и используют тот же язык, например C++, но при напи-

сании кода каждый руководствуется своими привычками.

Пример

Допустим, что отсутствуют стандарты названия новых классов C++.

S этом случае, если Саня любит называть свои классы в формате

"CREDITCARD" (все заглавные и нижнее подчеркивание), а

Леха — "CreditCard" (заглавные только первые буквы каждого слова

и слитное написание),

то, например, Леха, не зная о привычках Сани, но верный своим при-

вычкам, помня лишь "Кредиткард" и желая обратиться к функции из

CREDITCARD, в своем коде так и запишет: "CreditCard". В итоге код не

будет работать, так как C++, ничего не знающий ни о Лехе, ни о Сане, ни о

кредитных картах, думает о CREDITCARD и CreditCard как об

абсолютно разных классах.

Стандарты могут включать:

• правила о комментариях;

• правила об именах таблиц в базе данных, классов, функций

и различных видов переменных;

• правила о максимальной длине строки;

• прочее.

Документ со стандартами должен быть доступен на интранете.

Стандарты программирования — это неотъемлемая часть

процесса, когда в компании работают два программиста и боль-

ше. Они по определению должны быть обязательны для всех.

5. РЕАЛЬНЫЕ СРОКИ

В стартапе изначально и по определению сроки на разработку

нереальны, и приходится балансировать между

• "поспешишь — людей насмешишь" и

• необходимостью закончить кодирование в срок.

Цикл разработки ПО

93

Несмотря на то что стопроцентно действующих рецептов нет, вот

хорошая идея для облегчения нелегкой жизни программистов:

после ознакомления со спеками программисты должны предос-

тавить менеджменту примерные оценки (сметы) сроков для

разработки кода, и исходя из этих смет менеджмент может,

если нужно

• перераспределить нагрузку и

• посмотреть, имеет ли смысл убирать что-то из менее

приоритетных функционалъностей ради того, чтобы

чисто и тщательно написать остальной код.

Единственное утешение состоит в том, что, когда стартап как

бизнес становится более зрелым, сроки и рабочие часы стабили-

зируются во многом потому, что менеджмент понимает, что луч-

ше дать реальный срок (например, перенеся некоторые из спеков

в следующие релизы), чем поступиться качеством.

6. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ

ВСЕ документы, относящиеся к разработке ПО, включая спеки,

процедуру изменения спека, стандарты программирования, тест-

комплекты, и документы, о которых мы будем говорить в даль-

нейшем, должны быть доступны в локальной сети, и их располо-

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

быстроты поиска. Все должно быть сделано для того, чтобы за-

интересованный сотрудник быстро нашел нужный документ, а не

тратил свое время и время своих коллег на долгие поиски.

Несмотря на кажущуюся очевидность и легковесность этого мо-

мента, несоблюдение правила о доступности ВСЕХ документов

на практике может принести много проблем.

7. ТРЕБОВАНИЯ

К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ

Юнит-тестирование (unit testing) — это тестирование, произ-

водимое самим программистом. Здесь нужно подчеркнуть, что

неправильный подход к введению юнит-тестирования вызо-

вет справедливое раздражение программистов, так как за тес-

тирование платят тестировщикам, а отсутствие требований к

юнит-тестированию вообще увеличит стоимость багов.

94

Тестирование Дот Ком. Часть 1

Постановка мозгов

Стоимость бага — это