Оберон-клуб «ВЄДАsoft»

В удивительные и непредсказуемые времена мы в испуге цепляемся за прошлое.
А. Азимов. «Край основания»

Вначале, как известно, было Слово™. И Слово™ содержало ровно столько байтов, сколько допускала архитектура ЭВМ. Поэтому 1 К не был равным 1 кбайт.

Из Слов™ стали составлять настолько скучные и однообразные на вид инструкции, что выполнять их могла только ЭВМ. Или самые упорные из составителей — в своём уме. И назвали эту технологию Программированием© в Машинных Кодах™. Вскоре парни, вооружённые Программированием в Машинных Кодах™ сделали Первую© Систему®. Далее значки торговых марок и копирайта я опускаю.

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

И тут появились Молодые Парни, которым пришла в голову Мысль: можно вместо Машинных Кодов использовать их Мнемонику. Понятную человеку. Но, к сожалению, непонятную ЭВМ. Пришлось им в Машинных Кодах составлять вспомогательную программу — Транслятор, которая переводила Мнемокод в Машинный Код. На самом деле мысль Молодые Парни подслушали у Старых Чудаков, но тем, как мы помним, было не до реализации этой Мысли. И Молодые Парни, вооружённые Программированием в Мнемокодах, сделали Вторую Систему.

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

Во время пития одной из чашек кофе у Старых Чудаков возникла мысль о том, что хорошо бы приблизить составление программы к написанию текста на человеческом языке. На Языке Высокого Уровня (ЯВУ). Но Чудаки были так заняты Второй Системой, что благородно позволили подслушать эту Мысль новым Молодым Парням, подсматривавшим за ними сквозь дырки в перфокартах.

Молодые Парни поднатужились и составили Транслятор с языка, похожего на математическую запись формул. Его так и назвали: Фортран — ФОРмуло-ТРАНслятор. Вооружённые Фортраном, Молодые Парни сделали Третью Систему. Но не успели они, быстренько добавив в Систему новые функции, сесть за кофе и партию в преферанс, покуривая в форточку подсобки, как их снова сильно напрягли. И снова стали они Старыми Чудаками. Да, чуть не забыл: в соседней комнате другие Молодые Парни и Девушка создали другой Транслятор, КОБОЛ — Как бы Описания Бизнес-правил... Ой, Ладно. Они тоже делали Третью Систему, но с другого боку.

Надо сказать, что Старые Чудаки с Фортраном придумали такую вещь, как типы переменных по умолчанию. И все переменные, начинающиеся на i, j, k, l, m и n Транслятор считал целочисленными. С той поры все Новые Молодые Парни в своих Новых Системах используют эти переменные в циклах, особо не задумываясь об их происхождении.

Третья Система оказалась такой живучей, что до сих пор можно увидеть объявления о поиске ну-Очень-Старых-Чудаков для внесения в неё изменений.

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

Следует вспомнить, что Один Умный Старый Чудак из Швейцарии потом продолжил создавать Следующие Системы. Но его y*censored* не замечали. И не потому, что его Системы были плохи. А потому, что все были по горло заняты внесением новых функций в Четвёртую Систему.

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

Наконец, Большие Дяди сказали себе, что пора бы навести Как бы Порядок в этом Творческом Бардаке. И стали вкладывать много денег для создания Единственно Правильной Четвёртой-с-половиной Системы. Она не должна была зависеть от типа ЭВМ: единожды написанная на ЯВУ программа могла бы работать на любой другой ЭВМ. А чтобы новые Молодые Парни не создавали хаос, Большие Дяди создали свой Стандарт на ЯВУ и всё, что вокруг. На практике же оказалось, что однажды написанная программа должна быть отлажена везде, где её планируют запускать. Ну а чтобы другим парням и чудакам было не обидно заниматься отладкой и без передышки вносить в Четвёртую-с-половиной Систему изменения, назвали её просто «Кофе».

Когда Большие Дяди стали поднимать Большие Деньги на своей Четвёртой-с-половиной Системе, то Другие Большие Дяди решили, что они не хуже. И тоже сделали Четвёртую-с-половиной Систему. Но, поскольку название «Кофе» оказалось занято, а «Сигарета» явно не соответствовала маркетинговым концепциям, её назвали так, чтобы все были бы внутренне горды от одного только чувства того, что работают они с Великой Четвёртой-с-половиной-и-ещё-Точка Системой.

