Применимы ли традиционные принципы проектирования программного обеспечения к Internet, где все совершенно иначе? Свою точку зрения на этот счет высказывают девять ведущих разработчиков прикладных систем, имеющих богатый опыт создания программных систем. Некоторые из них - сторонники традиционных принципов проектирования приложений, другие сосредоточены на разработке систем на основе Internet-технологий.
«За 30 лет своей деятельности в сфере проектирования программного обеспечения я четко уяснил одну вещь: разработчики - всегда заложники модных течений. Появляется новая многообещающая технология, и мы бросаем все (по крайней мере пытаемся) и отдаемся ей полностью, начисто забывая уроки прошлого. Последняя такая «горячая» новинка - разработки на базе Internet», - такими словами открыл дискуссию Роджер Прессман.
 Роджер Прессман (Roger Pressman, pressman@rspa.com, http://www.rspa.com) в разное время занимался разработкой ПО, работал менеджером, сейчас он профессор и консультант по вопросам проектирования ПО. Он является автором шести книг и редактором колонки менеджера в журнале IEEE Software. Его книга "Software IEngineering. A Practionier's Approach" получила широкое признание в качестве руководства по проектированию прикладных систем. |
Поэтому первый вопрос: могут ли системы на базе Internet проектироваться в привычном смысле этого понятия? И если нет, то чем они так отличаются от остальных программных продуктов?
Тед Льюис: Мир Web отличается только тем, что в нем значительно сокращается время разработки и цикл жизни продукта. Вместо того, чтобы оценивать затраты на создание тщательно специфицированной системы, разработчики вынуждены прикидывать возможные качественные характеристики продукта, который просуществует весьма ограниченный промежуток времени.
 Тед Льюис (Ted Lewis, lewis@cs.nps.navy.mil) - член совета IEEE Computer Society Board of Governors, в прошлом главный редактор журналов Computer и IEEE Software, а сейчас - помощник редактора IEEE Internet Computing. Его публикации можно прочитать в журналах Computer, Открытые Системы, Scientific American и ряде других. Последняя книга Льюиса - "The Friction-Free Economy: Marketing Strategies for a Wired World" (Haper Collins, 1997). |
Правила разработки в Web должны быть иными, понадобятся новые, более быстрые инструментальные средства - принципы планирования и проектирования определяются назначением конкретного проекта. Это не означает, что классические методы совсем не применимы или что мы должны создавать Web-узлы исключительно на Perl. Это означает лишь то, что придерживаться твердых принципов проектирования программного обеспечения в Web, как правило, слишком сложно. Нам придется приспосабливать привычные методы к темпам жизни в Internet.
 Бен Адида (Ben Adida, ben@mit.edu) - аспирант MIT, изучает проблемы криптографии и сетевой защиты. С 1995 года участвует в создании средних и крупных систем на базе Web и Internet - от каталогов товаров компании Hearst для электронной коммерции до системы тайного голосования в MIT. Спектр его интересов включает программирование на Java, вопросы защиты и разработки Web-узлов с интерфейсами и базами данных. |
Элен Ульман: Однако не все компоненты Web-приложений создаются за рекордное время. Конечно, сегодняшние Web-страницы - вещь непостоянная, почти одноразовая; быстрые темпы разработки актуальны прежде всего для пользовательского интерфейса. Однако многие другие аспекты Web-приложений, например организация внутренних баз данных - это разработки долгосрочной перспективы, достаточно стабильные и изменяющиеся не часто.
 Элен Ульман (Ellen Ullman, ullman@well.com) возглавляет компанию NeoLogica, предоставляющую услуги инженерного проектирования начинающим компаниям. Ульман является автором книги «Close to the Machine: Technophilia and its Discontents». Ее книги и статьи, посвященные профессиональной разработке программного обеспечения, выходили в изданиях Harper's, Salon и в сериях Pesisting the Virtual Life и Wired Woman. |
Том Демарко: Всякий раз, когда появляется очередная новинка, ее приверженцы твердят одно и то же: «Это изменит все, старым методам пора в утиль». И в этом утверждении есть зерно истины, иначе оно не было бы столь соблазнительным - новые способы разработки, новые инструментальные средства, новые поколения аппаратных систем всегда требуют адаптации старых методов. Однако те их элементы, которым действительно необходима адаптация, как правило, совсем незначительны по сравнению с тем, что с успехом можно применять - в частности, когда речь идет о применении методов проектирования до сетевой эры к разработке на базе Web. Как бы не выплеснуть с грязной водой и ребенка.
 Томас Гилб (Thomas Ghilb, gilb@acm.org) - независимый консультант, преподаватель и писатель, работающий в Европе и США. Его перу принадлежит работа «Principles of Software Engineering Management», и он является основным автором книги «Software Inspection». Гилб специализируется на вопросах качественного проектирования и управления программным обеспечением. |
Том Гилб: Приложения на базе Internet необходимо «проектировать». следует определить несколько важнейших качественных показателей, а затем на их основе, а также исходя из соображений стоимости и других факторов построить приемлемую архитектуру системы. В ходе постепенного развития необходимо регулярно проверять ее на соответствие последним изменениям, внесенным в исходные базовые требования. Если этого не делать, существенно повышается риск получить неудачный проект, поскольку не будет правильного представления о том, для чего собственно он создается.
Брент Горда: Я не думаю, что навыки традиционного проектирования программного обеспечения окажутся в Web бесполезны. Наоборот, по моему убеждению, возможности ускоренной разработки и публикации в Web повышают значимость методов «tried-and-true».
 Том Демарко (Tom DeMarco, demarco@atlsysguild.com) - глава консультативной компании Atlantic Systems Guild, которая специализируется на вопросах управления проектами и судебных разбирательствах, связанных с программным обеспечением. Демарко является автором шести книг о методах разработки и управления программными системами, среди которых "The Deatline: A Novel about Project Management" (Dorset House, 1997). |
Я пришел к выводу, что сокращенный цикл разработки заставляет программистов игнорировать такие элементы проектирования, как ПО управления версиями или циклы оценки качества, поскольку на них приходится тратить время. Они заверят вас, что понимают важность подобных методик, но оправдают себя сентенциями типа: «Этот вариант системы лучше последней версии, а завтра у нас будет готов новый код, так что все ошибки, какие найдем, мы потом исправим».
Однако вы ведь не будете ехать дольше, если пристегнетесь ремнем безопасности - ежедневное использование жестких принципов и средств не затянет разработку. Человеку свойственно лениться, однако опытные разработчики оценили значение всех этих проверенных временем привычек. Многие из них работают в Web и создают прекрасные сайты и инструментальные системы.
 Том Демарко (Tom DeMarco, demarco@atlsysguild.com) - глава консультативной компании Atlantic Systems Guild, которая специализируется на вопросах управления проектами и судебных разбирательствах, связанных с программным обеспечением. Демарко является автор |
Уотс Хамфри: Такие принципы разработки, как «спланировать, прежде чем проектировать, и спроектировать, прежде чем реализовать», пережили все радикальные технологические перемены, переживут и эту. Мы выдвигаем те же самые аргументы, что и при переходе к символьным ассемблерам, языкам высокого уровня, удаленным вычислениям, интерактивным вычислениям и персональным компьютерам. А проблема, на самом деле, в том, что мы не проявляем достаточного усердия в пропаганде и применении глубоко продуманных принципов проектирования. В результате множество разработчиков просто не представляют себе, насколько эффективным может быть использование этих принципов. Мы много узнали о новой технологии и о том, как ею управлять, однако я пока не вижу ничего такого, что могло бы реально препятствовать применению базовых принципов проектирования.
 Уотс Хамфри (Watts Humphrey, watts@sei.cmu.edu) работает в Институте проектирования программного обеспечения (Software Engineering Institute, SEI) университета Карнеги Меллона, где он создал программу Process Program, провел начальный этап разработки Software Capability Maturity Model, а также инициировал такие проекты, как Software Process Assesment, Software Capability Evaluation и самый последний проект - Personal Software Process. Хамфри перешел в SEI после 27 лет работы в IBM различных должностях, в том числе в качестве менеджера разработки коммерческого ПО. |
Рей Джонсон: Сокращение времени выхода на рынок и многие другие характеристики разработки в Web присущи отнюдь не только Web-приложениям. Надо учитывать накладные расходы на разработку, но они не могут стать причиной для полного отказа от базовых принципов проектирования программ. По моим наблюдениям, создатели Web-приложений полагаются на действительно высококлассных и очень трудолюбивых разработчиков - это можно назвать методом «грубой силы». Однако, если проект окажется слишком скучен, и к нему не удастся привлечь лучших разработчиков, то этот метод уже не сработает. Лучше выбрать такую модель проектирования прикладной системы, которая будет соответствовать динамичному, быстро развивающемуся миру разработки в Web.
Тед Льюис: Наверно, мои высказывания прозвучат диссонансом в хоре участников этого обсуждения. «Старомодные» принципы проектирования программ, которые появились в результате начатого в 70-е годы движения за структурное программирование, сегодня уже не действуют, так зачем мы пытаемся навязать их новому поколению Web-разработчиков? Сегодняшние Web-программисты стремятся порвать со старой школой, внося элемент искусства в процесс разработки. Они знают, что задача не будет четко определена и специфицирована; что их заказчики не смогут точно сформулировать свои требования; и что, по большому счету, это и не имеет особого значения, поскольку как только система будет завершена, она устареет. Модель «водопада» умерла, спиральная модель доживает последние дни, и сейчас ставка делается на быстрое прототипирование. Законы дарвинизма заставили разработчиков применить метод «свободного полета» к созданию программ на базе Web, что приводит в состояние нервного напряжения приверженцев традиционной «структурной» разработки.
 Рей Джонсон (Ray Johnson, rjohnson@scriptics.com) - старший разработчик в недавно образованной компании Scriptics, которая занимается созданием инструментальных средств для программирования на языке сценариев Tcl. В сферу его интересов входят языки программирования, инструментальные пакеты для создания пользовательских графических интерфейсов, Internet-агенты и мобольные коды. Прежде чем перейти в Scriptics, Рей занимался исследовательской работой в Sun Microsystems Research Laboratories. |
Тед Льюис: Совершенно верно. Разрабатывая Web-ориентированные приложения, мы решаем те же самые проблемы, которые стояли перед нами в эпоху мэйнфреймов. И я считаю, что мы так и не нашли их решения. А то, что теперь мы делаем проекты для Web, вовсе не означает, что мы приблизились к разгадке.
Бен Адида: Тед затронул очень важный момент - неопределенность задачи. Нам нужен такой подход, при котором мы будем иметь большую свободу действий и сможем приспосабливаться к изменениям в проекте.
Элен Ульман: Технари каждого поколения уверены, что они оказались в уникальной ситуации. Сегодня в этом убеждены Web-разработчики, до них в это свято верили создатели распределенных систем, систем клиент-сервер, интерактивных систем, повторно вводимых кодов и так далее. И каждое поколение было по сути право: все, что они делали, действительно коренным образом отличалось от сложившихся ранее «традиций» прикладной разработки. Но тем не менее за поддержкой они всегда обращались к уже устаревшим инструментам, основанным на технологиях предыдущего поколения. Так что если прямо отвечать на поставленный вопрос - то нет, системы на базе Internet нельзя проектировать в «традиционном» смысле этого слова, так же как никакую систему, в основе которой лежит недавно возникшая, передовая технология, нельзя создать с помощью традиционных средств разработки. В деле создания программного обеспечения всегда будут существовать разногласия между передовыми архитектурами и «правильными» принципами проектирования систем.
Формула успеха
Прессман: Итак, у нас оформились две «школы». Сторонники одной из них считают, что скорость разработки и технологическая новизна делают создание Web-систем процессом, совершенно отличным от предыдущих разработок, и тем обосновывают использование уникальных методов проектирования этих программных продуктов. Другие полагают, что применение твердых принципов проектирования важнее каких бы то ни было отличий в разрабатываемых технологиях.
Обе точки зрения, в принципе, верны, и отсюда вытекает следующий вопрос: как проектировать системы, которые часто реализуются разработчиками- неспециалистами, динамичны и должны появиться на свет за несколько дней, а не месяцев? Или сформулируем его по-другому: что вы можете посоветовать организации, которая должна создавать все более сложные Web-системы и так, чтобы они заработали сразу и навсегда?
Адида: На самом деле, вопрос состоит в следующем: как в считанные дни сделать систему, масштабируемую до бесконечности. Не уверен, что найдется специалист, который сможет дать исчерпывающий ответ. Однако, возможно, окажутся полезными несколько простых правил. Прежде всего, поищите среди уже существующих решений. Если вам нужно хранить информацию с возможностью динамического поиска или редактирования в интерактивном режиме, возьмите реляционную базу данных. Для того чтобы обеспечить масштабируемость, организуйте соединение с ней посредством какого-либо стандартного протокола (например, ODВC), и тогда вы сможете за несколько месяцев заменить небольшую базу данных таким монстром, как Oracle. Во-вторых, отделите, насколько это возможно, информацию от функциональности. Это правило может показаться очевидным, но оно слишком часто игнорируется. Третий и наиболее важный принцип - используйте такую среду разработки, в которой сможете все делать быстро. Забудьте о больших программах на Си, которые придется перекомпилировать при каждом изменении. Языки сценариев, встроенные в программное обеспечение Web-сервера - как раз то, что вам нужно.
Демарко: Все системы надо разрабатывать в кратчайшее время. Web-продукты в этом смысле ничем не отличаются от остальных, за одним исключением: Web переполнена режущими глаз своей роскошью страницами, которые при этом содержат мало по-настоящему ценной информации. Конечно, если вы делаете такую «конфетку», то лучше действовать максимально быстро. Но давайте посмотрим на настоящие Web-системы, такие как Alta Vista, E-Trade или FedEx. Кто станет возражать, что для таких систем необходимо настоящее проектирование?
Ульман: Не могу согласиться с этим утверждением. Фасад Web-страниц действительно часто выглядит довольно кричащим, и в определенном смысле не имеет большого значения, какими средствами вы будете пользоваться для его создания. «Детские игрушки» типа point-and-click прекрасно подойдут для реализации этих эфемерных созданий. Но все, что кроется за этим фасадом, требует серьезной разработки. В основе внутренних компонентов лежат старые технологии, и существует немало действительно полезных инструментов разработки, которые могут пригодиться в процессе их создания.
Адида: Безусловно, эти системы необходимо проектировать; но, начав абсолютно новый Web-проект, вы не сможете действовать исключительно по книжным правилам. У вас будет другая модель и такой спектр пользователей, с которым вам редко приходилось сталкиваться при разработке традиционных проектов.
Льюис: Эти системы не «проектируются», поскольку в реальной жизни никто не использует принципы так называемого «проектирования программного обеспечения». Windows NT, например, не «проектировалась», поскольку Microsoft практикует только одну методику разработки: «откомпилируй без ошибок, прежде чем уйти домой»! NT эволюционировала в течение семи или восьми лет, когда 500 человек вносили в нее различные изменения. Что неизбежно приводило к появлению ошибок, которые распространяются до тех пор, пока их не ликвидируют методом грубой силы. Нам следует разобраться в том, почему разработчики выбирают для себя именно такой способ действий.
Гилб: Что можно посоветовать создателям систем на базе Internet? Совет первый: выразите количественно качественные требования к системе. Совет второй: закрепите в контракте гарантии своевременного выполнения и соответствующего сопровождения на всех уровнях разработки, оговорите возможность наказания в случае нарушения обязательств. Совет третий: обращайтесь к поставщикам с солидной репутацией, которые располагают достаточными средствами для решения всех проблем. Совет четвертый: создавайте и расширяйте систему поэтапно. И совет пятый: примите во внимание необходимость определенной избыточности на нескольких уровнях, так чтобы система сохраняла хотя бы частичную работоспособность в случае сбоев.
Ульман: В начинающих компаниях разработчики смеются надо мной, когда я пытаюсь порекомендовать им такую «бюрократию» (по их выражению), как составление простого списка ошибок. Важно помнить, что Web создается очень молодыми людьми. Вспомните свое собственное юношеское невежество и в то же время избыток сил (и бесстрашие!), и вы поймете, почему, собственно, мы затеяли весь этот разговор.
Горда: Практически каждый крупный, или даже средний программный проект, с которым мне приходилось сталкиваться, таил в себе угрозу бесконтрольного расширения, поскольку разработчики слишком подобострастно относятся к реализуемым возможностям. Для того чтобы не попасться в эту ловушку, мы обязаны четко осознавать, что программные системы имеют свойство разрастаться подобно сорнякам.
Мой совет, в особенности организациям, которые разрабатывают «все более сложные» системы - делайте их простыми! Чем проще система будет сегодня, тем легче будет завтра привести ее в соответствие новым задачам. Чем меньше ненужных функций вы в нее запихнете, тем меньше возникнет препятствий для поддержки требований, которые появятся в будущем.
Льюис: Я бы рад делать их простыми, только как? Сейчас я консультирую Internet-проект стоимостью 600 млн. долл., который должен быть завершен за пять лет. Как сохранить простоту в такой грандиозной работе? У нас нет для этого подходящих инструментов.
Хамфри: Динамика разработки Web-приложений позволяет нам оперативно подключать пользователей к процессу формулирования требований. Это поможет быстро разрабатывать такие продукты, которые действительно будут удовлетворять потребностям заказчика. Однако, обладая возможностью за один миг рассылать продукты по всему миру, мы обязаны научиться быстро разрабатывать качественные системы. Метод обеспечения качества программных продуктов с помощью тестирования, на который мы опираемся сегодня, занимает слишком много времени и почти наверняка будет неприемлем в нашем Web-будущем. На тестирование программного обеспечения иногда уходят месяцы, но и после этого остается много дефектов.
Нам стоит поучиться у других - ни в одной дисциплине тестирование не является основным способом обнаружения и исправления ошибок. Отследить все дефекты системы, определить их стоимость и понять, какими способами их можно обнаруживать или предотвращать - вот те средства, с помощью которых в других технологических процессах повышается качество продуктов, снижается их стоимость и сокращается время производства.
Адида: При разработке Web-приложений вопрос качества оказывается на повестке дня очень рано. В известном смысле дисциплина проектирования программного обеспечения моложе других видов инженерной деятельности. Мне кажется, что те строгие требования, которые предъявляются к разработчикам Web-систем, форсируют развитие нашей отрасли.
Джонсон: Как можно без тестирования быть уверенным в том, что исправленные ошибки действительно устранены? Где гарантия, что они не появятся вновь? Безусловно, нужно отслеживать ошибки, чтобы определить их стоимость и частоту появления. Но как вы собираетесь следить за ошибками, если у вас нет тестовых средств для поиска самых распространенных дефектов?
При создании динамичного Web-приложения важно спроектировать и построить как его инфраструктуру, так и процесс модификации его информационного содержимого. Построение инфраструктуры - на самом деле не что иное, как построение традиционного программного обеспечения новыми инструментальными средствами. С другой стороны, построение процесса модификации содержимого похоже на формирование редакционной схемы для газеты. В этот процесс необходимо включить такие понятия, как ввод данных, проверка правильности данных, компоновка, гарантии качества и так далее. Для решения этой задачи потребуется либо большое число специалистов, либо значительная автоматизация. Важно то, что методы, которые используются для решения проблем инфраструктуры, должны отличаться от способов организации процесса внесения изменений. Ни та, ни другая задачи не новы, но их комбинация уникальна. Разбить проблему на несколько известных подзадач - один из способов применить испытанные методы разработки в новой области.
Хамфри: Конечно, мы должны тестировать, но тестирование не гарантирует нам качества. И для Web справедливо утверждение, что если не протестировать высококачественный продукт, высококачественный продукт не выпустить.
Льюис: Идеи, проповедуемые различными школами разработчиков, сами по себе хороши, но их до сих пор не удалось применить на практике главным образом потому, что они не соответствуют практицизму коммерческой разработки. Я не оспариваю утверждение, что методы разработки нужны, я просто указываю на отсутствие адекватных методов. Классические принципы проектирования ПО не справляются с задачей, так как же мы можем навязывать их новому поколению разработчиков? Учитывая плачевное состояние технологий программирования, я могу лишь предложить нанимать специалистов с исключительными способностями, делать упор на взаимодействие внутри команды разработчиков и двигаться вперед предельно малыми шагами. И по-прежнему много тестировать.
Ульман: Мой совет организациям - не забывайте, что программное обеспечение принадлежит пользователю. Разработка на базе Web полностью покончила с концепцией инсталляционной базы. ПО может бесконечно изменяться, с вмешательством пользователя или без него, но именно потому, что коды находятся на вашем сервере, вы, разработчик, не можете постоянно менять их по своему усмотрению. Когда Web-разработчики решают отказаться от таких «старомодных» вещей, как поэтапное проектирование, планирование сроков выпуска версий и тестирование возможности использования, они отнимают у пользователей ощущение контроля за собственным рабочим пространством.
Молодые разработчики говорят о «новой бизнес-модели» для программного обеспечения, в которой Web-система становится больше похожа на сервис с почасовой оплатой, чем на продукт, который пользователь покупает и которым владеет. Даже если мы примем эту довольно спорную идею о пользователях-арендаторах, все равно разработчики должны помнить, что владелец дома не имеет права врываться в арендуемое у него помещение бесконтрольно распоряжаться в нем.
Подбор персонала
Прессман: На этапе бурного развития очередной технологии или новой области вся работа держится на «специалистах с исключительными способностями» (по выражению Теда Льюиса), благодаря безудержному энтузиазму которых на свет один за другим появляются продукты самого высокого качества. Однако с течением времени объем работ становится непосильным даже для самых лучших разработчиков, поэтому компании, чтобы справиться с требованиями развивающегося рынка, набирают менее компетентных в данной области людей, которые, возможно, уже не обладают энергией своих предшественников. Не вызывает особого сомнения, что то же самое случится и с программным обеспечением на базе Web, как произошло во всех других областях разработки ПО. Как действовать компании в такой ситуации? Как организовать группу разработчиков для создания программных систем на основе Internet, если не все ее члены будут «исключительными» специалистами?
Льюис: Подавляющая часть программной индустрии стоит перед этой дилеммой. Особенно сейчас, когда существуют тысячи вакансий для программистов и разработчиков.
Я думаю, первые шаги должны быть такие. Менеджер проекта должен признать, что, (1) по существу, он не знает, какие требования предъявляются к системе, поэтому отслеживание таких требований - задача номер один; (2) группа разработчиков состоит из людей, а не машин, поэтому надо быть внимательным к взаимоотношениям членов группы; (3) продукт появится с опозданием, так что изначально надо несколько растянуть сроки; (4) ошибок в системе будет больше, чем ожидается, так что тестирование должно проводиться очень тщательно; и (5) текучесть кадров неизбежна, поэтому необходимо постоянно принимать меры предосторожности относительно неадекватной документации. Одному моему другу удалось вдвое повысить продуктивность работы программистов, благодаря тому, что он каждую пятницу после работы водил свою команду в кино! Все эти принципы формулируются в книге Тома Демарко.
Гилб: Нам остается только надеяться, что весь этот хаос удастся взять под контроль, если мы научимся определять основные требования к проекту, особенно качественные требования, таким образом, чтобы их можно было измерить количественными показателями и впоследствии протестировать. В этом случае, независимо от того, какими специалистами и методами работы мы располагаем, в центре нашего внимания будет постепенное доведение проекта до полной реализации предъявленных требований, правильность которой можно будет проверить с помощью соответствующих тестов. Тогда мы очень быстро обнаружим неадекватных задаче сотрудников, архитектуры или методы и сможем заменить их на более подходящие.
Следует также предусмотреть материальное вознаграждение разработчикам за их реальные достижения. Мы же привыкли реагировать на неудачи, а в этом как раз нет особой необходимости.
Горда: Компании должны укладываться в жесткие сроки, поэтому задача не переусложнить систему и не дать чересчур разрастись команде разработчиков не менее важна, чем подбор специалистов с исключительными способностями. При необходимости следует разбивать задачу на подзадачи и распределять их по подгруппам разработчиков. Разработчикам нужны мощные программные инструменты, но у них нет времени (или возможностей) создавать их своими силами. Необходимо тщательно выбирать эти инструментальные средства, поскольку на них будет строиться все решение. Нужно выбрать такой источник программных средств, на который можно положиться и в будущем.
Демарко: Мне кажется, что все наше обсуждение крутится вокруг «хакинга». Создается впечатление, что все защитники идеи «в Web все по-другому» подразумевают одно: Это - единственный способ работы в Web, поскольку только с его помощью удается действовать достаточно быстро. Даже последний вопрос об организации группы разработчиков подразумевает, что суперпрограммисты действуют одним способом, а «обычные» специалисты найдут что-нибудь попроще - и, по всей видимости, помедленнее. Думаю, это заблуждение - нет ничего проще и неповоротливее, чем «хакинг». Вы начинаете с очень плохого проекта, а потом не оставляете от него камня на камне, чтобы все-таки получить работающую систему. Но это всегда проигрышный вариант.
Нам нужен легкий процесс быстрой разработки, независимо от того, в Web она происходит или нет. Простая и качественная разработка всегда основана на дисциплине проектирования - тщательной декомпозиции задачи на связанные друг с другом компоненты с прозрачным интерфейсом между ними. Этот подход годится и для суперзвезд и для начинающих - последним просто потребуется больше поддержки.
Хамфри: Мы совсем не коснулись того, что, на мой взгляд, особенно важно. За ростом и развитием Web не стоит никакого реального проектирования. Тщательно разрабатывались фундаментальные основы Web, но в многосвязных, динамичных, распределенных по всему миру Web-приложениях отсутствует какой бы то ни было системный дизайн. Боюсь, что слабая разработка могла стать источником таких скрытых дефектов, по сравнению с которыми проблема 2000 года покажется невинной шалостью. Системы на базе Web, вне всякого сомнения, обладают огромным потенциалом, но они же составляют серьезную угрозу национальной экономике, которая во многом зависит от Web. Нам же необходим надежный фундамент, в котором присутствуют средства восстановления, гарантии безопасности, возможности сохранения секретности информации и защита от разрушительных воздействий. Кроме того, нам нужны системы, которые выходят из строя без катастрофических последствий и могут сохранить работоспособность в неблагоприятных условиях.
Не думаю, что есть простые ответы на поставленный вопрос, но почти наверняка нам понадобятся стандарты и дисциплина разработки. У Web-технологий большое будущее, и я рискну предположить, что значение профессиональных навыков будет возрастать, а не уменьшаться.
Джонсон: Фред Брукс в своей знаменитой книге «Мифический человеко-месяц» отмечает, что высококлассные программисты на порядок лучше плохих программистов. Это утверждение справедливо и по прошествии двадцати лет. Но если специалисты с «исключительными способностями» создали систему, которую трудно поддерживать и сопровождать, то, когда такая «звезда» получит новую работу, вам придется начинать все с нуля. Мы должны помнить, что программное обеспечение, как правило, остается с нами гораздо дольше, чем его разработчики. Так что суммы, которые вы потратите на то, чтобы заставить лучших специалистов следовать базовым принципам проектирования систем, могут показаться ничтожно малыми по сравнению с теми расходами, которых потребует переделка системы, когда ее авторы покинут свое место работы.
Ульман: Я категорически не согласна с исходной постановкой вопроса. Каждый человек, работающий на вас, является (или может являться) исключительным специалистом в данной конкретной ситуации. После завершения начальной стадии разработки вам потребуются «исключительные» специалисты совсем другого рода. По моему мнению, на этапе, когда уже есть в наличии работающий код, такое качество, как «безудержный энтузиазм», играет деструктивную роль. На заключительных фазах работы по-настоящему исключительными качествами я считаю умение общаться с коллегами (и при этом быть хорошим программистом - редко встречающееся сочетание), возможность читать и понимать чужие «блестящие» программы, написанные разработчиками системы (судя по моему опыту, умение читать коды - настолько редкое качество, что его можно назвать экстраисключительным) и так далее. Когда проект практически готов, в игру вступает целый комплекс новых «исключительных» способностей. Не очень разумно снижать требования к каждой последующей когорте своих сотрудников. Это путь к поражению - если вы ищете заурядных людей, вы их и получите.
Адида: Для Web нужна новая модель проектирования, но мы совершим большую ошибку, если полностью отодвинем в сторону традиционные принципы разработки.
Решение - в возврате к основам. Серьезная, исчерпывающая документация. Модульный проект. Планирование будущих модификаций. Конечно, многие Web-проекты по существу таковы, что им уготована недолгая жизнь. Для них достаточно запланировать внесение нескольких изменений или полное их отсутствие, так что не возникнет необходимости раздумывать над последствиями привлечения «менее квалифицированных» сотрудников. Сложность, конечно, состоит в том, как определить, какие проекты рассчитаны на длительное существование, а какие нет. Эту задачу можно возложить на «исключительных» специалистов при запуске проекта.
Резюме
Прессман: Выслушивая мнения участников дискуссии, я ловил себя на мысли, что когда-то все это уже было. Мы обсуждали тогда другие технологии, но приводили те же самые доводы.
Смею утверждать, что дисциплина проектирования никогда не будет лишней. Базовые принципы, которые позволяют создавать высококачественные продукты, применимы в любом случае - разрабатываете ли вы новейшее и сложнейшее Web-приложение или трехтысячную версию корпоративной платежной системы. Проблема не в том, использовать или нет жесткие принципы проектирования ПО. Проблема состоит в том, как их применить, чтобы не сделать процесс разработки чрезмерно догматичным и бюрократическим.
Но за этим встает другой вопрос, а именно: то, что вам кажется догматичным и бюрократическим, может полностью удовлетворять меня. Каждая организация должна самостоятельно решить, каким образом будут применяться принципы проектирования при разработке Internet-приложений. Это будет важное для бизнеса решение. Но если компания предпочитает совсем игнорировать методы проектирования программных систем, то, по моему мнению, и менеджеры, и разработчики совершают ошибку, последствия которой дадут о себе знать и после того, как особая привлекательность Web пойдет на убыль.
| "Can Internet-based applications be engineered?" - IEEE Software, Sep/Oct 1998, pp. 104-110. Reprinted with permission, Copyright IEEE, USA, 1998. All rights reserved. |
