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

Эволюция аппаратуры и скорость разработки

Эволюция аппаратуры и скорость разработки

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

В итоге, спустя 20 с лишним лет, все мы – и разработчики, и пользователи – продолжаем сидеть на «числогрызах» 4-го поколения. Производительность «железа» возросла на порядки, почти упёршись в физические ограничения миниатюризации полупроводников и скорость света. Стоимость тоже на порядки, но снизилась. Увеличилась надёжность, развилась инфраструктура, особенно сетевая. Параллелизация вычислений пошла в массы на плечах многоядерных процессоров.

Прежними остались лишь принципы, заложенные ещё в 1930-х годах и названные, согласно месту, Гарвардской и Принстонской архитектурами ЭВМ. Вчерашний студент теперь пишет не на ассемблере и C, а на Java, будучи уверенным в принципиальной новизне ситуации, не всегда осознавая, что изменилось только количество герц тактовой частоты и байтов запоминающих устройств.

Возросла ли при этом скорость разработки? Вопрос достаточно сложный, даже если сузить периметр до программирования согласно постановке задачи. Тем не менее я рискнул бы утверждать, что не только не возросла, но, наоборот, снизилась.

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

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

Бывшие разработчики 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 не навязывал следование ООП, давая органично встраивать процедурную обработку между склеенными компонентами.

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

Оглавление книги