Такая позиция легкомысленна. Время, которое требуется для поиска причин ошибочной работы программы, часто значительно превышает затраты на рецензирование. Рецензирование кода – разумный и прак% тичный способ управления процессом разработки и обеспечения высо% кого качества программного обеспечения.

Каким образом вы могли бы оказать положительное влияние на ситуа% цию с рецензированием в вашем нынешнем проекте?

2.Есть ли у вас программисты, чей код считается выше того, чтобы быть рецензируемым?

К уважаемому гуру%программисту часто относятся с таким трепетом, что никому и в голову не приходит предложить рецензирование его ра% боты. Или все боятся. Такое почитание ошибочно и опасно.

На мой взгляд, гуру иногда пишут код, более достойный рецензирова% ния, чем код любых других авторов, – полный непонятных и недоступ% ных для сопровождения загадок. То, что они никогда не выставляют свой код для рецензирования, отражает их неправильное отношение к задаче и команде. Ничей код не может быть освобожден от рецензи% рования; весь код должен быть тщательно изучен.

3. Какой процент вашего кода когда либо проходил рецензирование?

Можно не сомневаться, что этот объем невелик, иначе вы выпадаете из общих рядов. Насколько формальными были обсуждения? Насколько полезными они были и какое влияние оказали на качество кода в ко% нечном итоге?

Какая часть вашего кода, не подвергавшегося рецензированию, была написана в паре? Какой объем следовало бы рецензировать? Какая часть непрорецензированного кода была критически важным коммер% ческим кодом? Сколько ошибок проникло в готовый продукт и сколь% ко из них вызвало впоследствии проблемы?

Даже если культура вашего проекта не предполагает проведение ре% цензирования, возьмите себе за правило предлагать делать официаль% ную рецензию вашей работы. Не смущайтесь тем, что никто больше так не поступает – ваш код будет выше среднего уровня!

Глава 21. Какой длины веревочка?

Вопросы для размышления

1.Как спасти отстающий проект и привести его в соответствие с графи ком?

Один из способов не стать свидетелем провала проекта – это как можно скорее бежать из него, как крысе с тонущего корабля. Однако это не очень профессионально!

Если проект отстал от графика, мало что поможет исправить положение – если только в графике не отведено необычно много времени на непред% виденные обстоятельства. Можно попробовать следующие стратегии:

•Изменить сроки проекта; попробуйте договориться с клиентом о бо% лее поздней доставке.

•Изменить объем функциональности первой версии, отложив реали% зацию недостающих функций до следующего выпуска. Лучше сде% лать меньше, но лучше и вовремя, чем реализовывать ненужные функции и отставать от графика.

Не будьте безрассудны и не бросайте на проект новых разработчиков, чтобы ускорить работу. Брукс понятно описал, насколько плоха эта идея, особенно при угрозе провала проекта (Brooks 95). Нынешние разработчики будут отвлекаться на то, чтобы ввести в курс дела но% вых, а руководство большой командой потребует дополнительного труда. Любая прибыль наверняка окажется меньше, чем стоимость до% полнительного персонала.

2.Как правильно реагировать на то, что конечный срок вам устанавли вают до того, как проведено технико экономическое обоснование или планирование?

Будьте благоразумны! Фиксированный срок поставки может быть за% конным деловым требованием: вы получите деньги, если поставите программу вовремя, в противном случае вы не получите ничего. Не всегда удается делать продукт идеологически правильно, отодвинув для этого конечный срок или ограничив объем функций.

Иногда при проектировании полезно заранее знать о предполагаемых сроках завершения проекта. Это поможет определить, насколько пра% вильным и хорошо продуманным может быть ваш проект, оценить объем кода и возможности расширения его в будущем. В конечном итоге, будет ясно, что предпочесть: решение на скорую руку или кра% сиво сконструированный код, который следовало бы писать в идеале. Будет легче решить, что нужно купить, а что изготовить самостоя% тельно, а также установить уровень качества, которому должен соот% ветствовать конечный продукт.

Разъясните, что такой способ разработки программного обеспечения неидеален. Возможно, к вам прислушаются, и впредь ваши менедже% ры не будут обещать поставок в такие рискованные сроки; это легко% мысленное поведение, в котором на карту ставятся успех проекта и бу% дущее организации.

3. Как обеспечить реальную пользу плана разработки?

Для высококачественных планов разработки характерны:

Точность

Они включают в себя задачи, необходимые для постройки про% граммного продукта, и основаны на разумных временных оценках.