Читать онлайн «Человеческий фактор в программировании». Страница 52

Тем не менее, как говорится, был еще не вечер.

По результатам начальной оценки на последнем месте оказалась команда из Xpedite Professional Services Pty. Ltd. под руководством Сью Стивене (Sue Stevens). Пока другие команды усердно наращивали функциональность, они сосредоточились на деталях и тщательно продумывали код, направив все усилия на обработку ошибок и исключений. Однако этот метод, очевидно, не подходил для чрезвычайно плотного цикла разработки, установленного на соревновании. На полпути команда Xpedite решила поменять свою стратегию.

Когда подошло время финальной оценки, команда Ernst amp; Young начала объединять различные компоненты своей методично построенной системы. В спешке, когда все файлы переносились на одну машину, они нечаянно записали черновые версии поверх рабочих файлов. Мы все совершали такую ошибку, случайно перепутав направление копирования. Я и сам совершил ее всего за несколько месяцев до этого, когда переносил файлы Power Point, созданные для другой конференции. К счастью, у меня были резервные копии. К несчастью, у команды Ernst amp; Young их не было. Затерев большую часть своих данных, к финалу они пришли с меньшим количеством функциональных пунктов по сравнению с результатами в середине соревнований.

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

Итак, что же можно извлечь из опыта этих доблестных команд? Более чем когда-либо очевидно, что быстрое создание прототипов не может заменить методичность в работе. По существу, именно сочетание инструментов быстрого визуального проектирования (см. главу 23) с разумным процессом анализа и разработки будет более эффективным при слишком сжатых сроках. Время, затраченное на осмысление и планирование, экономит время на разработку.

Также следует помнить о том, что именно мы разрабатываем. Мы производим не код, мы производим продукт. Большая польза и небольшой код намного ценнее, чем большой код и малая польза. Сырая функциональность менее ценна для наших клиентов, чем простые в использовании системы, которые отвечают потребностям их бизнеса.

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

И наконец, еще об одном, хотя это и кажется очевидным. Хорошее управление версиями необходимо даже при очень коротких циклах программной разработки. Даже под непомерным давлением сроков — или, возможно, особенно под таким давлением — время, затраченное на создание резервных копий и версий, идет только на пользу. По сути, управление резервными копиями и версиями было необходимо включить в ускоренный метод разработки, применявшийся командой Ernst amp; Young. Именно это они и пообещали сделать к следующему соревнованию.

Из журнала Software Development, том 3, № 10, октябрь 1995 г.

Что произошло с архитектурой программного обеспечения? В типичном приложении для малого бизнеса или в стандартном коммерческом пакете зачастую бывает трудно обнаружить присутствие хоть какой-то структуры. Архитектура — будь то внутренняя функциональная структура или структура пользовательского интерфейса — сегодня часто оказывается первой жертвой сжатых по времени разработок, коротких периодов между релизами и быстрого проектирования приложений. Иногда просто не остается времени на обдумывание всех последствий архитектурных решений. Зачастую едва хватает времени на то, чтобы просто подумать. Приехали. Системы собираются сразу, как только придумываются их новые компоненты, без особого внимания к общей структуре. Темпы настолько высоки, что разработчики не видят дальше следующей строки кода или следующего элемента.

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

Добавьте к быстрому созданию прототипов итеративную доработку, и последние остатки архитектуры могут утонуть в программном болоте. Это вызывает сожаление, потому что итеративное создание прототипов является мощным методом для разработки более удобного программного обеспечения за меньшее время. Создание прототипов позволяет своевременно поставлять функциональные программы или перепробовать различные подходы. Прототипы компонентов необходимы для получения отзывов пользователей, основанных на их реальных потребностях. Даже при создании пользовательского интерфейса для относительно скромных систем все предусмотреть с первого раза невозможно. Это не зависит от того, сколько времени и сил вы затратили на проектирование. Создание прототипов и итеративная доработка дают второй шанс (а также третий и четвертый) для того, чтобы довести до ума интерфейс пользователя. С каждой новой итерацией интерфейс и его внутренние компоненты становятся качественнее и функциональнее, обеспечивая все большие возможности и большую эффективность.

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