Для примера я взял одну очень характерную вакансию. Сразу нужно сказать, что зарплата не указана: многие отсеивают такие объявления — и наверно, не зря. Но она очень показательна. Для удобства я пронумеровал предложения, чтобы составить список требований. Источников, разумеется, не будет, однако процитировано дословно:
Теперь разберём по пунктам. А точнее — как это читаю я, когда натыкаюсь на подобные предложения.
В этом пункте как раз всё нормально. Просто указаны актуальная версия библиотеки и язык.
Да, QML — это часть Qt, никто не спорит. Но есть маленький момент: конечно, возможно написать проект, который одновременно сидит на двух стульях, но мешать то и другое есть признак плохой архитектуры. Может быть, люди имеют ввиду только разработку на QML? Ну, в самом деле: проект пишется на QML, но нужны свои компоненты, а они пишутся на C++ с использованием QtWidgets… Пока непонятно, поэтому читаем дальше. Кстати, к архитектуре мы ещё вернёмся.
Какие конкретно системы имеются ввиду? Сразу возникают вопросы: сколько их у вас? Это несколько проектов, над которыми одному человеку надо работать одновременно или классическое программирование на Qt намешано в один монструозный проект с QML-ем и ещё какими-то подходами? Судя по тому, что QtWidgets в предыдущем пункте относится к так называемой «классической разработке на Qt» (делаем форму — пишем к ней класс) безо всякого QML, то становится понятно, что программисту придётся сидеть одновременно на двух стульях.
Это для чего написано? Чтобы не пришёл QML-щик, который C++ не видел ни разу в жизни? Или опыта текущих разработчиков недостаточно, чтобы перейти с QML обратно на QtWidgets? Может быть, они не хотят заниматься поддержкой старого кода?
Мне кажется, всё несколько сложней: дело в том, что стандартных возможностей QML как правило, недостаточно для полноценного приложения — поэтому приходится создавать свои QML-плагины. Для которых нужен C++. Другими словами, проект у людей уже был частично написан на QML, но дальше упёрлись в ту самую нехватку возможностей — а дальше QML-щик оказался то ли недостаточно проскиллован, то ли занят на двести процентов своего времени только тем, что создаёт формы, но QML-компоненты на C++ он так или иначе писать не может. Становится понятно, чем мы будем заниматься: это саппорт классического кода и создание новых QML-компонент.
Однако это уже не одна, а две вакансии. В классическом коде на Qt обычно море сложно-исправляемых багов и программист, который сидит на саппорте, будет занят фиксами больше ста процентов своего времени (работа с переработками). Новые QML-компоненты тоже не получится писать «время от времени», этим надо заниматься постоянно. Наверно думают, что человек будет в основном саппортить старый код, местами «быстренько и как-нибудь» заменяя их на QML. В этом случае встаёт вопрос, а кто занимается архитектурой всего этого безобразия? Вспоминаем пункт три: «мы и есть те спасатели». Короче, делай что хочешь, архитектурой всё равно заниматься некому, архитектора проектов никто нанимать не собирается, а менеджер не архитектор и этой темы не знает, поэтому всё свалят на нас.
Правда? Нет, я просто не могу поверить, что с плохим знанием чего-либо можно идти куда-то устраиваться. То есть об этом вообще стоило писать, а то ведь правда, придут с плохим? Может быть, нам что-нибудь в этом пункте расшифруют? Получается, что когда так пишут, то считают, что их текущие разработчики знают Qt недостаточно хорошо (чтобы это ни значило), а раз так, то когда-то уже пытались экономить на программистах.
Действительно, расшифровали. Разработка многопоточных приложений на Qt подразумевает действительно её хорошее знание. Вот только лично я читаю в этом требовании совершенно другое, не то, что наверняка имелось ввиду, когда писали эту фразу. Для начала давайте вообще разберёмся, зачем вообще Qt многопоточность?
Классическая часть Qt — это библиотека, основанная на обработке событий. Однако позже в неё был добавлен функционал, позволяющий запускать потоки. Однако весь интерфейс всё равно работает в одном-единственном главном потоке и пока вы не выскочили из предыдущей функции, другая не вызовется, как ни соединяй их между собой слотами-сигналами.
Многопоточная обработка обычно требуется на неинтерфейсном уровне: в Qt-приложениях часто так или иначе используется клиент-серверное разделение — и если сервер архитектурно спроектирован не совсем удачно (например, его вызовы строго синхронны), то в этом случае как раз потребуются потоки для организации ожидания на уровне интерфейсов. Что это означает в применения к вакансии?
Первое: интерфейсная часть между клиентом и сервером либо плохо спроектирована, либо отсутствует вовсе. Писали, как могли и как минимум, часть бизнес-логики замешана с клиентским кодом, а нам придётся частично заниматься системными программированием (доделывая то, что не доделал системный программист на уровне сервера). Тут надо сказать, что системный программист в таких коллективах обычно есть — но очень специфический. Это он придёт на собеседование, чтобы валить вас вопросами о стеке протоколов TCP/IP, хотя именно он обязан был так спроектировать систему, чтобы системного кода в окнах не было вовсе. И он же, кстати, получает максимальную зарплату из всех — а отдуваться за его недоделки придётся вам, с помощью многопоточного программирования.
Второе: как следствие из синхронных вызовов, программа уже так тормозит, что руководство компании (не путать с менеджерами) получилолюлей от инвесторов пользовательский фидбек. Этот фидбек был немногословным, но крайне эмоциональным… И теперь требует, чтобы программисты всё ускорили — причём сделали это как можно быстрей. О том, как такое произошло, нам скорее всего намекнут в следующем пункте.
Ох… это что-то из разряда «я умею кодить на C++, по понятия не имею о том, что такое ООП». Так не бывает. Кроме разве что студентов-выпускников, которые написали на C++ одну-единственную курсовую в стиле Си и которые по отклику на вакансию выявляются сразу и по возрасту. Следовательно, имеется ввиду что-то другое. Что именно?
Из собственного опыта я могу предположить, что в программе знатно накосячили до нас. Наверняка начиналось всё, как обычно, очень круто, интересно и весело: правильная архитектура, слои абстракций и всё такое, что обычно сопутствует грамотному проекту. Но потом началась гонка за функционалом, которая размыла слои абстракций. Скорее всего, если окажется, что проект давний, его изначальные разработчики сделали его на QtWidgets, но уже давно ушли — настолько давно, что лет пять вместо них успели поработать те самые молодые студенты, которые начали лепить QML (уверяя начальство, что это круто). Которые, в свою очередь, тоже выросли — и поняли, что тот лапшевидный код, который они писали по-началу, со временем превратился в равиоли из абстракций (см. антипаттерны). И теперь на каждое окно вызывается по десятку почти пустых микроклассов вместо одного нормального класса формы, которые жонглируют данными между собой — причём не напрямую, а через какой-нибудь буст-инжектор (это же было модно несколько лет назад). Заканчивается данное жонглирование тем, что продравшись через десятки лишних слоёв, вы натыкаетесь на тот самый лапшевидный код с «TODO: переписать всё по-человечески, когда появится время» где-то в укромном уголке проекта.
В итоге в коде не разобраться настолько, что его уже невозможно развивать. Программисты давно всё сообразили и свалили в более гостеприимные места. Однако менеджмент проекта ничему не научился и теперь (увидев простой QML-скрипт) считает, что проблему можно «по-быстрому» решить с помощью очередной серебряной пули. О том, что это скорее всего так, нам говорит следующий пункт:
Ну и наконец стало понятно, для чего проект. Рвзумеется, можно спорить (в комментариях), но разработка под Линукс в наше непростое время — это вовсе не идеалы свободного ПО (о котором мы все, наверно, мечтаем). В девяносто девяти процентов случаев это — безопасники с идеей следить за всем и вся, а в качестве линукса имеется ввиду Астра, потому что так сказал товарищ майор. То есть это не айтишная компания и о нормальных архитектурных подходах там никто не слышал, а все проблемы (из опыта) решаются средствами «подковать блоху». Отсюда вывод: зарплату не указали не зря. Тут надо троих сеньоров нанимать (с соответствующим количеством миддлов и джунов на каждого из них) для полного рефакторинга кода, а не искать «человека, который решит все проблемы». Однако работодатели этого позволить себе не могут, потому что такое возможно только в нормальной экономике со зрелым рынком инвестиций. Но это уже другая тема и о ней когда-нибудь в другой раз.
1 — Разработка ПО и доработка существующего на C++ (Qt5). 2 — Разработка GUI на QtWidgets/QML. 3 — Участие в проектировании архитектуры различных систем. 4 — Опыт разработки на C++. 5 — Хорошее знание Qt5. 6 — Опыт разработки многопоточных приложений. 7 — Понимание ООП. 8 — Знание Linux на уровне опытного пользователя.
Теперь разберём по пунктам. А точнее — как это читаю я, когда натыкаюсь на подобные предложения.
1. Разработка ПО и доработка существующего на C++ (Qt5)
В этом пункте как раз всё нормально. Просто указаны актуальная версия библиотеки и язык.
2. Разработка GUI на QtWidgets/QML
Да, QML — это часть Qt, никто не спорит. Но есть маленький момент: конечно, возможно написать проект, который одновременно сидит на двух стульях, но мешать то и другое есть признак плохой архитектуры. Может быть, люди имеют ввиду только разработку на QML? Ну, в самом деле: проект пишется на QML, но нужны свои компоненты, а они пишутся на C++ с использованием QtWidgets… Пока непонятно, поэтому читаем дальше. Кстати, к архитектуре мы ещё вернёмся.
3. Участие в проектировании архитектуры различных систем
Какие конкретно системы имеются ввиду? Сразу возникают вопросы: сколько их у вас? Это несколько проектов, над которыми одному человеку надо работать одновременно или классическое программирование на Qt намешано в один монструозный проект с QML-ем и ещё какими-то подходами? Судя по тому, что QtWidgets в предыдущем пункте относится к так называемой «классической разработке на Qt» (делаем форму — пишем к ней класс) безо всякого QML, то становится понятно, что программисту придётся сидеть одновременно на двух стульях.
4. Опыт разработки на C++
Это для чего написано? Чтобы не пришёл QML-щик, который C++ не видел ни разу в жизни? Или опыта текущих разработчиков недостаточно, чтобы перейти с QML обратно на QtWidgets? Может быть, они не хотят заниматься поддержкой старого кода?
Мне кажется, всё несколько сложней: дело в том, что стандартных возможностей QML как правило, недостаточно для полноценного приложения — поэтому приходится создавать свои QML-плагины. Для которых нужен C++. Другими словами, проект у людей уже был частично написан на QML, но дальше упёрлись в ту самую нехватку возможностей — а дальше QML-щик оказался то ли недостаточно проскиллован, то ли занят на двести процентов своего времени только тем, что создаёт формы, но QML-компоненты на C++ он так или иначе писать не может. Становится понятно, чем мы будем заниматься: это саппорт классического кода и создание новых QML-компонент.
Однако это уже не одна, а две вакансии. В классическом коде на Qt обычно море сложно-исправляемых багов и программист, который сидит на саппорте, будет занят фиксами больше ста процентов своего времени (работа с переработками). Новые QML-компоненты тоже не получится писать «время от времени», этим надо заниматься постоянно. Наверно думают, что человек будет в основном саппортить старый код, местами «быстренько и как-нибудь» заменяя их на QML. В этом случае встаёт вопрос, а кто занимается архитектурой всего этого безобразия? Вспоминаем пункт три: «мы и есть те спасатели». Короче, делай что хочешь, архитектурой всё равно заниматься некому, архитектора проектов никто нанимать не собирается, а менеджер не архитектор и этой темы не знает, поэтому всё свалят на нас.
5. Хорошее знание Qt5
Правда? Нет, я просто не могу поверить, что с плохим знанием чего-либо можно идти куда-то устраиваться. То есть об этом вообще стоило писать, а то ведь правда, придут с плохим? Может быть, нам что-нибудь в этом пункте расшифруют? Получается, что когда так пишут, то считают, что их текущие разработчики знают Qt недостаточно хорошо (чтобы это ни значило), а раз так, то когда-то уже пытались экономить на программистах.
6. Опыт разработки многопоточных приложений
Действительно, расшифровали. Разработка многопоточных приложений на Qt подразумевает действительно её хорошее знание. Вот только лично я читаю в этом требовании совершенно другое, не то, что наверняка имелось ввиду, когда писали эту фразу. Для начала давайте вообще разберёмся, зачем вообще Qt многопоточность?
Классическая часть Qt — это библиотека, основанная на обработке событий. Однако позже в неё был добавлен функционал, позволяющий запускать потоки. Однако весь интерфейс всё равно работает в одном-единственном главном потоке и пока вы не выскочили из предыдущей функции, другая не вызовется, как ни соединяй их между собой слотами-сигналами.
Многопоточная обработка обычно требуется на неинтерфейсном уровне: в Qt-приложениях часто так или иначе используется клиент-серверное разделение — и если сервер архитектурно спроектирован не совсем удачно (например, его вызовы строго синхронны), то в этом случае как раз потребуются потоки для организации ожидания на уровне интерфейсов. Что это означает в применения к вакансии?
Первое: интерфейсная часть между клиентом и сервером либо плохо спроектирована, либо отсутствует вовсе. Писали, как могли и как минимум, часть бизнес-логики замешана с клиентским кодом, а нам придётся частично заниматься системными программированием (доделывая то, что не доделал системный программист на уровне сервера). Тут надо сказать, что системный программист в таких коллективах обычно есть — но очень специфический. Это он придёт на собеседование, чтобы валить вас вопросами о стеке протоколов TCP/IP, хотя именно он обязан был так спроектировать систему, чтобы системного кода в окнах не было вовсе. И он же, кстати, получает максимальную зарплату из всех — а отдуваться за его недоделки придётся вам, с помощью многопоточного программирования.
Второе: как следствие из синхронных вызовов, программа уже так тормозит, что руководство компании (не путать с менеджерами) получило
7. Понимание ООП
Ох… это что-то из разряда «я умею кодить на C++, по понятия не имею о том, что такое ООП». Так не бывает. Кроме разве что студентов-выпускников, которые написали на C++ одну-единственную курсовую в стиле Си и которые по отклику на вакансию выявляются сразу и по возрасту. Следовательно, имеется ввиду что-то другое. Что именно?
Из собственного опыта я могу предположить, что в программе знатно накосячили до нас. Наверняка начиналось всё, как обычно, очень круто, интересно и весело: правильная архитектура, слои абстракций и всё такое, что обычно сопутствует грамотному проекту. Но потом началась гонка за функционалом, которая размыла слои абстракций. Скорее всего, если окажется, что проект давний, его изначальные разработчики сделали его на QtWidgets, но уже давно ушли — настолько давно, что лет пять вместо них успели поработать те самые молодые студенты, которые начали лепить QML (уверяя начальство, что это круто). Которые, в свою очередь, тоже выросли — и поняли, что тот лапшевидный код, который они писали по-началу, со временем превратился в равиоли из абстракций (см. антипаттерны). И теперь на каждое окно вызывается по десятку почти пустых микроклассов вместо одного нормального класса формы, которые жонглируют данными между собой — причём не напрямую, а через какой-нибудь буст-инжектор (это же было модно несколько лет назад). Заканчивается данное жонглирование тем, что продравшись через десятки лишних слоёв, вы натыкаетесь на тот самый лапшевидный код с «TODO: переписать всё по-человечески, когда появится время» где-то в укромном уголке проекта.
В итоге в коде не разобраться настолько, что его уже невозможно развивать. Программисты давно всё сообразили и свалили в более гостеприимные места. Однако менеджмент проекта ничему не научился и теперь (увидев простой QML-скрипт) считает, что проблему можно «по-быстрому» решить с помощью очередной серебряной пули. О том, что это скорее всего так, нам говорит следующий пункт:
8. Знание Linux на уровне опытного пользователя
Ну и наконец стало понятно, для чего проект. Рвзумеется, можно спорить (в комментариях), но разработка под Линукс в наше непростое время — это вовсе не идеалы свободного ПО (о котором мы все, наверно, мечтаем). В девяносто девяти процентов случаев это — безопасники с идеей следить за всем и вся, а в качестве линукса имеется ввиду Астра, потому что так сказал товарищ майор. То есть это не айтишная компания и о нормальных архитектурных подходах там никто не слышал, а все проблемы (из опыта) решаются средствами «подковать блоху». Отсюда вывод: зарплату не указали не зря. Тут надо троих сеньоров нанимать (с соответствующим количеством миддлов и джунов на каждого из них) для полного рефакторинга кода, а не искать «человека, который решит все проблемы». Однако работодатели этого позволить себе не могут, потому что такое возможно только в нормальной экономике со зрелым рынком инвестиций. Но это уже другая тема и о ней когда-нибудь в другой раз.
podde
Почему «разумеется»?
С чего вы взяли? Можно, пожалуйста, ссылку на статистику про 99%?