Сергей Тарасов – Дефрагментация мозга. Софтостроение изнутри (страница 7)
Конечно, специализированные средства разработки всегда обеспечат преимущества по сравнению с универсальными. Тем не менее основная разработка по-прежнему будет идти на весьма ограниченном наборе универсальных сред и фреймворков, выталкивая специализированную в ниши, где сроки и производительность являются наиболее важными.
Бывшие разработчики PowerBuilder или FoxPro неоднократно выражали мне своё недоумение по поводу того, что для простейших операций, вроде настраиваемого показа табличных наборов данных на клиенте, теперь приходится тратить уйму времени и писать десятки строк кода, а каждая корректировка структур данных должна быть отражена во всех слоях системы. Опуская технические ограничения классических клиент-серверных приложений, нетрудно убедиться, что найти на рынке труда специалиста по PowerBuilder на порядок сложнее, чем VB.NET-программиста. К тому же поставщик среды PowerBuilder после многих перекупок за последние годы в итоге выглядит не слишком жизнеспособным.
С другой стороны, количество работающих в софтостроении женщин росло до начала 1990-х годов, после чего резко пошло на убыль. Рисунок 2 представляет ситуацию в США, но и в СССР и позднее в РФ она вряд ли отличалась.
Рис. 2. Процент женщин, занятых в компьютерной отрасли в 1985–2009 годах, согласно данным американского бюро статистики труда
Такая тенденция иллюстрирует факт ухода технологий софтостроения от специализированных сред, не требующих работы на далёком от решаемой прикладной задачи уровне математических абстракций, в которых прекрасный пол почему-то считается менее способным разбираться.
В начале своей трудовой деятельности я наблюдал изображённый на графике пик в среде женщин-программистов. В отделах конструкторско-технологического центра профессия прикладного программиста прекрасно сочеталась с равноправием: мужчин и женщин среди них было примерно поровну. В разгаре был переход с больших ЭВМ на «персоналки» и локальные сети NetWare. Автоматизированные информационные системы переносили на новую платформу, используя специализированные среды разработки приложений баз данных типа FoxPro, Clipper, dBase. И женская половина коллектива успешно справлялась с поставленными перед ними задачами.
Одна умная девушка, получавшая в школе хорошие отметки по математике и без особого труда оперирующая программами и данными в среде FoxPro, после знакомства со средой C++ Builder высказалась максимально ясно: «Язык понравился, но я не поняла, зачем мне нужны эти классы…».
Впоследствии мне не раз приходилось видеть исходники программисток на вполне себе объектно-ориентированном Delphi/C++Builder. В прикладном коде никакого объектного подхода, конечно, не было, всё ограничивалось компоновкой экранных форм стандартными элементами среды и написанием обработчиков событий в процедурном стиле.
Разумеется, это говорит не о «плохости» ООП, а о высоком уровне компетенции, необходимом, чтобы эта технология давала осязаемые преимущества. Тогда как цель прикладника – побыстрее собрать работающее решение для заказчика. Неплохим компромиссом был Visual Basic, похороненный Microsoft в начале 2000-х годов. Хотя ему и далеко до специализированных сред по удобству и скорости, VB не навязывал следование ООП, давая органично встраивать процедурную обработку между склеенными компонентами.
Про объектно-ориентированный подход мы ещё поговорим, но у меня сложилось мнение, что будучи реализованной повсеместно без малейших представлений о её применимости, эта технология сыграла не последнюю роль в вытеснении женского труда из отрасли.
Диалог о производительности
В одном из проектов у меня произошёл с заказчиком весьма характерный разговор, ярко иллюстрирующий приоритеты при освоении бюджета даже в относительно небольшой частной компании:
Заказчик: Нам необходимо рассчитать ряд показателей на основе данных одной базы, но использовать их будут из таблиц в другой базе данных.
Я: Сделаем расчёт на SQL, заполним таблицы напрямую. Базы данных у вас на одном сервере?
Заказчик: На одном, но теоретически могут быть разнесены…
Я: Значит, просто поменяется источник расчётных данных: локальный на удалённый.
Заказчик: Э-э-э… А по сравнению с пакетом сервиса интеграции[20] скорость не замедлится?
Я: Наоборот, все будет работать быстрее. Две стадии – запрос с расчётами и заливка результата – вместо трёх.
Заказчик: Ух ты, здорово! (
Я (
Заказчик (
Речь шла о регулярном заполнении пары таблиц объёмом примерно в сотню миллионов строк. Вместо прямого пути с настраиваемым источником данных ради приобщения к действу ещё одного «выпускника курсов» заказчик выбрал локальный расчёт с последующий перекачкой данных. В итоге используемое дисковое пространство удваивается, время увеличивается.
Служба «бизнес-интеллекта»[21] предприятия – неисчерпаемый кладезь такого рода задач для новоиспечённых специалистов курсов переквалификации и их начальников.
О карманных монстрах
В послужном списке одной конторы имелась небольшая и простая система ведения заказов на рекламу для книжно-журнального издательства. Полтора десятка сущностей (и таблиц), с десяток экранных форм.
Лет 10–15 назад можно было бы взять на выбор Delphi/C++ Builder, PowerBuilder, Visual Basic, FoxPro, лёгкую клиент-серверную СУБД и сделать приложение за 3–5 дней с написанием каких-то сотен строк прикладного кода. Внесение изменений типа «добавления атрибута к сущности» вместе с воссозданием инсталлятора и скрипта обновления базы данных занимало час-два.
В 2009 году приложение было сделано на платформе. NET в трёхзвенной архитектуре: сервер приложений на базе WCF, Entity Framework, СУБД SQL Server 2005 и клиент в виде подключаемого модуля (
Первоначальная разработка заняла у фирмы порядка трёх недель работы одного программиста при том, что большая часть кода генерируется из модели. Отладка проблемы в канале WCF при нештатном исключении занимает часы. При добавлении атрибута изменение поднимается по всем звеньям, что также может потребовать длительного времени.
Наверное, и в 2009 году можно было бы обойтись разработкой на VB.NET приложения, напрямую работающего с СУБД через DataSet. И даже с учётом необходимости устанавливать. NET на рабочем месте, это было бы не намного хуже и медленнее, чем 10–15 лет назад.
Но механизм принятия решения базировался на других критериях:
• менеджеру, в соответствии с корпоративным стандартом, необходимо было использовать только платформы и средства Microsoft;
• программист не имел опыта разработки вне шаблонов многозвенной архитектуры и проекций объектов на реляционную СУБД, поэтому не стал рисковать.
Такие решения принимаются в мире ежечасно. Поэтому новичкам не раз предстоит столкнуться с заданием типа «быстро добавить поле в форму» и познакомиться с внутренним устройством подобных программ – карманных монстров, готовых откусить палец неосторожно сунутой руки.
ASP.NET и браузеры
Всякий раз, когда приходилось что-то делать при помощи технологии ASP. NET или просто править чей-то код, даже правильно написанный, меня не покидало ощущение копания по локоть в большой столовской кастрюле с макаронами.
Давайте вспомним историю. Успех в 1994–1995 годах первой версии бесплатной и открытой платформы PHP, называвшейся тогда Personal Home Page, показал, что веб быстрым темпом трансформируется из источника статической информации в среду динамических интерактивных приложений, доступных через «стандартный» проводник-браузер. Ниже я объясню, почему взял слово «стандартный» в кавычки. Microsoft не могла остаться в стороне и выдала собственное решение под названием ASP (Active Server Pages), работающее, разумеется, только под Windows.
Лежащий в основе названных платформ принцип был просто замечательным, хотя и совсем не новым. Логика приложений реализовывалась на стороне сервера скриптами на интерпретируемом языке, тонкий клиент-браузер в качестве терминала только отображал информацию и ограниченный набор элементов управления вроде кнопок. Вскоре выяснилось, что привыкшему к интерактивности полноценных приложений пользователю одних лишь кнопок не хватает. Тогда и в браузеры (то есть на стороне клиента) тоже включили поддержку скриптовых языков.
В итоге исходная веб-страница, ранее содержавшая только разметку гипертекста, стала включать в себя скрипты для выполнения вначале на сервере, а затем и на клиенте. Можете представить, какова была эта «лапша» на сколько-нибудь сложной странице ASP. Многие сотни строк каши из HTML, VBScript и клиентского JavaScript.