В комментарии к моему недавнему посту “ИТ-специалисты. Спрос и предложение. Кто в дефиците, а кто в избытке?”
директор Центра компьютерного обучения при МГТУ им. Н. Э. Баумана Дмитрий Гудзенко написал: “Рынок насытился "полуучками", теперь работодателю нужны более квалифицированные кадры. Так что если раньше, чтобы найти работу, надо было 2 - 3 курса пройти, то теперь 5 - 6 нужно. Перешёл своеобразный переход от количества к качеству”.
Мне захотелось уточнить: о ком в данном случае идет речь -- "полуучках" c вузовскими дипломами, или о тех людях, которые освоили ту или иную ИТ-премудрость в школе, техникуме или самостоятельно?
Вот как ответил на этот вопрос Дмитрий Гудзенко: “Речь идёт о людях, которые обладают поверхностными знаниями – им с 2009 г. стало намного сложнее найти работу, так как работодатель может выбирать, и выбирает более серьёзных специалистов. А где были получены поверхностные знания – в вузе, на курсах, самостоятельно – не столь важно. Реально технические вузы даже половины потребности в ИТ-специалистах не удовлетворяют, так что роль курсов повышения квалификации велика”.
О том, кого именно следует считать ИТ-специалистами, мы уже писали. Хотя, конечно, взгляды на соответствующий список могут быть разные. К примеру, к какой категории трудящихся следует причислять продавцов ИТ-секций магазинов? К труженикам прилавка (которым все равно, что продавать) или все же к ИТ-специалистам?
Говоря о рынке ИТ-труда, Дмитрий Гудзенко отмечает ещё одну его особенность: “В абсолютных цифрах знатоков Excel всегда будет больше (как предлагаться, так и спрашиваться), чем, к примеру, знатоков SQL. В то же время у нас падает (но не умирает насовсем) спрос на курсы подготовки начальных пользователей. В настоящее время соответствующие группы формируются в основном из пожилых людей или людей, недавно приехавших в Москву. В то же время выше среднего растет спрос на так называемые “тяжёлые” курсы: к примеру, “Информационная безопасность” (локомотив здесь – курс “Этичные хакер”) и различные курсы подготовки разработчиков (Microsoft, 1C, PHP, и т. д)”.
Впрочем, спрос на курсы подготовки разработчиков ПО понятен. Ведь в “армии” разработчиков ПО должны быть не только “офицеры от софта” (либо выпускники соответствующих вузов, либо практики, прошедшие нелегкий путь “от сержанта до генерала”), но и так называемые “рядовые”, реализующие задумки “системных архитекторов” (именно так называется одна из позиций рекрутингового портала Superjob.ru) .
Но я что-то сомневаюсь, что хороший “системный архитектор” может получиться из специалиста, который два-три года не тянул лямку рядового программера. А вы что думаете на этот счет?
Если отвлечься от каторжно-бурлаковской терминологии в формулировке вопроса и прейти к его сути, то краткий ответ «нет, не может», гораздо более полно, аргументированно и довольно захватывающе освещен в серии блестящих эссе, вошедших в книгу «97 этюдов для архитекторов программных систем»: «Архитектор должен быть практиком», «Архитектор – прежде всего разработчик», «Одна строка кода стоит 500 строк спецификаций», «Попробуйте, прежде чем сделать выбор», «Проектируйте только то, что сможете запрограммировать» - пожалуй, сами статьи можно и не читать, одних названий достаточно.
Общепризнанные библии для архитекторов вроде GoF’а и «Архитектуры корпоративных программных приложений» наряду с UML-ными диаграммами щедро иллюстрированы программным кодом, так что для эффективного усвоения материала знать какой-то язык с С-подобным синтаксисом не помешает.
Положим, бессмертный труд Кернигана и Ричи был предварительно проштудирован и паттерны из приведенных выше трудов успешно легли на неиспорченный практикой мозг начинающего архитектора. Вот тут, как правило, начинается настоящее веселье.. Нам доводилось получать решения простого тестового задания («разработать наборчик юнит-тестов для некоего контейнера элементов»), содержащие дюжину паттернов, среди которых могли оказаться даже такие, казалось бы внезапные, для этого задания штуки как MVP, отыскать само решение в этой толпе стратегий, инъекций, фабрик, моделей, представлений и их предъявителей – бонусный квест для приемщика задания. Все эти болезни вроде овердизайна (или «патологии шаблонов» в «97 этюдах..») и «аналитического паралича», конечно, излечимы, а лекарство – практика!
Более того, для того, чтобы отвергать идеи, требующие для своей реализации неприемлемых ресурсных затрат, уже на стадии зиготы и проверять «наколенными» прототипчиками свои сомнительные задумки архитектор должен постоянно держаться «на плаву» - уметь разрабатывать и хорошо чувствовать стоимость разработки. Так что не стоит лишать архитекторов главного удовольствия в нашей отрасли – можно и нужно их привлекать к программированию, например, критичных с архитектурной точки зрения кусков системы, иначе они быстро портятся, превращаясь в менеджеров
2 Дуров Илья: строительные метафоры и аналогии уже, увы, не в моде в области разработки софта («Лучшие программы не строят – их выращивают» - название еще одного этюда из 97-ми). Хотя с требованиями по части широты кругозора соглашусь, у настоящих зодчих тут, кстати, все гораздо сложнее: «Идеальный архитектор должен быть человеком образованным, математиком, знатоком истории, осведомлённым в философии, разбирающимся в музыке, не чурающимся медицины, посвящённым в тонкости юриспруденции, знакомым с астрономией и космологическими теориями». Наверное, поэтому Барри Хокинс в этюде «’Архитектор программного обеспечения’ пишется со строчной буквы» заявляет: «.. дерзостью будет настаивать на том, что архитектор программного обеспечения должен стоять на одной ступени с Адвокатом, Доктором и Зодчим».
Александр, Зодчий по софту,
ЗАО «Лаборатория Касперского»
- разумную простоту (в т.ч. упрощать, чтобы было легче разобраться тем, кто будет поддерживать код после авторов);
- читать и разбирать (в т.ч. чужой код, разный, часто брошенный авторами);
- и главное помогать разработчикам (в т.ч. аргументированно решить, как лучше сделать, договориться, подобрать компоненты среди того, что уже сделано, найти такие пути доработки, которые позволяют сэкономить время и усилия).
Это действительно не очень важно?