Внесение изменений в Четвёртые-с-половиной Системы стало занятием столь же скучным, как и предыдущие. Поэтому, чтобы Молодые Парни не чувствовали себя, по крайней мере сразу же, такими же Старыми Чудаками, им разрешили обзывать всех вносящих изменения в Четвёртую (ту, что без половины, а тем паче в Третью) Систему Старыми-Чудаками-на-Одну-Букву.

И вот одни Старые Чудаки добавляют функции в Четвёртую, Третью и даже Вторую Системы. Другие — в Четвёртые-с-половиной Системы. А в перерывах на форумах и в блогах последние обзывают первых Одной Буквой.

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

И тогда все хором — от Старых Чудаков Первой Системы до Самых Молодых Парней — сказали: в нашей отрасли кризис! А Старые Чудаки добавляют: застой, и света в конце тоннеля не видно. Рядом с ними Маргинальные Чудаки с искусственным интеллектом под мышкой, специализированными ЯВУ и ЭВМ, суперкомпьютерами, векторными вычислениями и прочей экзотикой стоят в сторонке от мейнстрима и посмеиваются над ловкостью, с которой им удалось обмануть всех, включая самих себя.

О красоте

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

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

Учёный и классик жанра научной фантастики Иван Ефремов писал: «Красота — это высшая степень целесообразности в природе, степень гармонического соответствия и сочетания противоречивых элементов во всяком устройстве, во всякой вещи и во всяком организме».

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

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

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

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

Круговорот

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

На практике это означает, что на одного производителя тиражируемого продукта разной степени серийности — от массовых брендов до малотиражных специализированных, приходится почти десяток поставщиков услуг, крутящихся вокруг этих продуктов, и разработчиков заказных программных систем. Чем дальше от основного производителя программных продуктов в мире — США, тем больше это соотношение в пользу сервиса.

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

Куда направить освободившиеся ресурсы? А давайте-ка автоматизируем непроизводительную возню отдела «X» с таблицами, и тогда начальники смогут быстрее получать сводки!

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

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

Вот такой, если очень упрощенно, происходит круговорот. Возникает естественный вопрос: «А как же конкуренция по себестоимости разработки, которая должна двигать прогресс в отрасли?»

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

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

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

Разница в том, что инфраструктурные услуги неплохо оптимизируются и один бывший администратор сети или баз данных компании может теперь обслуживать сразу несколько клиентов, работая удалённо на прямой связи, атои непосредственно в ВЦКП [10 -Вычислительный Центр Коллективного Пользования.] или ЦОД [11 — Центр Обработки Данных (англ. Data Center).]. В софтостроении такая оптимизация оказывается проблематичной. Кроме упомянутых проблем с конкуренцией, имеет место и другая веская причина — нечёткость требований, сформулировать которые заказчик далеко не всегда в состоянии. Ведь, как вы помните, он уволил своих прикладных программистов ещё 10-15 лет назад. У подрядчика же функциональная специализация программистов существует только для клиентов, способных давать стабильный заказ с высокой долей прибыли. В первую очередь, это банки и финансовые компании. Проектная фирма обычно вкладывает собственные средства в обучение разработчиков предметной области таких заказчиков, вплоть до получения ими второго высшего образования. Найти же программистов, знающих специфику работы отдела «X» с электронными таблицами, мягко говоря, маловероятно. Подойдёт и бригада после курсов переквалификации, возглавляемая более опытным руководителем, скорее всего, имеющим не техническое, а коммерческо-управленческое образование.

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

Масштабы и последствия

