Путь камикадзе



         

Средства и процессы - часть 3


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

Едва ли кто-нибудь станет возражать против использования усовершенствованных технологий, позволяющих избавляться

от рутинных и утомительных процессов. Гораздо труднее внедрить новую технологию, требующую введения новых

процессов или модификации

существующих процессов, к которым мы привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно используемых компонент, броузеров и других средств. Проектные команды, использующие эту технологию, могут повысить уровень повторного использования кода приблизительно от 20 процентов (уровень, который я называю «случайным») до 60 процентов и более; разумеется, если технология используется в масштабе всей организации, то уровень повторного использования может достигать 80-90 процентов и более.

Разница между 20-процентным и 80-процентным уровнем повторного использования эквивалентна четырехкратному повышению производительности. Как отмечено в [2], постепенное последовательное повышение уровня повторного использования приносит больше выгод, чем можно было бы ожидать. Если уровень повторного использования возрастает с 80 до 90 процентов, это означает, что вместо разработки «с нуля» 20 процентов кода проектной команде придется разрабатывать только 10 процентов. Таким образом, их загрузка снизится вдвое.

Все это замечательно - и вполне достойно называться «серебряной пулей» - но совершенно бесполезно, если проектная команда (и в конечном счете вся организация) окажется неспособной или не пожелает менять свои процессы в соответствиями с требованиями технологии повторного использования. Ирония заключается в том, большинство организаций поставят в вину самой технологии свои собственные провалы: они приобретут дорогостоящую библиотеку классов или поменяют свою старую методологию разработки ПО на объектно-ориентированную методологию, исходя из предположения, что объекты и повторное использование - это одно и то же; когда они в конечном счете обнаружат, что не добились сколько-нибудь ощутимых результатов, то будут винить во всем объектную технологию, библиотеку классов, поставщика и др.


Содержание  Назад  Вперед