Сегодня вряд ли что-то изменилось. Сотрудники, которые ведут учетные книги, по-прежнему ценятся невысоко. Но в их карандашах, маркерах и клавиатурах может скрываться сила, предопределяющая успех или провал разработки программного обеспечения.
Если группы по разработке программного обеспечения ведут какие-то записи, то в архивах и заметках отражаются только результаты и выводы, рабочие продукты или готовые компоненты. Программисты особенно не любят записывать что-нибудь кроме самого кода, если только перед ними не стоит угроза штрафа или тюремного заключения. Заставить их нари-совать диаграммы — это все равно, что заставить слона сделать наброски карандашом. В конце концов, разве не является хороший код самодокументируемым?
Жизненно важная статистика
Такое отношение приводит к потере жизненно важной информации. Вообще говоря, когда сохраняется только конечный продукт, нам известен результат, но мы не знаем, как его получили. Как создавалось программное обеспечение, какие решения были найдены в процессе работы — все это является важным. Можем ли мы полагаться на свою память? Беспокоимся ли мы только об ошибках или вдобавок хотим извлечь из них пользу?
Особые трудности в работе групп, сохраняющих только конечный программный продукт, вызывает отсутствие записей о решениях, от которых отказались. Знать о том, какие методы были отклонены и по каким причинам, часто бывает так же важно, как и о том, какие методы были выбраны. Это жизненно важно в тех случаях, когда готовятся новые версии или системы или когда разработка текущей системы заходит в тупик.
Наверное, вы когда-нибудь рассматривали свой код, написанный несколько месяцев или лет назад. Случалось ли так, что вы находили такие места, которые казались неверными, и вы удивлялись, как же программа вообще могла работать? Если вы поддавались соблазну «исправить» эту скрытую ошибку, как это иногда делал и я, то могли обнаружить, что «исправление» загоняло систему «в угол». Естественно, код только казался неправильным, но сам по себе он не объяснял, почему здесь все в порядке. Не помогут и такие комментарии в коде: «Ничего здесь не меняйте. Это место кажется неверным, но здесь все правильно». Если программист знал, что «здесь все правильно» и почему другой вариант будет неверным, то почему же тогда эта логика не отражена в комментарии? Если мы хотим поддерживать систему не один год или иметь возможность выпустить следующую версию через пять лет после того, как все разработчики первой версии системы будут далеко, нам нужно знать, какие варианты рассматривались, какие были отклонены и почему.