Согласно сведениям IBM, сообщество Java-разработчиков уже к 2006 году насчитывало более 6 миллионов человек [12 — «With today's news, the companies are reinforcing their commitment to the Java community, which comprises more than six million developers worldwide» // IBM Taps Boom in Linux Growth by Expanding Commitment to Partners, Linux and Open Source, december 2005.]. Вдумайтесь в эту цифру. Шесть миллионов ремесленников ежедневно садятся перед монитором и усердно вбивают в дисковое пространство программный код.

Когда вступают в действие большие числа, впору вспомнить о нормальном распределении, на которое нам открыл глаза ещё старина Гаусс.

Чтобы не просто зарабатывать на хлеб, но и мазать его маслом, сохраняя при этом возможности технического творчества, вам лучше держаться подальше от тех направлений деятельности, где конкурентами будут 6 миллионов человек.

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

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

Когда выборка составляет 6 миллионов, несложно получить и среднюю по отрасли оплату своего труда. И можно себе представить, скольких усилий стоит добиться высокой оплаты. Не будет иметь большого значения то, что ты можешь сделать хороший дизайн, если за тобой на интервью придёт дилетант, заучивший десять известных работодателю «паттернов», 200 классов фреймворка [13 — От англ. framework. В рамках объектно-ориентированного подхода — библиотека классов с двусторонним (взаимным) управлением потоком исполнения программы. Более общее значение — каркас, предоставляющий стандартные службы, библиотеки и компоненты для разработки программ в рамках накладываемых им ограничений.] и просящий за это в 2 раза меньше денег.

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

Не забывайте, что относительная доля критичных к качеству проектов падает, а переделка работающих систем базового уровня, от которых непосредственно зависит бизнес, — и вовсе редкое явление. Этот момент всегда оттягивают до последнего, предпочитая использовать вышедших на пенсию кобол-программистов и модернизацию мейнфреймов [14 — От англ. mainframe — классическая большая универсальная ЭВМ.] с помощью специалистов IBM. Слишком высоки риски. Новые значимые проекты возникают только с новыми рынками и направлениями бизнеса.

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

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

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

Хорошо оплачиваемая работа с творческим подходом к труду в современном мире — это привилегия, за которую придётся бороться всю жизнь. И софтостроение здесь не является исключением.

Начинающим соискателям

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

1. «Быстро растущая компания» — фирма наконец получила заказ на нормальные деньги. Надо срочно нанять народ, чтобы попытаться вовремя сдать работу.

2. «Гибкие (agile) методики» — в конторе никто не разбирается в предметной области на системном уровне. Программистам придётся «гибко», с разворотами на 180 градусов, менять свой код по мере постепенного и страшного осознания того, какую, собственно, прикладную задачу они решают.

3. «Умение работать в команде» — в бригаде никто ни за что не отвечает, документация потеряна или отсутствует с самого начала. Чтобы понять, как выполнить свою задачу, требуются объяснения коллег, как интегрироваться с уже написанным ими кодом или поправить исходник, чтобы наконец прошла компиляция модуля, от которого зависит ваш код.

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

5. «Гибкий график работы» — программировать придётся «отсюда и до обеда». А потом после обеда и до устранения всех блокирующих ошибок.

6. «Опыт работы с заказчиком» — заказчик точно не знает, чего хочет, а зачастую — неадекватен в общении. Но очень хочет заплатить по минимуму и по максимуму переложить риски на подрядчика.

7. «Отличное знание XYZ» — на собеседовании вам могут предложить тест по XYZ, где в куске спагетти-кода нужно найти ошибку или объяснить, что он делает. Это необходимо для проверки пункта 4. К собственно знанию XYZ-тест имеет очень далёкое отношение.

Тесты — особый пункт при найме. Чаще всего они касаются кодирования, то есть знания синтаксиса, семантики и «что делает эта функция».

Про мотивацию

Мне очень нравится одна история-притча, которую приведу целиком:

Около дома одного человека мальчишки играли в мяч: ударяли им о стены, громко кричали и смеялись. Естественно, они мешали хозяину дома. И вот в один прекрасный день он вышел к ним и сказал: «Друзья, вы так весело играете в мяч, так заразительно смеётесь и кричите, что я с удовольствием вспоминаю свое детство. Я буду платить каждому по монете, чтобы вы каждый день приходили сюда, громко кричали, смеялись и играли в мяч». Мальчишки взяли по монете и продолжили игру. На следующий день они снова пришли и получили по монете. Так продолжалось несколько дней. Но как-то хозяин подошёл к мальчишкам и сказал, что его финансовые дела не так хороши, как раньше, и он сможет платить им только по полмонеты. Он заплатил им по полмонеты и ушёл. А мальчишки поговорили и решили, что не будут стараться за полмонеты. И больше они не приходили. Так хозяин дома получил желаемые мир и спокойствие.

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

Поэтому, когда вам предлагают услуги по «мотивации персонала», желательно спросить, будут ли персонал бить током, колоть препаратами или ограничатся лёгким массовым сеансом гипноза.

Напротив, стимуляция — это внешний механизм. Он основан на выявлении мотивов и последующем их поощрении или подавлении. Стимулятор подобен катализатору для запуска химической реакции. Управление стимуляцией сводится к созданию системы стимулов, требуемых для «реакций» катализаторов. Для «реакций» — процессов работы человеческих коллективов.

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

Изгибы судьбы при поиске работы

Рассказ из реальной жизни, надеюсь, внесёт долю юмора в оказавшуюся не самой весёлой тему профессиональной ориентации.

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

Как обычно, регулярно названивали мадемуазельки ранга ассистента по «человечьим ресурсам», первый их вопрос стандартен, вызван дилетантизмом в предметной области нанимаемых и потому звучит всегда: «А какую работу вы ищете, если поточнее?» То есть объясните, дяденька, что это за аббревиатуры такие у вас на первой странице CV. Если настроение хорошее, можно коротко просветить девушку, если не очень, то отвечать в стиле: «Ровно то, что написано в заголовке CV, вы его читали?»

Второй этап — выяснение, ищут ли они специалиста на конкретный проект или просто под широкий профиль. Это вопрос специфичный для самого массового работодателя — консультационно-проектных фирм. Если набор идёт «под широкий профиль», то можно вежливо начинать прощаться.

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

Третий этап — отбрыкаться от приглашения на бесполезное интервью, убедив, что не стоит зря тратить время. Ведь у мадемуазелек рабочего времени навалом. Достаточно попросить прислать краткое описание требований к вакансии. В 90 % случаев это срабатывает, причём в 90 % из этих 90 % случаев требования оказываются неподходящими. В оставшихся 10 % можно соглашаться на интервью, главное — потом накануне не забыть уведомить, что по уважительной причине прийти на него нет никакой возможности.

Ладно, это все техника, которая приходит с опытом. Тем более, если времени много, например, вы сидите на пособии по безработице — это надо же так постараться в нашем расцвете лет, можно и походить по мадемуазелям, расширив круг повседневного общения.

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

Как раз звонят из этой конторы. Но не ассистентка, а паренёк, и, видимо, подкованный. Так как после первой минуты сказал, что ещё через четверть часа мне перезвонит собственно начальник отдела, куда ищут работника. С руководителем мы приятно побеседовали минут 20. Выяснилось, что хотя профиль и не совсем тот, что нужен «ещё вчера», но вот очень скоро будет проект и уж там-то. . Ну и хорошо, как будет, так и созвонимся-спишемся? Спишемся.

Вечером в почтовый ящик падает анкета «Контрабаса» для соискателя на 10 (!) страницах. Я тут же ее закрыл, письмо переместил в корзину.

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

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

В конце концов, по сумме обстоятельств я стал сотрудником «Контрабаса», избежав заполнения 10-страничной анкеты и нескольких раундов интервью, из которых смысл имеет только один — с непосредственным начальником или напарниками, но остальные можно не пройти по совершенно не зависящим от тебя причинам. Например, много лет назад я по неопытности пытался объяснить мадемуазельке из фирмы-посредника разницу между SQL и PL/SQL, потому что это было важно для данной вакансии. А она только улыбалась. Но по итогам выдала моему агенту заключение: «Не могу рекомендовать вашего инженера клиенту, он был со мной очень холоден.» Я не шучу, формулировка была именно такой.

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

ООП — неизменно стабильный результат

Говоря об объектно-ориентированном подходе и программировании, принято добрым словом вспоминать начало 1970-х годов и язык Smalltalk, скромно умалчивая, что понадобилось ещё почти 15 лет до начала массового применения технологии в отрасли, прежде всего, за счёт появления C++ и позднее — Объектного Паскаля. Потому что фактическим отраслевым стандартом был язык C, а Паскаль широко использовался для обучения и в основном для прикладного программирования, если не рассматривать исключения вроде первой версии Microsoft Windows. Религиозные войны 1970-80-х годов в новостных группах проходили под лозунгом «Си против Паскаля». По этой причине революционный переход сообществ на Smalltalk выглядел маловероятным, тогда как объектно-ориентированные расширения вышеупомянутых языков были восприняты положительно. Немудрено, что многие концепции Smalltalk были в них реализованы.

В начале широкой популяризации ООП, происходившей в основном за счёт языка C++, одним из главных доводов был следующий: «ООП позволяет увеличить количество кода, которое может написать и сопровождать один среднестатистический программист». Приводились даже цифры, что-то около 15 тысяч строк в процедурно-модульном стиле [33 — В языке C нет понятия модуля, поэтому этот показатель несколько ниже.] и порядка 25 тысяч строк на C++.

Довод в целом правильный, хотя из него совсем не следовало, что десяти программистам на C++ будет легче сопровождать общую систему, чем десяти программистам на C. Про это как-то забыли, потому что существовало много автономных проектов, управляемых процессом типа бруксовской операционной бригады [34 — Ф. Брукс описывает софтостроение по принципу «операционной бригады» в своей книге «Мифический человеко-месяц»[0].] с главным программистом, отвечающим за всё решение. Собственно, и Бьёрн Страуструп, создатель C++, прежде всего преследовал цели увеличения производительности своего программистского труда.

Как только «главным программистом» стал «коллективный разум» муравейника, неважно мечущийся ли на планёрках «гибкой» (agile) разработки, прозаседавшийся ли на совещаниях по тяжёлой поступи RUP [35 — Rational Unified Process — итеративная тяжеловесная методология софтостроения от компаний Rational и IBM.], проблема мгновенно всплыла, порождая Ад Паттернов [36 — От англ. design pattern — шаблон проектирования.], Чистилище нескончаемого рефакторинга [37 — От англ. refactoring — реструктуризация и факторизация программного кода. В экстремальных методиках при отсутствии концепции системы и анализа предметной области формально требуется постоянный рефакторинг кода, при помощи которого предполагается чудесным образом прийти к хорошему решению ничего не проектируя.] и модульных тестов, недосягаемый Рай генерации по моделям кода безлюдного Ада.

Термин «Ад Паттернов» может показаться вам незнакомым, поэтому я расшифрую подробнее это широко распространившееся явление:

• слепое и зачастую вынужденное следование шаблонным решениям;

• глубокие иерархии наследования реализации, интерфейсов и вложения при отсутствии даже не очень глубокого анализа предметной области;

• вынужденное использование всё более сложных и многоуровневых конструкций в стиле «новый адаптер вызывает старый» по мере так называемого эволюционного развития системы;

• лоскутная [38 — Термин широко используется в автоматизации предприятий и происходит от «лоскутного одеяла» — разрозненного набора программ и пакетов, решающих локальные задачи подразделений.] интеграция существующих систем и создание поверх них новых слоев API [39 — API (Application Programming Interface) — интерфейс программирования приложений, функциональность, которую предоставляет модуль, компонент или библиотека программисту.].

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

Services.Oragnization.ContainerProvider.ProviderInventory.InventorySectorPrivate. Stacks[0].Code.Equals("S01")

Последствия от создания Ада Паттернов ужасны не столько невозможностью быстро разобраться в чужом коде, сколько наличием многих неявных зависимостей. Например, в рамках относительно автономного проекта мне пришлось интегрироваться с общим для нескольких групп фреймворком ради вызова единственной функции авторизации пользователя: передаёшь ей имя и пароль, в ответ «да/нет». Этот вызов повлёк за собой необходимость явного включения в .NET-приложение пяти сборок. После компиляции эти пять сборок притащили за собой ещё более 30, большая часть из которых обладала совершенно не относящимися к безопасности названиями, вроде XsltTransform. В результате объём дистрибутива для развёртывания вырос ещё на сотню мегабайтов и почти на 40 файлов. Вот тебе и вызвал функцию...

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

Несомненно, C++ является мощным инструментом программиста, хотя и с достаточно высоким порогом входа, предоставляющим практически неограниченные возможности профессионалам с потребностью технического творчества. Я видел немалое количество примеров изящных фреймворков и прочих «башен из слоновой кости», выполненных одиночками или небольшим коллективом. Но крупные проекты подвержены влиянию уже упоминавшейся гауссианы (см. рис. 1). Нормальное распределение вовлекает в процесс большое количество крепких профессионалов-середняков, которым надо сделать «чтобы работало» с наименьшими телодвижениями во время нормированного рабочего дня. Если Microsoft или Lockheed Martin — подрядчик Министерства Обороны США, имеют возможность растянуть кривую на графике вправо и вложить немалые средства во внутреннюю стандартизацию кодирования, то в обычной ситуации оказывается, что C++, действительно увеличивавший личную продуктивность Страуструпа и его коллег, начинает тормозить производительность большого софтостроительного цеха где-нибудь в жарком субтропическом опенспейсе [40 — От англ. openspace — большое офисное помещение, зал без перегородок с расположенными в нем рабочими местами.] площадью в гектар. Помимо общих проблем интеграции, на C++ достаточно просто «выстрелить себе в ногу», и человеческий фактор быстро становится ключевым риском проекта.

Если вернуться к вопросу стандартов кодирования на C++, хорошим примером будет разработка программной начинки нового истребителя F-35 [15]. Объем разработанного кода порядка 10 миллионов строк, это даже больше, чем Windows. Следовательно, стандарт вполне пригоден к практическому использованию. Но имеются ли у вас в проекте ресурсы для того, чтобы не только обучить всех программистов 150-страничному своду правил, но и постоянно контролировать его исполнение?

Поэтому появились новые C-подобные языки: сначала Java, а чуть позже и C#. Они резко снизили порог входа за счёт увеличения безопасности программирования, ранее связанной прежде всего с ручным управлением памятью. Среды времени исполнения Java и .NET решили проблему двоичной совместимости и повторного использования компонентов системы, написанных на разных языках для различных аппаратных платформ.

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

Примерно в то же время в сообществе начались дискуссии, появились первые публикации вроде уже ставшей классической «Почему объектно-ориентированное программирование провалилось?» [41 — См. публикацию «Objects Have Failed» (2000 г.) и материалы конференции OOPSLA (Object-Oriented Programming, Systems, Langauges and Applications) по данной теме в 2002 г.]. Эксперты по ООП в своих книгах стали нехотя писать о том, что технология тем эффективнее, чем более идеален моделируемый ею мир.

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

Учебники по ООП полны примеров, как легко и красиво решается задачка отображения геометрических фигур на холсте с одним абстрактным предком и виртуальной функцией показа. Но стоит применить такой подход к объектам реального мира, как возникнет необходимость во множественном наследовании от сотни разношёрстных абстрактных заготовок. Объект «книга» в приложении для библиотеки должен обладать свойствами «абстрактного печатного издания», в магазине — «абстрактного товара», в музее — «абстрактного экспоната», в редакции, типографии, в службе доставки... Можете продолжить сами.

Попытки выпутаться из этой ситуации за счёт агрегации приводят к новым дивным мирам, существующим только в воображении разработчиков. Теперь объект «книга» это контейнер для чего-то продающегося, выдаваемого, хранящегося и пылящегося. Необходимо быстро менять контекст: в магазине вкладывать в книгу товар, в библиотеке — печатное издание, в отделе «книга-почтой» — ещё какую-нибудь хреновину. Плодятся новые многоуровневые иерархии, но теперь уже не наследования (is a), а вложения (is a part of).

Изящнее выглядят интерфейсы. Но если в реальном мире книга, она и в музее — книга, то во вселенной интерфейсов «книга в музее» — неопознанный объект, пока не реализован соответствующий интерфейс «экспонат». Дальше интерфейсы пересекаются, обобщаются, и мы получаем ту же самую иерархию наследования, от которой сбежали. Но теперь это уже иерархия, во-первых, множественная, а во-вторых, состоящая из абстрактных классов без какой-либо реализации вообще (интерфейс, по сути, есть pure abstract class). Если же мы отказываемся от обобщения интерфейсов, то фактически оказываемся в рамках современных реализаций модульного программирования типа Оберон [42 — Оберон — семейство языков программирования высокого уровня, разработанных Никлаусом Виртом и его школой.].

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

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

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

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

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

Александр Сергеевич Пушкин использовал в своем творчестве порядка 24 тысяч слов. Толковый словарь Ожегова содержит около 70 тысяч слов. Среднестатистический русский человек использует в повседневной жизни от 5 до 10 тысяч слов [43 — Объем активного словаря образованного человека оценивается в среднем в 5-10 тысяч слов. «Сколько слов в русском языке?», Наука и жизнь, 2004, № 11.], из них только 3 тысячи являются общеупотребительными. Получается, что даже наследник гения Пушкина способен охватить менее половины предлагаемой технологии, при том что её словарь сравним с естественным языком!

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

Практика подтвердила, что технология, будучи обёрнутой в относительно безопасные языковые средства и жёсткие стандарты, допускает применение в больших проектах. С другой стороны, немалое число крупных проектов принципиально не используют ООП, например, ядро операционной системы Linux, Windows API или движок Zend уже упоминавшегося PHP. Язык C по-прежнему занимает первое место согласно статистике активности сообществ программистов [44 — См. данные TIOBE Programming Community Index.], стабильно опережая второго лидера Java — например, индексы ноября 2012 показывают 19 % против 17 %.

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

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

О технических книгах

Дефрагментация мозгов

Современное софтостроение заслуженно забыто наукой. Ну а что вы хотите, если на вопрос «Почему нет науки на конференциях и в публикациях?» получаешь однозначный ответ «Никакая наука рынку не нужна» [129 — См., например, заметку обозревателя PC Week/RE А. Колесова «Научные конференции возвращаются в ИТ».]. В результате на первый план выходят повара, написавшие очередную порцию рецептов приготовления пиццы и винегрета из найденных в холодильнике продуктов корпораций.

Ошибочно полагать, что такая ситуация возникла недавно. Отрицательная динамика степени полезности технических книг наблюдалась уже в начале 1990-х годов. Например, С. Дмитренко в предисловии к своему переводу известной книги Leo Brodie «Thinking FORTH. A Language and Philosophy for Solving Problems» в 1993 году писал:

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

Нынешняя «гуглизация» позволяет быстро находить недостающие фрагментарные знания, зачастую забываемые уже на следующий день, если не час. Поэтому ценность книг как систематизированного источника информации, казалось бы, должна только возрастать. Действительно, автору бессмысленно брать на себя функции интеллектуального фильтра RSS [130 — Агрегация в единый поток информации из множества источников: анонсов статей, изменений в блогах и т. п.], составляя компиляции из содержимого чужих блогов. Кроме стоящих вне конкуренции учебников остаётся в основном только конкретизация — узкоспециализированная проработанная технологическая тема либо обобщение концептуальных наработок и практического опыта.

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

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

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

Изредка мне приходится практиковать обучение СУБД, где я столкнулся ровно с тем же явлением. Группа стажёров примерно моего возраста и старше всю неделю честно старалась вникнуть в детали, написанные мелким шрифтом после каждого слайда, уместить знания в некую систему, желательно, не диссонирующую с уже имеющейся в голове.

И напротив, аудитория примерно 20-25 лет оказалась совершенно равнодушна к пояснительному тексту. Если картинка слайда была удачной, то она более-менее откладывалась в памяти. Вдобавок, шло конспектирование некоторых случаев из моей практики с короткими кусками кода. Иное дело — лабораторные работы, когда решение находилось увлекательным методом «научного тыка». Если же метод не срабатывал, то ко мне обращались с просьбой подсказать «код доступа для прохождения на следующий уровень».

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

Является ли фрагментарное мышление приспосабливанием к многократно увеличившемуся потоку информации? Отчасти да, только это скорее не адаптация, а инстинктивная защита. Чтобы осознанно фильтровать информацию о некоторой системе с минимальными рисками пропустить важные сведения, нужно иметь чётко сформированные представления о ней, её структуре и принципах функционирования. Если, например, у стажера нет знаний о СУБД в целом, то курс по SQL Server — конкретной её реализации, сводится к запоминанию типовых ситуаций и решений из набора сопутствующих практических работ. Вся теоретическая часть при этом просто не проходит фильтры.

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

Что интересно — со знанием дела рассуждает об Обероне. Это подтверждает, что среди "водил мэйнстрима" даже встречаются образованные и с широким кругозором. Изредка.