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

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

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

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

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

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

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

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

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

• прочее.

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

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

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

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

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

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

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

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

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

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

93

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

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

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

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

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

если нужно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

94

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

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

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

• расходы компании, чтобы найти баг и исправить его до пе-

редачи кода пользователю. Расходы компании поддаются

приблизительной оценке;

• убытки, которые несет компания, потому что баг не был

найден до передачи кода пользователю. Объективная оценка

убытков в большинстве случаев невозможна.