Комментарии 78
HR могут заметить, что Джуниор и Миддл специалисты, как правило, дольше находятся на одной позиции. Почему?
Потому, что автору статьи так захотелось написать.
Из моих личных наблюдений, из нескольких разных компаний, Junior прыгают туда-сюда, как кузнечики, Middle чуть дольше задерживаются, но вот как раз Senior задерживаются дольше всех. И по-моему, это логично: сложно выполнять задачи senior-уровня до того, как хорошо ознакомишься с проектом, коммуникации с заказчиками и бизнес-аналитиками также лучше идут, когда ты не воспринимаешься "новеньким".
Чем больше ты "синьор" тем сложнее\дольше "скакать", особенно если к переходу есть список требований (формальный титул позиции не меньше текущего, заработок +n%, стек\и такие-то, культура\методология\область деятельности новой компании такие-то).
У джуна список требований обычно попроще поэтому и переходы они совершают быстрее.
В точку! Полностью согласен!
Большой плюс набирать Джунов и Миддлов — это лояльность. Чем более юный специалист, тем выше лояльность к компании.
... и тем заметнее перемены, когда джуниор или миддл понимает, чтоб бизнес - это про деньги. И хорошо, когда он понимает, что не просто про деньги, а про взаимовыгодное сотрудничество.
Где-то посередине этого перехода наблюдается разочарование в одной картине "рабочего мира" со всеми этими Корпоративными Ценностями™ и Семейным Духом™ и неимение другой. Иногда получается кто-то вроде Доктора Хауса, но с профессиональными навыками уровня мидла.
Работал я в одной компании, которая решил сыграть в эту рулетку "сеньоры не нужны, вырастим сами". Три джуна за полгода наработали техдолга на 2 человекогода по оценке CTO. Ненужный сеньор потом полгода весь в мыле рефакторил эту "экономию бюджета" параллельно со своими задачами. Теперь компания как миленькая ищет сеньоров. Урок усвоен. Вы тоже усвоите.
За полгода "параллельно со своими задачами" отрефакторил "техдолга на 2 человекогода"? Это не сеньор, а какая-то машина для рефакторинга просто. Не верится, imho где-то в этой истории обман – или оценка завышена, или он так и не исправил ситуацию.
(но мысль, что нельзя оставлять джунов без присмотра, поддерживаю всеми лапами)
А как получилось, что рефакторинг сильно дороже самой разработки? Три джуна * полгода = полтора человекогода (в джунах). Если такая возможность есть, то проще было бы переписать это всё зановос с околонулевым техдолгом за условный человекогод.
Это так сеньор сказал) Он всё это время расставлял импорты в алфавитном порядке, и добавлял private к переменным. С воплями "кто вам делал это гуано". Видал таких.
Спасибо - поржал...
Я еще видел, как юзинги упорядочивали лесенкой - начиная от самой короткой строки, типа using NLog; до самой длинной (подключение проектов с очень длинными нэймспейсами).
но... зачем? Есть же автоформатеры кода, которые поправят код так, как надо. Или это в те времена, когда автоформатирование кода не в ходу было?
Ну а как ещё. В файле по 20-40 use. Все идут в разнобой. Почему не потратить две минуты времени и не упорядочить их хотябы по неймспейсам.
PhpStorm не форматирует автоматически это, а вставляет просто новые use вниз.
Бывает ещё так, что над файлом работает несколько человек и у каждого из них IDE использует разные правила для автоформатирования. Тогда в PR появляется масса ненужного шума из-за которого сложно понять что же конкретно собирался менять автор.
Так те же продукты intelij по дефолту импорты ставят по алфавиту, плюс автоформаттер можно конфигурировать путем настройки code style проекта. Хреновый был у вас сеньор, раз он руками это все двигал вместо того, чтобы потратить пару дней на настройку и потом одним кликом мыши все сделать моментально
переписать это всё зановос с околонулевым техдолгом за условный человекогод.
Порой на условный человекогод нет денег, а чинить надо уже сейчас.
Легко. Код уже в проде. На него уже завязались. Он уже приносит деньги.
Ремонтировать самолет в полете сложно и дорого.
Старый анекдот на тему:
Кардиолог приезжает в автосервис, ему работяга машину чинит, потом говорит:- Слышь, мужик, вот я мотор перебираю - и ты мотор перебираешь, только человеческий - почему тебе платят в 4 раза больше?Кардиолог кивает, идет к машине, включает зажигание и говорит работяге:- А попробуй, при работающем движке теперь - перебери!
Да, анекдот старый, и когда-то я над ним смеялся.
Но сейчас понимаю, что все не так - ни один хирург не перебирает человеческий мотор, который работает - либо сердце останавливают (с применением гипотермии), либо выводят из основного цикла (с применением искусственного мотора).
Так а разница? По аналогии - машина должна крутить колёса на пониженных оборотах, пока мотор подменяют электромотором, а настоящий мотор отключенным перебирают, тогда уже понадобится и план "операции", вместе с ассистентами.
Механик открывает капот, и смотрит, чё где потекло или не потекло, идёт на перекур, советуется с коллегой пока курит, возвращается, лезет внутрь - вроде собрал - ай нет, забыл трубку накинуть, которую отцеплял когда внутрь лез.
А прежде чем оперировать нужно обследовать из вне(окей, аналог осмотра под капотом), составить план операции, предусмотреть варианты развития, в том числе самые плохие, и сама операция ограничена по времени, нужно всё успеть за один заход, и сразу сделать всё правильно от самого начала, до самого конца. А рядом сидит анастезиолог, который заранее рассчитывает корректную дозу обезбаливающего, и добавляет по мере необходимости, если операция затягивается. Требования к квалификации несопоставимы, мотор можно и самому в гараже перебрать в течение месяца, а в случае ошибки, цена - не вполне работающий мотор.
Я к чему.
Анекдот всё ещё смешной))
А как получилось, что рефакторинг сильно дороже самой разработки?
А примерно также, как строить небоскреб на месте снесенной пятиэтажки в центре Москвы сильно дороже, чем строить такой же небоскреб посреди бескрайних просторов Балашихи или еще какого Красногорска. Требование деликатно работать с имеющимся наследием, в т.ч. с данными, плюс небходимость вкурить что же это там такое было сделано и почему именно так сделано - это все время на разработку только удлинняет.
Конечно, тут без уточнений сказать наверняка нельзя, но вполне возможно, что там обратно-независимая архитектура получилась, которую переписать за один подход невозможно. Как правило, джуны про это не особо задумываются, а больше пытаются построить расширяемую архитектуру, в силу своей неопытности. Хотя ВСЕГДА нужно помнить, что после вас ОБЯЗАТЕЛЬНО придет "сеньор", который скажет, что все говно и начнет все рефакторить.
Я правильно понял, что СТО сначала допустил самостоятельную работу 3 джунов приведшую к серьезному техдолгу, а затем еще и не смог корректно его оценить? Т.к. между "два человекогода" и "полгода параллельно основной работе" разница очень серьезная.
Странно, что все цепляются к оценке. Если в течение полугода написать код, отдать заказчику и дорабатывать по методике "и так сойдет", то кто сказал, что итоговый техдолг будет те же полгода? Возможно и меньше, возможно и больше. Переписать банальный перекладчик джейсонов после джуна и правда можно довольно быстро. А если у вас нетривиальные бизнес-кейсы плюс нетривиальная схема данных, то попасть можно довольно крупно, а править это по живому будет занимательным приседанием.
Как допустили джунов до таких дел? А вот так взяли и допустили. Я же сказал - сыграли в рулетку "сэкономим, вырастим своих джунов". Понадеялись, что метод fake it till you make it сработает.
На всякий случай замечу, что из вашего описания не понял, в чем же проблема в этом проекте в итоге была у компании. Провалили дедлайн? Качество? Бюджет? Не сделали все фичи?
Из описания - да, иногда так можно растить из джунов в сеньёры, если есть откуда брать подходящие задачи класса "не бей лежачего" + "выкинуть через полугода", ну и повышать градус постепенно. Особенно хорошо заходит, когда есть какие-то образцы кодовой базы, откуда джуны могут черпать мудрость.
Качество. Там, где сеньор заложил бы задел под новые хотелки, джуны херачили спагетти-процедурщиной напрямик лишь бы сделать. А хотелок было достаточно, заказчиков много и у каждого свои особенности. Через пару итераций джуновские направления встали колом - каждое следующее изменение требовало все больше времени и гарантированно приводило к регрессу. Поступает новое требование - джун не моргнув глазом берет под козырек, пыхтит 2 недели, выдает мерж-реквест на 2к строк в 50 файлах. Ревьювер фалломорфирует, тестеры фалломрофируют, релиз флооморофирует и съезжает на 2 неделю, босс фалломорфирует и идет извиняться перед заказчиком, что фичу придется подождать. Все попытки донести мысль о декомпозиции задач, планировании, архитектуре, солиде, наконец, ни к чему не приводили.
Двух джунов в итоге на мороз выставили. Третьего перевели исключительно на задачи уровня изи. А ненужный сеньор пошел это все исправлять - но в итоге выгорел и сам уволился. Вот так скэномили.
А я был в противоположной ситуации, когда компания нанимала только синьеров. Ушел через 3 месяца, потому что пилить crud и интегрировать очередной soap/json/etc провайдер данных, это как раз задачи мидлам или даже джунам.
А вы на какой позиции наблюдали эту занимательную историю?
Джуниоры и Миддлы могут предложить новое решение с их прежнего места работы/учёбы,
Тут у меня большие сомнения. Так-то и джуниор, и сеньор могут сказать "у нас на прошлом проекте использовался X для Y", но навыков Джуна или Мидла (если только это не "сильный мидл, почти сеньор) вряд ли хватит на то, чтобы сопоставить требования, которые были "там" и есть "тут", оценить подводные камни и издержки по внедрению того решения и принять взвешенное решение о целесообразности этого. А у сеньора и опыта прошлых проектов побольше обычно. Так что этот пункт вообще мимо.
Брать джунов и мидлов нужно только затем, что нужны новые сеньоры. Иначе скоро один сеньор будет стоить, как крыло от боинга (хотя я не скажу, что я против) :) В остальном в 99% случаев - это расход ресурсов и денег :) Сеньоры делают быстрее всё. И рутину, и сложные задачи. Что рутину часто впадлу делать - это другой вопрос. Но когда ты задачу решал 150 раз, то в 151 ты делаешь её примерно за минуту. Сеньорам есть что обсудить на ревью, и часто сеньорам лень менять компанию, так как денег платят везде на определённом уровне в тех же корпах +- одинаково. И если ты уже "устал от приключений", ты просто работаешь на проекте и не паришься. Чаще всего мотивацией смены работы я видел скуку, а не вопрос деньгах. Лидами вообще многие становится в принципе не хотят.
В большинстве своём сеньоры - это такие бывалые, уставшие профессионалы, которым плевать что делать, так как они умеют очень многое и на контекст задачи смотрят, как на предметную область. Бывает кто-то ещё горит работой, но за 6 лет+ ты начинаешь к программированию (коммерческому) относится филосовски. Пилишь какой-то пет проектик, если тебе не надоело программировать, так как там никто не меняет бизнес требования, не переобувается на лету, не нужно думать о коммерческих рисках использования той или иной технологии. А коммерция вся +- одна и та же, меняется по моему опыту разве что контекст. Поэтому нет смысла менять особо компанию, так как поменяешь в большинстве случаев одно на другое, если не подвернётся действительно супер интересный проект :)
tl/dr; (вру, прочитал)
Куча дурацких, порой откровенно неверных обоснований вместо трёх слов: джун дешевле сеньора.
Что ещё может сыграть в ту же сторону: "свой" миддл (уже нырнувший в проект) на краткосроке может оказаться полезней "чужого", только пришедшего сеньора.
Готовность выполнять рутинные задачи, насколько я могу судить, вообще не коррелирует с рангом. Легче адаптировать – хрень, сеньор, который не умеет адаптироваться – это просто старый закосневший джун. И так далее.
нельзя сводить всю команду к одним старшим уровням
Вообще да, "генералы не бегают". Я как-то работал в стартапе, куда в самом начале набрали звёзд за хорошие деньги (многие имена широко известны по выступлениям на популярных конференциях). Естественно все старались. За год концепция продукта менялась несколько раз, дизайн креативил, разработка выдавала фантастические решения (создав в процессе несколько до сих пор популярных в народе библиотек). Это было драйвово и весело, но в итоге все превратилось в глючное и неподдерживаемое . Потом фаундеры заменили супер-стар-команду на прикормленных аутсорсеров, оставив часть предыдущего состава не у дел в ролях консультантов. Те конечно звез с неба не хватали, но стоили меньше в разы и собрали с фактически с нуля вполне рабочий MVP за несколько месяцев.
Чисто по ощущениям, совмещение ролей, когда ты утром работаешь над архитектурой, а после обеда идёшь разбираться с каким-то нюансом в скриптах сборки или клепать формы - контрпродуктивно, поскольку вынуждает постоянно переключать контекст. В любом проекте есть уйма типовой работы, с которой может справиться даже новичок.
Ага. Да возьми пару звёзд и через полгода твой проект не сможет понять никто. Работать он может быть будет.
Спасибо, благодаря вашему комменту осознал пользу от джунов (не упомянутую в посте): если ты не можешь объяснить свой код джуну, то код – [censored]. Этакая опорная точка.
Если код организован так, что ты можешь давать задачи джунам и не бояться, что они что-то сломают (проверять надо только тот кусок, который джун делал) – кодовая база прекрасна.
Как бы есть подозрение что не все из стэка технологий джун может знать.
Это решаемо (если джун толковый – до уровня базового понимания технологии доводится быстро)
Если в стеке технологии, требующие серьёзного обучения (до уровня мидла) просто для чтения кода – может, в консерватории что-нибудь поправить?
Ну окей, базово понял да. Вот только если у нас что то крупное - это не фига не будет достаточным.
Ну прочитал он код того что там работает с очередью. Но если он не знает эти очереди, к чему они здесь, почему оно так - сломать он сможет только в путь.
Поддержу вас. Опыт у меня, может быть, и не 100500 лет, но припоминаю такой случай:
Собеседовался, нанимающим не понравилось, что я работал из СУБД только с MySQL, а "у нас на проекте PostgreSQL(!)". Кряхтели, сомневались, видимо, но оффер прислали. Начинаю вкатываться в проект. Думаю, наверное, у них там какие-то фишки именно PostgreSQL используются (пока отрабатывал на прежнем месте - попытался почитать, дома развернул, пощупал). Выхожу на новую работу, месяц работаю, два... Полгода. Ничего кроме ANSI SQL нет, а развертыванием и администрированием разработчики не занимаются от слова "вообще". Парам-парам-пам.
Поэтому, бывает оооочееь по-разному и иногда (часто) технологии тащат в проект разработчики, чтобы пощупать и поучить (в т.ч. и для резюме), а не потому, что эти технологии жизненно необходимы.
В любом проекте есть уйма типовой работы, с которой может справиться даже новичок.
У нас, например, такой работы очень мало. Рутинные задачи делаются один раз, второй, а в третий раз делать то же самое становится лень и задача автоматизируется. Минус в том, что для джунов нет работы, через которую они могли бы погружаться в проект. Даже если человек в чем-то разобрался, то скорее всего делать ещё раз то же самое по аналогии ему уже не придется, а будет снова задача, в которой придется что-то исследовать, искать варианты решения.
Даже если возникают какие-то типовые задачи, то синьор условно сделает их несколько штук в день, а джун будет одну задачу делать неделю.
а в третий раз делать то же самое становится лень и задача автоматизируется.
А что за предметная область? Моя команда сейчас работает небольшими инкрементами (иначе сильно растут риски) над, условно, автоматизацией документооборота. Самое сложное это разобраться в требованиях, придумать и согласовать решение со всеми заинтересованными лицами. Закодить, написать тесты, задеплоить, проверить, где-то обновить документацию это все довольно муторно, но уже не сложно. Джуны по началу теряются из-за количества церемоний, но при наличии гайдов, ментора и код ревью, быстро втягиваются. Синьеры лучше видят решение вцелом, но типовые задачи закрывают не сказать, что сильно быстрее.
На нашем проекте разобраться в требованиях - вообще не проблема, гораздо сложнее найти людей с опытом в этой области или без опыта, но кому было бы интересно этим заниматься.
Предметная область - разработка инструментов моделирования, анализа моделей, кодогенераторов и т.п. Вполне естественно, что с автоматизацией рутины сложностей нет, т.к. это одно из назначений самого продукта :) Поэтому джуны, которые закрывают типовые задачи по инструкции, не нужны, такие задачи (типа добавления новой формочки, поля, правил валидации, добавления новой нотации моделирования в инструмент, добавления отчета, написания boilerplate кода) уже автоматизированы, или могут быть автоматизированы, или делаются самим заказчиком без участия разработчиков. По сути мы делаем конструктор, который сами же и используем в разработке.
На мой взгляд многие задачи в ИТ проходят через такие стадии:
1) Сначала задача исследовательская, видны только какие-то первые шаги для её решения, как она будет реализована в деталях неизвестно. Для таких задач джуны бесполезны. Они или в принципе не сделают её ни за какое время, или будут делать в 10-50 раз дольше сеньора, или сделают что-то не то.
2) Затем задача тщательно документируется, становится типовой. Остается прочитать разные внутренние руководства по решению таких задач, по оформлению кода и т.п. Для таких задач, да, джуны вполне подходят.
3) Затем задача постепенно автоматизируется. Появляются какие-нибудь скрипты, кодогенераторы, движки с типовыми компонентами. Джун вряд ли сможет разработать что-то такое, но может использовать. Например, сгенерить boilerplate код и что-то ещё дописать. Или взять готовый компонент и задать параметры.
4) Наконец все эти инструменты внутренней автоматизации становятся отдельным продуктом, выходят на рынок и используются повсеместно, задача полностью автоматизирована. Начиная от каких-то внутренних задач. Например, оформление кода, поиск типовых ошибок могут быть автоматизированы с помощью SonarLint, Checkstyle, ESLint - для этой рутины уже не нужен ни джун, ни синьор. Генерация документации по коду. Или при разработке учетных систем, систем документооборота можно делать всё с нуля, а можно взять движок типа DevExpress XAF, или разработать свой такой движок. Тогда большая часть работы будет заключаться а) в описании схемы данных, описании формочек в виде модели (в основном это аналитическая работа, с которой синьор справится быстрее джуна) или б) в реализации сложных вещей, выходящих за рамки готового движка (с этим сеньор тоже справится лучше). В разработке инструментов моделирования я видел примеры, когда люди тратят очень много ресурсов, делая многие вещи с нуля и вручную, вместо того, чтобы взять готовый движок, использовать правильные технологии и сократить время разработки раз в 10.
Я сходу не могу придумать задачи в ИТ, которые невозможно довести до 4-ой стадии. Наверное часто это не делают по каким-то организационным причинам, проще нанять десяток синьоров и сотню джунов. Синьоры будут заниматься сложными задачами и писать инструкции, а джуны по этим инструкциям будут решать типовые задачи.
Хотя, блин, я всё-таки уверен, что сеньору лень заниматься рутиной и он будет искать варианты автоматизации и в итоге сделает задачу быстрее джуна. Например, у нас была такая задача. Есть структуры таможенных и других документов, для них описаны правила заполнения на русском языке. Нужно реализовать систему, которая будет проверять документы на соответствие этим правилам. Типов документов сотни. Правил заполнения для каждого от сотен до тысячи. Самый очевидный вариант решения следующий. Аналитики вникают в эти правила, пишут постановки разработчикам, разработчики реализуют всё в коде, покрывают тестами, тестировщики тестируют вручную. Отличный проект на сотню-другую человеколет, и для джунов работы полно. У нас не было столько джунов, поэтому мы пошли следующим путём. Правила описываются на формальном языке (что-то типа предикатной логики), а всё остальное генерится автоматически. Нужно несколько синьоров, которые реализуют этот транслятор из формального языка спецификации правил в валидаторы документов, а джуны не нужны вообще. Хотя даже при этом всё равно находилась какая-то рутинная работа, которую в принципе можно было бы дать джунам, например, перевод правил с русского языка на формальный. Но у джуна перевод тысячи правил займет неделю непрерывной механической работы. Мне это занятие надоело уже через несколько минут, я потратил день чтобы сделать табличку в Excel с формулами, которые делают это автоматически для большинства правил, а в сложных случаях можно дописать уже вручную.
На мой взгляд, даже если задача совершенно типовая и простая всё равно синьор справится с ней быстрее, потому что он будет искать какие-то варианты автоматизации рутины.
Правила описываются на формальном языке (что-то типа предикатной логики) , а всё остальное генерится автоматически.
Вы просто написали свой собственный язык программирования и обучили разработчиков писать на нем. Этот подход имеет право на жизнь, но далеко не всегда. Скорее даже это довольно нетипичный способ решать задачи.
С одной стороны, да, конечно! И есть мнение, что это чуть ли не единственный правильный подход к программированию. Когда-то очень давно прочитал эту статью и она запала мне в душу. По хорошему разработка любого приложения - это разработка своего DSL.
1) Это может быть прямо реальный DSL со своим синтаксисом. При этом синтаксис может быть текстовым (SQL, HTML, CSS, XML, XSLT, XPath, Gradle, Make, JSON, YAML, DOT, PlantUML, Docker, ...) или графическим (BPMN, UML, диаграммы SSIS, ...). А может быть и таким, и таким как у SysML v2. Разработчики постоянно пользуются такими языками. Постоянно появляются новые языки. Они могут быть разной степени сложности. Но если стоимость разработки какого-нибудь простого DSL - пару дней, а время изучения - пару часов, то что в этом плохого? Если это какой-то безумно сложный DSL, который нужно изучать годы и потом эти знания нигде не пригодятся, то наверное это просто не самый удачный язык. Не все DSL похожи на 1С.
2) Может быть DSL, встроенный в другой язык. Например, JavaDoc, LINQ, JSX.
3) Может быть DSL на базе языка с макросами (Lisp) или расширяемым синтаксисом (Isabelle). Тут создание своих своих языков - это просто обычный подход к разработке, с этого всё начинается.
4) Может быть DSL на базе JSON, XML, YAML в виде конфигурационных файлов. Например, GitLab CI/CD, Docker Compose, Ansible, Spring, ...
5) DSL в виде аннотаций. Тот же Spring, UML-профили.
6) Наконец, если все эти кастомные синтаксисы, конфиги и аннотации не для нас, мы просто пишем код на ЯП и всё, то даже в этом случае хорошее приложение состоит из набора микрофреймвоков или наборов типовых компонентов. Например, набор своих или чужих React-компонентов, из которых мы собираем UI. Набор компонентов для обработки каких-нибудь данных, рассылки уведомлений и т.д. Главная идея, что есть какая-то узкая область, например, UI приложения. Этот UI строит из какого ограниченного набора компонентов. А будет UI собираться в коде, описываться на YAML, рисоваться в виде диаграммки или текстом на специальном DSL, ... - вообще пофиг, это уже детали.
Многие фреймвоки реализуют сразу несколько вариантов из перечисленных выше. Например, в Spring одно и то же можно сделать вариантами 4, 5 и 6. Аналогично в Swagger. В React - варианты 2 и 6.
В общем, ещё раз подытожу идею, на мой взгляд, разработка любого приложения - это разработка своего DSL одним или сразу несколькими способами описанными выше. Я думаю, что это нормальный и правильный подход к разработке, когда программист смотрит на приложение с этой точки зрения. В противном случае код превращается в какую-то кашу с файлами на тыщи строк, с классами с десятками приватных полей и методов, которые через эти поля обмениваются какими-то данными и нужно часами дебажить этот код и рисовать на листе бумаги схему его работы, чтобы понять что там вообще происходит. Или если в приложении прямо очень много однотипного boilerplate кода, многие задачи решаются копипастой, куча рутинных задач, то возможно настало время как-то обобщить этот код, сделать свой микрофреймвок, вынести что-то в конфиги или даже сделать свой DSL. Я не то, что не вижу в этом никакой проблемы, а наоборот хороший сеньор должен мыслить такими категориями ещё до того, как рутина в принципе появилась.
С другой стороны, мы никакой собственный язык программирования не придумывали, а взяли готовый. Хотя это не язык программирования, а язык спецификации. Это тоже отдельная тема, я не хочу писать тут ещё столько же текста, пора уже сворачивать этот поток графоманства ) В 90-е высказывались идеи, что на UML можно нарисовать несколько квадратиков, по которым можно сгенерить любое приложение (веб-сайт, компьютерную игру, систему управления атомным реактором), а языки программирования и программисты не нужны вообще. По каким-то "неведомым" причинам идея оказалась несостоятельной :) И с тех пор бытует мнение, что вообще все эти квадратики со стрелочками, текстовые DSL и т.п. не нужны, потому что они не могут заменить языки программирования общего назначения. DSL абсолютное зло, не нужно использовать их нигде и никогда. Но сейчас как-то незаметно DSL стали использоваться практически везде (выше много примеров), а многие разработчики даже не осознают того, что какие-нибудь JavaDoc, Docker, GitLab CI/CD, LINQ, Swagger, Gradle и т.п. - это на самом деле DSL, языки, которые позволяют специфицировать на более высоком уровне абстракции что нужно сделать, чем это делается на ЯП общего назначения.
Безусловно здесь можно впасть в крайность, начать создавать какие-то безумные абстракции над абстракциями, создавать какие-то свои сложнейшие языки, в которых никто никогда не разберется. Поэтому первое что нужно сделать - это посмотреть не создавал ли кто-то такой язык уже до тебя. Например, в нашей предметной области (разработка инструментов моделирования) большая часть DSL уже придумана консорциумом Object Management Group. Тот же OCL для описания правил валидации или запросов к объектным моделям. QVT для преобразования моделей в модели, M2T для преобразования моделей в текстовое представление. MOF для описания языков моделирования. И т.д. Я видел много примеров, когда вместо специального DSL, придуманного умными людьми в серьезных компаниях, используют какие-нибудь VBA, Lua, JavaScript, C# и т.п., мотивируя это тем, что на hh.ru резюме JavaScript разработчиков дофига, а людей со знанием QVT нет вообще. Но в итоге получается печаль печальная, потому что JavaScript не предназначен, например, для преобразования моделей. На нём можно это сделать, но нет никакой гарантии, что в итоге не получится неподдерживаемый лапшакод. Потому что практически все JavaScript разработчики, разместившие своё резюме на hh, занимались совершенно другими задачами (фронтом или бэком), а не преобразованием UML моделей в BPMN модели и не реализацией какого-нибудь имитационного моделирования. Чё-то меня прямо прорвало, извиняюсь за этот поток )
Если подытожить весь этот поток:
1) Я думаю, что разработка своего DSL - это единственно правильный способ создания приложений.
2) Реализованы эти DSL могут быть совершенно разными способами: от диаграммы с квадратиками и стрелочками до микрофреймвока. Принципиальной разницы между ними я вообще не вижу, это детали реализации, какой способ удобнее, тот можно и использовать.
3) Каждый язык должен использоваться для своих задач. Если в коде много boilerplate кода и копипасты, возможно удобнее будет использовать какой-то более высокоуровневый язык.
4) Разные DSL используются практически повсеместно, постоянно создаются новые. Некоторые удачные, некоторые не очень удачные. Но это данность. Многие разработчики думаю, что используют только один ЯП, хотя реально они используют десятки языков, просто не осознают этого.
5) Безусловно есть неудачные примеры очень сложных и узкоспециализированных DSL или когда в приложении накручивают микрофреймвок над микрофреймвоком и в этом невозможно ничего понять. Но это не значит, что сам подход неправильный.
Блин, я никак не могу закончить это сообщение :) На самом деле после всего этого опуса до меня дошло, что я просто являюсь адептом языко-ориенированного программирования и расширяю его на всё программирование вообще. Т.е. в моём понимании все разработчики на самом деле используют ЯОП, просто в разной степени осознают это.
Кажется, сейчас, как обычно, всё сведётся к спору о терминах – выяснится, что вы с оппонентом придерживаетесь примерно одного мнения, но излагаете его по разному :-)
Многие фреймвоки реализуют сразу несколько вариантов из перечисленных выше. Например, в Spring одно и то же можно сделать вариантами 4, 5 и 6.
Нет, вы извините, но ставить равенство между тем, что в спринге можно описать кодом и тем, что можно описать конфигом (что аннотациями, что конфиг-файлами), категорически нельзя. Код писать всё равно придётся, конфигурация остаётся только конфигурацией, пусть и умной и с кучей хороших дефолтов в разных местах, о которых вы могли и не подумать.
Согласен. В случае с React наверное пример был корректный. Можно использовать JSX, а можно то же самое написать на JavaScript/TypeScript.
Для Spring, да, разными способами можно описать только конфигурацию приложения. А реализация всего этого всё равно пишется на ЯП общего назначения. Хотя если посмотреть на какой-нибудь Spring Cloud Gateway, то там в конфигах можно описывать уже достаточно сложные правила и может быть даже удобнее чем в коде.
И с тех пор бытует мнение, что вообще все эти квадратики со стрелочками, текстовые DSL и т.п. не нужны, потому что они не могут заменить языки программирования общего назначения
На то есть чисто технологические причины. Разработка DSL не уменьшает общую сложность решения, она лишь перекладывает ее из одного места в другое, зачастую увеличивая ее там напорядок.
Для работы с DSL нужен обмен знаниями и соответствующие инструменты (начиная с банальной подсветки синтаксиса и т.д.), инвестиции в разработку которых могут ни когда не окупиться.
Кодогенерация это ад в поддержке (ни кто не может сделать нормально с первого раза), поскольку нужно знать не только целевой язык, но и логику работы кодогенератора, и учитывать как изменение скажется на всей массе проектов, которые могут не быть под вашем контролем. Если же вы здесь пользователь, то можете ждать годами когда вендор соизволит починить баг в кодогенераторе.
Графический способ это лишь одно из возможных представлений, которое ни чего не говорит ни о надёжности, ни о нагрузках, ни о юзабилити, ни о массе других нефунциональных требованиях, которые существенно влияют на архитектуру. На этом уровне сложно решать вопросы версионирования и слияния. Это все мега удобно для проектирования, когда у вас один архитектор, десяток-другой сущностей и нужно показать определенные аспекты. Когда их становится больше, то диаграммы превращаются в месиво.
Короче я не против DSL как идеи, и в определенных задачах в них есть смысл. Но это ни разу не замена ЯП общего назначения.
Кодогенерация это ад в поддержке (ни кто не может сделать нормально с первого раза), поскольку нужно знать не только целевой язык, но и логику работы кодогенератора, и учитывать как изменение скажется на всей массе проектов, которые могут не быть под вашем контролем.
Другой вариант - интерпретация, но это может оказаться ещё большим адом, потому что фиг его знает что там в рантайме происходит, пока не запустишь не узнаешь. А в сгенеренный код можно хотя бы посмотреть.
В целом, да, конечно это ад. Когда Gradle или Maven проект не собирается, попробуй пойми что там внутри происходит. Или, например, SQL запросы тормозят и нужно смотреть планы их выполнения. С GitLab CI/CD я недавно намучился, прочитал тонны документации, pipeline нормально начал работать только после 150 запуска. В докере иногда загадочные вещи происходят.
Какая альтернатива-то? DSL и так используются везде, это данность. Отказаться от них и писать всё на языках программирования общего назначения? Но и в их компиляторах/интерпретаторах могут быть баги. Перейти на ассемблер?
Что делать с типовым boilerplate кодом? Мне лень даже копипастить один и тот же код, я скорее напишу какой-нибудь генератор, который это будет делать за меня.
Кодогенераторы бывают очень разные. Например, у меня транслятор из OCL в Java занимал 2000 строк. Транслятор из Xtext (BNF-подобный язык) в JavaScript занимал строк 200. Это достаточно простой код, который легко сопровождается. Я сталкивался и со сложными кодогенераторами, например, в SCADE один из кодогенераторов был написан на Tcl, проще было его с нуля переписать, чем разбираться. Но я не согласен с тем, что кодогенераторы это обязательно что-то очень сложное, что разрабатывается годами, занимает сотни тысяч строк кода.
На этом уровне сложно решать вопросы версионирования и слияния. Это все мега удобно для проектирования, когда у вас один архитектор, десяток-другой сущностей и нужно показать определенные аспекты. Когда их становится больше, то диаграммы превращаются в месиво.
На прошлом проекте в модели данных у нас были тысячи сущностей, сотни процессов. Десятки аналитиков в разных компаниях из разных стран, создающие эти модели. На текущем проекте больший акцент на процессах, их десятки тысяч, сотни моделировщиков. Со слиянием, да, есть сложности. Есть инструменты типа EMF Compare, EMF DiffMerge, ... которые позволяют это делать. Но на практике проще и правильнее разделить зоны ответственности, чтобы потребности в слиянии изменений не возникало вообще.
Короче я не против DSL как идеи, и в определенных задачах в них есть смысл. Но это ни разу не замена ЯП общего назначения.
Конечно это не замена, но я не вижу какой-то принципиальной пропасти между DSL и ЯП общего назначения. Например, мне нужно реализовать какого-нибудь поискового робота. Я могу описать для него конфиг на YAML:
description: News parser
crawl:
document: http://some-news.example.com
interval: 1m
article:
path: html/body/div.article
title: h1.title
body: div.content
publicationDate:
path: span.date
format: YYYY-mm-ddВ соответствии с этим конфигом робот может раз в минуту с указанного адреса скачивать HTML-страницу, находить на ней теги div с классом article, в каждом из них находить заголовок, содержание и дату новости.
Могу для того же самого запилить DSL:
define crawler('News parser') {
crawl('http://some-news.example.com') {
interva = 1m
for (`html/body/div.article`) {
add() {
title = `h1.title`
body = `div.content`
publicationDate = date(`span.date`, 'YYYY-mm-dd')
}
}
}
}Могу описать примерно то же самое на Java (псевдокод):
public class NewsCrawler implement ICrawler {
public String getDescription() { retrun "News crawler"; }
public int getInterval() { return 60; }
public void run() {
Document page = PageService.getPage("http://some-news.example.com");
for (Node article : page.get("html/body/div.article")) {
ArticleService.add(
article.get("h1.title"),
article.get("div.content"),
article.get(parseDate("span.date", "YYYY-mm-dd")));
}
}
}Могу сделать то же самое, но с аннотациями и Fluent API:
@Crawler("News crawler")
public class NewsCrawler {
@Crawl(interval = 60)
public ArticleProvider run() {
return Document.get("http://some-news.example.com")
.articles("html/body/div.article")
.title("h1.title")
.body("div.content")
.publicationDate("span.date", "YYYY-mm-dd");
}
}
}Я не вижу принципиальной разницы между всеми этими вариантами. Есть определенная предметная область "Парсинг сайтов". В ней есть свой набор базовых понятий: поисковый робот, документ, который парсится, материалы в этом документе, у которых есть заголовок, содержимое и дата.
Допустим у нас контора, которая пилит такие парсеры сайтов. На начальном этапе каждый пилит как хочет. Затем мы определяем структуру типового парсера, создаём какой-нибудь интерфейс парсера с тремя методами getDescription(), getInterval(), run(), а внутри run() можно писать что угодно. Затем мы пишем какие-нибудь рекомендации по содержимому метода run() типа для получения страницы желательно использовать такой-то класс, а для парсинга HTML такой-то. Затем мы можем реализовать типовые методы для получения страницы, для извлечения из неё материала и т.д. И уже на этом этапе мы создали не что иное как embedded DSL!
Если мы используем какой-нибудь Lisp, то можем пойти немного дальше и определить для нашего DSL более подходящий синтаксис, чем например в Java.
Можем пойти ещё дальше и разработать полностью свой синтаксис для нашего для DSL (например, с помощью Xtext, он практически даром даёт парсер, текстовый редактор с подстветкой синтаксиса и автодополнением). Можем не заморачивать со своим синтаксисом, а использовать тот же YAML.
А затем можем написать либо интерпретатор для этого DSL или этих YAML конфигов, либо транслятор в Java код или ещё во что-то. Причем результирующий код может выглядеть ровно так же как в примерах выше, это не обязан быть какой-то лютый нечитаемый треш.
Я не топлю за то, что абсолютно всегда нужно делать свой DSL с каким-то своим синтаксисом. Я говорю о том, что к разработке любого софта можно относиться как к созданию DSL, т.е. выделить в приложении какие-то осмысленные области, для каждой области определить набор базовых понятий и конструкций. А какой при этом у этих DSL будет синтаксис (какой-то кастомный, YAML, или это будет просто eDSL в Java) - вообще пофиг, что удобнее, то и нужно использовать.
Сделать язык это сложно. Правда сложно.
Даже довольно простой язык спроектировать так чтобы им можно было пользоваться и не страдать это уровень выше сеньоров. Людей способных на такое обычно звездами называют. И у них часто есть всякие PhD и статьи в интересных местах. А еще они Лисп любят (это личное наблюдение без пруфов).
Написать и развивать язык не сильно проще. Сеньоры плачут над практическими реализациями AST и оптимизаторами AST. Когда туда надо запилить новую фичу или поправить баг в корнер кейсе в глубинах реализации. Поддержка приемлимого басфактора для вашей реализации языка это дорого само по себе. На это надо жечь много времени сеньоров.
Это нормальный путь для написания софта. Но на него способен мало кто. Окупается он еще реже. Нанять джунов делать "типовые формочки" на любой модной сегодня технологии обычно проще и дешевле.
Я шесть лет назад, смотрел как фронтовики кроваво сражаются с комбо боксом с множественным выбором и поиском, прошло 6 лет. Бойня стала только кровавей) Но раньше её джун делал. С развитием новых технологий, задачка стала под силу только тимлидам)
На заре карьеры работал Джуном. Три Джуна подчинялись мидлу, три мидла сеньору. Очень чистый код, и большинство задач решались копипастой. Если у вас на проекте не так, то сеньора у вас там нет.
За следующие пять лет, даже близко такого не видел, зато в проекте всё сеньоры.
Сеньор руководящий командой из 12 человек это матерый тимлид. Код он будет писать максимум 1-2 дня в неделю. Остальное время он будет управлять людьми, сидеть на совещаниях о продукте и заниматься планированием.
Счастье если такие люди у вас на проекте есть. Их найти еще сложнее чем сеньоров.
Очень чистый код, и большинство задач решались копипастой
Чистый код с копипастой. Клёво.
Мне кажется, заголовок не соответствует статье. В статье говорится о том что не стоит оставлять одних лишь сеньоров. С таким утверждением согласен - сеньоры оставшись в одиночестве банально тухнут из-за обилия рутины и начинают страдать от синдрома самозванца.
Какие-то кадровые фантазии про сферических программистов. В статье верные джуны и нервозные сеньоры, по факту наоборот. Джун наберётся опыта и свалит с зарплатой, полученной за процесс, а сеньор будет колотиться до приемлемого результата, особо при этом не нервиничая, так как повидал уже всякого.
Прям ненависть к джунам какая-то. Может я что-то не понимаю в антиджуновских изречениях, но может проблема была в том, что набрали джунов, сказали работать и благополучно забыли про них? Менторство абормотов - не про деньги же да и вводить их в курс дел лень. К тому же слабо представляю себе сеньора, которому нравится когда его дёргают "сделай тут, поправь там и тут ещё сделай" и ещё меньше представляю работодателя, который будет платить большие деньги за работу джуна. Да и если тренд - сеньору делать работу джуна/мидла, то последние наверняка могут претендовать на зп приближеную этого самого сеньора. Ну и в таких перспективах теперешние сеньоры как динозавры ибо какой смысл учиться на ИТ, если тебя априори не возьмут на работу? Вобщем если в вашей организации отсутствует рутинная работа, то вы прям редкостные молодцы, в остальных случаях какой-то сюр
Посмотрел автора и вроде немного прояснилось (Прямой поиск и формирование IT команд) - просто hr продают джунов
Вам скорее всего не нужен Хабр
У статьи неверное и даже дезинформирующее название. Если по-честному, она должна называться "Вам скорее всего не нужен сеньор на каждую должность в проекте"
Тот момент, когда комментарии полезнее и интереснее статьи )
Почему-то не увидел в статье самого главного - про найм: "как нанять мидла, если владелец бизнеса или HR не разбирается в предметной области?". Работал с несколькими бизнесами, где за зарплату сеньора работали джуны и исправлять результаты их жизнедеятельности оказалось очень и очень дорого и сложно.
Почему все забыли о найме программистов?:)
Хорошие мидлы всем нужны. Но таких людей очень мало. Либо джуны, либо сеньоры.
Мидл - это переходный вариант, на год-два. Ибо это странно, когда человек секет в программировании, развился, но до сеньора не дорос. Те кто не дорастают, они и до мидлов не дорастают.
Есть конечно еще и роскстары, до туда, да, не все могут дорасти - это нужно талант иметь
Вам скорее всего нужен не Сеньор