Дефрагментация мозга. Софтостроение изнутри

Однако, несмотря на значительный прогресс за последние 15 лет, производительность разработки пользовательского интерфейса для веб-приложений в разы отстаёт от автономных приложений, тех самых, что «компонентокидатели» на Visual Basic, Delphi или C++ Builder делали 15 лет назад.

Если взять простой пример отображения модального диалога, то в Delphi, Visual Basic или WinForms-приложении потребуется написать одну строку кода для вызова формы и вторую – для проверки статуса возврата. Для веб-приложения, во-первых, реализация этого сценария одними серверными скриптами невозможна, необходимо задействовать клиентские. Во-вторых, необходимо хорошо представлять себе механизмы взаимодействия браузера и веб-сервера, чтобы синхронизировать вызовы и организовать передачу статуса. Наконец, веб-приложение не имеет состояния, поэтому понятие пользовательской сессии очень условное. Например, после 15-минутной паузы в деятельности клиента сервер решает, что сеанс закончен.

Теперь представьте, что под модальным окном с индикатором выполнения и единственной кнопкой «Прервать» вам надо запустить асинхронную обработку с обновлением информации в главном окне. В автономном приложении снова пишем несколько строк кода, добавляя обработчик события с делегатом из основной формы. А вот в веб… Даже краткое описание займёт несколько абзацев и будет касаться зоопарка технических ухищрений.

В качестве иллюстрации, существующая подсистема пользовательского интерфейса у одного из наших клиентов насчитывала всего около четырёх десятков экранных форм. Но для реализации только логики отображения потребовалась примерно сотня тысяч (!) строк code-behind [22] и Java-скриптов, несмотря на то, что создатели чётко отделили слой представлений от прикладной обработки, следовали логике «модель – представление – котроллер» [23] , а общие элементы управления разного уровня – от собственных ( custom

) до композитных ( user ) – свели в библиотеки.

Легко проследить даже на простом примере, что для программиста помимо решения собственно прикладной задачи находится уйма забот. Основной целью такой дополнительной головной боли является платформенная независимость клиентской части приложения и максимально облегчённое развёртывание так называемого «тонкого» клиента, которым является веб-браузер.

Действительно, переносить автономное приложение между разными операционными системами и аппаратными платформами трудно. Большинство из них пишутся под Windows. Приложения на Java или WinForms.NET переносить легче, но для развёртывания требуется предустановленная среда времени исполнения ( runtime ) соответствующего фреймворка не ниже определённой версии. Гораздо меньше проблем с развёртыванием у FreePascal/Lazarus (открытый многоплатформенный аналог Delphi), новой версии Delphi XE или C++/Qt-приложений. Но, во-первых, перечисленное – далеко не самые массовые технологии, представляющие по этой причине дополнительные риски для менеджеров. Во-вторых, для обеспечения переноса и сам код, и требования к его написанию усложнятся, тогда как тестировать придётся на всех целевых платформах.

Поэтому на первый взгляд идея универсального программируемого терминала, которым является веб-браузер, поддерживающий стандарты взаимодействия с веб-сервером, выглядит привлекательно. Никакого развёртывания, никакого администрирования на рабочем месте. Именно этот аргумент и стал решающим в конце 1990-х годов для внедрения веб в корпоративную среду. Гладко было на бумаге, но забыли про овраги…

Достаточно быстро выяснилось, что разработка приложения, корректно работающего хотя бы под двумя типами браузеров (Internet Explorer, Netscape и впоследствии Mozilla) – задача не менее сложная, чем написание кода в автономном приложении на базе переносимой оконной подсистемы (Lazarus, C++ и другие). А тестировать нужно не только под разными браузерами, но и под разными операционными системами. С учётом версий браузеров.

Поскольку отступать было поздно (см. информацию про капиталовложения в начале раздела), эту проблему решили в лоб. Корпоративная среда в отличие от общедоступного Интернета имеет свои стандарты. Поэтому при разработке веб-приложений достаточно было согласовать внутренние требования предприятия с возможностями разработчиков. К началу 2000-х годов установился фактический стандарт корпоративного веб-приложения: Internet Explorer 6 с последним пакетом обновления под Windows 2000 или Windows XP.

Под эти требования за 10 лет было написано великое множество приложений. А когда пришла пора обновлять браузеры, внезапно выяснилось, что их новые версии далеко не всегда совместимы с находящимися в эксплуатации системами. И по этой причине простое обновление Internet Explorer 6 на 7 вызовет паралич информационных систем предприятия.