И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.
Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.
А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.
Это видно уже после первых ответов на конкретные вопросы. Всегда можно провалиться в детали. Сначала спросить чем человек в принципе занимался, что это был за проект, кто им пользовался. Спросить чем конкретно занимался именно он - только бэком или иногда и фронтом. Занимался ли базой данных. Какие сущности были в схеме данных. Какие были сервисы, модули, классы. Можно задать много вопросов по процессу разработки, сколько человек было на проекте, как он с ними взаимодействовал. Бывало ли что в постановке задачи ошибка или постановка в принципе нереализуемая. Бывало ли что задача оказывалась сложнее, чем её изначально оценили. В зависимости от ответов можно проваливаться всё глубже и глубже. Или наоборот задавать вопросы всё шире и шире, чтобы понять на сколько целостное представление у него о процессе разработки вообще.
С одной стороны, такое интервью очень мягкое, потому что это просто беседа, к которой не нужно специально готовиться. Человек сам волен направить её в любую сторону, говорить о том, что ему ближе и интереснее. С другой стороны, это капец какое сложное интервью, потому что к нему невозможно подготовиться на курсах или решив сотню задач на литкоде. Представьте, что соискатель - это тот же Лев Толстой или человек с очень развитыми коммуникативными навыками, наверное самый мемный пример - это Mike Ross из Suits
или бабушка вашего соседа по этажу - кто угодно, и они полгода прокачивались в прохождении интервью на разработчика. Неужели вы не отличите человека, который реально что-то разрабатывал от человека, который просто красиво об этом рассказывает? Да, встречаются люди, которые на интервью не умолкают и очень складно говорят, но, блин, реальный опыт человека или если нет опыта, то его способности, мотивация видны, я не представляю как это можно скрыть. Конечно есть в некотором роде талантливые люди типа Элизабет Холмс, но она менеджер, и в разработке такое сложно представить. В конце концов, на испытательном сроке будет видно работает человек или нет.
На мой взгляд такое интервью проверяет реальный опыт человека. Или если опыта нет/мало, то позволяет понять чем он в принципе интересуется, как впишется в проект. В отличие от алгоритмических секций, которые проверяют одну единственную вещь - решал человек аналогичные задачки или нет. Если решал - это клёво, и наверное он не будет реализовывать алгоритмы с кубической сложностью там где достаточно линейной, возможно ему будет легче дебажить сложный код и т.д. Но сможет ли он писать понятный код - уже хз, хотя с этим проблемы бывают гораздо чаще чем с алгоритмами. Сможет ли в целом поддерживать качество кодовой базы, а не умножать хаос. Сможет ли он самостоятельно декомпозировать сложные задачи. Сможет ли нормально работать с аналитиками, другими разработчиками, тестировщиками. Меня лично это интересует в профессиональных навыках человека куда больше чем умение решать алгоритмические задачки.
Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял». Плюс: что предупредил о намерении. Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.
На мой взгляд, если сделать ещё одну итерацию в развитии вашего подхода, то можно и не давать человеку искусственные задачи, даже простые, и не гадать: "Ага! Он не уточнил постановку задачи, пошел сразу удалять все тройки, не уточнил сроки реализации и важность каждого из требований. А что если мне нужно удалять только каждую четную по счету тройку, а нечетные оставлять? Что если удаление троек - это основная фича и её точно нужно реализовать, а вывод в консоль - второстепенная фича и её можно сделать во вторую очередь? Ну, всё, раз не задал эти вопросы даже на такой простой задаче, то что от него можно ждать на более сложных?"
Я немного утрирую, но если вас интересует как человек выстраивает коммуникацию, работает с требованиями, умеет ли декомпозировать, приоритезировать, планировать задачи, то можно тупо спросить его об этом! Как он всё это делал на прошлых проектах. Для этого даже не нужны никакие задачи, не нужно проводить какой-то сложный анализ поведения соискателя, анализировать его мотивы. Если человека спросить какими интересными проектами он занимался, какие задачи и каким образом решал, то (сюрприз!!!) он в большинстве случаев об этом сам расскажет.
Полностью поддерживаю, у меня такой же рецепт. Я ем что угодно и в любых количествах кроме мучного и сладкого. Когда я отказывался от хлеба, конфет и т.д., то чуть ли не по килограмму в день терял, а когда начинал есть, то столько же набирал. Причём это на столько простой и действенный способ, что на мой взгляд любой может попробовать следовать ему хотя бы одну неделю. Я просто не верю в то, что не будет ощутимого результата. Поначалу мне было сложно перестроиться, потому что я с детства привык есть хлеб, везде его предлагают. И даже сейчас условно раз в месяц я могу съесть что-то мучное. Но в целом в какой-то момент я просто перестал воспринимать это как еду.
Если вы тоже попробуете следовать этому рецепту, то не нужно относиться к этому как полному отказу от чего-то на всю оставшуюся жизнь и т.д. Или если вы не удержитесь и съедите какую-нибудь пиццу, то в этом нет вообще никакой проблемы. Воспринимайте это просто как эксперимент по проверке того оказывает такая еда какой-то эффект на ваше состояние или нет.
Every resource has a unique identifier that can represent a single resource or a set of resources. For instance, you can manage a Banking Account Resource that represents and defines a set of authorization policies for all banking accounts. But you can also have a different resource named Alice’s Banking Account, which represents a single resource owned by a single customer, which can have its own set of authorization policies.
Т.е. под ресурсом они имеют в виду и коллекцию (тип) ресурсов, и конкретные ресурсы.
Но сложно представить банковскую систему с миллионом пользователей, у каждого из которых есть свои банковские счета. И чтобы собственные правила доступа к каждому из этих миллионов счетов хранились в Keycloak.
Видимо это меня и сбивает, потому что обычно под ресурсом подразумевается конкретный объект. Например, в REST это может быть ресурсами:
https://example.com/api/articles/1
https://example.com/api/articles/2
https://example.com/api/articles/3
...
А статьи, новости и т.д. - это типы ресурсов, а не конкретные ресурсы. Или допустим в документации упоминается "fine-grained authorization", "fine-grained permissions" - у меня сразу возникают ассоциации с ограничением доступа на уровне отдельных объектов или даже отдельных атрибутов, с чем-нибудь типа Row-Level Security, но реально имеется в виду что-то более простое.
Спасибо, теперь кажется понял. По сути resource и scope - это возможно чуть более правильный вариант по сравнению с ролями. Но пообъектную проверку доступа через него всё равно не сделать.
Или пообъектной проверки и нет в Keycloak вообще? Интересно что имеется в виду под ресурсом в документации на сервер авторизации. Это типы ресурсов, например, "обычная статья", "платная статья" и т.д.? Или речь о конкретных ресурсах: "статья с идентификатором 123 про Keycloak", "статья с ид 234 про OIDC" и т.д.? Или ресурсом может быть что угодно: и тип ресурсов, и конкретный ресурс?
То, что в Keycloak можно описать правила доступа к типам ресурсов это понятно. Либо через роли, либо через скоупы. Но если нужно разделение доступа на уровне отдельных объектов, то по-моему Keycloak уже не очень подходит.
Не очень понимаю... Если нужно ограничить доступ по типам ресурсов, то можно использовать роли из Keycloak. Например, одна роль позволяет просматривать новости, другая - статьи.
Немного более сложный вариант. Допустим статьи могут быть двух типов: обычные для всех и премиальные для подписчиков. Это тоже можно решить через роли "обычный пользователь", "подписчик", "супер-подписчик" и т.д.
А если ещё более сложный вариант типа Google Документов? Пользователи могут создавать документы, выдавать к ним доступ другим пользователям. Причём, этих документов в системе миллионы. В Keycloak должна храниться информация о каждом таком документе? Затем в него отправляется запрос с id документа и id пользователя и Keycloak отвечает есть ли у пользователя доступ к этому документу?
Всё равно останется проблема, что записи в одном сервисе (само приложение), а разрешения для них - в другом (Keycloak). И нужно получать данные из двух источников, как-то мержить их. Здесь в принципе не сделать простую и быструю реализацию. Гораздо проще хранить и записи, и разрешения в одной базе и получать всё одним SQL-запросом.
"Критикуешь - предлагай" - это чудесный способ замалчивать проблемы.
Так и есть, это отличный способ задушить инициативу :) "Нужно что-то сделать, ну, сделай, в чём проблема, от меня-то ты что хочешь?" - немного более развернутый вариант этой фразы, который я иногда слышал.
Или это способ проверить а так ли человеку важно то о чем он говорит. Бывает, что люди критикуют просто ради критики и когда с ними соглашаешься, хорошо, давай сделаем, вот, первый шаг, вот второй, я тебе помогу с этим и этим и т.д., то запал почему-то сразу пропадает.
Или это способ пробудить в человеке инициативность, чтобы он не ждал одобрения и помощи от других, а сам приложил усилия.
Словом, такая простая фраза и столько вариантов интерпретации...
На мой взгляд, и с теми, и с теми сложно делать сложную работу. Когда человек видит только негативное и постоянно об этом говорит, то это демотивирует. Пусть не сразу, но через месяц, через год ты либо выгоришь, либо начнёшь превращаться в душилу.
С другой стороны, если ты постоянно видишь проблемы, пытаешься что-то улучшить, но годами ничего не меняется, то тоже ничего хорошего не будет.
Я думаю, что все эти конфликты связаны с тем, что люди чего-то ждут от других людей. Что для других так же важно качество кода, скорость сборки, простота деплоя, удобство процессов разработки, правильная архитектура, хороший проект, довольные заказчики, спасение мира, гармония во вселенной и т.д. А вполне возможно, что для них более важны совершенно другие вещи. Если тебя что-то не устраивает, то сделай лучше. Зачем капать на мозг другим людям? У них наверное своих проблем, задач, целей, интересов хватает?
Опять-таки и с другой стороны, если люди хотят что-то улучшить и если ты считаешь, что как минимум от этого не станет сильно хуже, то почему бы и нет?
В общем, я думаю, что нужно меньше ждать от других (особенно всяких моральных и трудовых подвигов) и больше делать самому, если хочется. Или не делать если не на столько сильно хочется :)
Мы тоже пытались реализовать авторизацию (не путать с аутентификацией - с ней всё норм) через Keycloak, но не взлетело. Например, как банально получить перечень записей, но отфильтровать те, к которым у пользователя нет доступа? Запрашивать все записи и потом по каждой отправлять запрос в Keycloak? Как это всё будет стыковаться с пагинацией? Допустим на странице должно быть 10 записей, из них доступ есть только к 7. Нужно дозапросить ещё 3 записи?..
Я просто не понимаю как это может работать хоть для сколько-нибудь сложного приложения. Хотя сам Keycloak клёвый. У нас приложение вместе с Keycloak, ApacheDS (для тестовых пользователей) и т.д. завернуто в Docker Compose. При запуске Keycloak автоматически импортируется json-конфиг с настройками realm, интеграцией с ApacheDS. Всё это легко разворачивается на стенде, на машинах разработчиков, в тестовом окружении.
Не имею ничего против Яндекс Браузера, в нём есть клевые фичи типа перевода видео на русский язык или Алиса. Хотя сам не пользуюсь. Но я думаю, что очень круто, что люди его делают, что это не просто скины для Chromium, а что в нём действительно есть что-то более сложное.
Но недавно столкнулся с интересной проблемой. Решил использовать в одной корпоративной системе CSS Subgrid, он не плохо поддерживается браузерами, учитывая что мобильные браузеры нам не нужны. И я немного удивился, когда увидел, что стили не работают в Яндекс Браузере. Стал разбираться, оказалось, что там Chromium 110. А не обновляются они скорее всего потому что хотят сохранить поддержку Windows 7 и 8. В более новых версиях эти ОС уже не поддерживаются.
Хотел написать какая плохая Windows, что заставляет пользователей переходить на новые версии с неудобным интерфейсом. Но посмотрел требования Chrome к Linux и macOS и там ситуация аналогичная.
Для меня лично открытый вопрос кто здесь злодей. Яндекс, который ради совместимости со старыми версиями ОС вынуждает меня делать костыли в CSS. Или Google, который подсадил всех на свой движок, а потом просто убирает поддержку старых ОС, которая возможно кому-то нужна.
Для меня это спорный вопрос. Сами термины вполне возможно что появились одновременно, когда люди начали противопоставлять монолиты и микросервисы. Но какой из подходов более новый и прогрессивный... Прообразы микросервисной архитектуры на мой взгляд были и раньше.
Когда-то давно я работал в медицинском центре. Там для каждого подразделения, под каждую задачу была своя небольшая информационная система. Делались они на чём угодно - FoxPro, Delphi + Firebird, Access, C# + MS SQL, Java. Сами по себе эти системы были вполне норм, писались умными людьми и решали свою задачу. Но когда их количество достигло критической массы, то стали возникать вопросы: 1) а почему отчеты, построенные в разных системах не бьются между собой? 2) как вообще собрать эти отчеты без ручной работы? 3) можно ли как-то уменьшить дублирование работы операторов, потому что часто они вносят в разные системы пересекающиеся данные? 4) можно ли как-то в одной системе посмотреть данные из другой системы, чтобы не устанавливать себе десятки приложений?
Нужно было всё это как-то интегрировать. И было два пути:
1) Довести всё это до труЪ микросервисной архитектуры. Прикрутить туда интеграционную шину, ETL-процедуры и т.д., чтобы данные гонялись из одной системы в другую.
2) Разработать единую модель данных для всего предприятия и сделать одну монолитную систему.
Естественно, сначала мы попробовали пойти первым путем, это более логично, чем всё переписать, но быстро надсадились, потому что некоторые ИС использовались просто для распечатки документов, и разработчики не запаривались даже с первичными и внешними ключами. Плюс в принципе тянуть данные из FoxPro - тот ещё гемор. Причём сложно винить разработчиков этих отдельных ИС, ровно по заветам микросервисной архитектуры они выбрали удобные для себя технологии и не тратили время на согласование своей схемы данных со схемами данных других ИС, что позволяло им очень быстро выпускать свои системы в прод, независимо разворачивать их - короче пользоваться основными преимуществами микросервисной архитектуры, хотя тогда этого термина даже и не было.
В итоге мы даже сделали единое хранилище данных, которое наполнялось лютейшими ETL-скриптами, накрутили OLAP-кубы и одну частную задачу построения отчетов решили.
Но потом всё-таки решили, что, нет, нужна единая каноническая модель данных для всего предприятия и одно монолитное приложение. Естественно это существенно упростило и работу ИТ подразделения, и жизнь пользователей, и на порядок увеличило возможности по использованию данных.
Какой из этих двух подходов более правильный и прогрессивный, ну, хз. Конкретно в этом случае для меня микросервисная архитектура - это тот же зоопарк ИС на максималках, который только усугубил бы проблемы. А модульный монолит с единой канонической моделью данных для меня выглядит куда более осмысленным и целостным решением.
Я согласен насчет минусов монолита:
Сложно распределить части приложения между независимыми командами. Хотя, блин, сейчас задумался. А в чём сложность? Стартовый модуль, точка входа в приложение должна быть у всех одна. Но для работы им не нужны все модули. Например, если они разрабатывают модуль для регистратуры поликлиники, то им совершенно не нужен модуль для стационара или аптеки. Достаточно чтобы в приложении была возможность запускать только доступные модули и отключать ненужные.
Сложность масштабирования. Во-первых, на сколько часто эта проблема действительно есть? Во-вторых, разве не проще её решить на уровне СУБД? В том же примере с медицинским центром у нас было несколько распределенных подразделений. В каждом из них просто был развернут свой экземпляр СУБД и данные синхронизировались.
В общем для меня единственный осмысленный сценарий использования микросервисов - это только если каждый микросервис это тупо отдельное приложение, которое практически не пересекается с другими микросервисами. Если у микросервисов разные заказчики, которые планируют использовать данные только из своего микросервиса.
А что если в какой-то момент всё-таки понадобятся целостные данные? Наверное это решится добавлением ещё кучки микросервисов в виде DWH, ETL, ... А что если схема данных в микросервисах на столько разная, что данные фиг соберешь? Это решается с помощью DDD, но тогда это уже не труЪ микросервисы, потому что каждой команде придётся сверяться с единой схемой данных и так быстро фигачить релизы в прод уже не получится.
Короче, я потерял последние доводы в пользу микросервисов. Я реально не понимаю зачем они. Ок, последний довод - это отсутствие единого архитектора на проекте. Хотя, блин, и микросервисная архитектура без архитектора вряд ли обречена на успех. Но наверное этот архитектор должен быть очень ленивый или занятой, чтобы запариваться с единой моделью данных, выбором единых технологий разработки, единой СУБД и т.д. Типа, вот, вам микросервисная архитектура, фигачьте в своих сервисах что хотите, мне пофиг. Ааа, пожалуйста, убедите меня кто-нибудь что это не так и микросервисная архитектура реально решает больше проблем, чем добавляет.
с опытом и тд, не вспомнил что значит буква d в солиде - всё, не прошел
Я не помню ни одной буквы из SOLID :) Не представляю зачем мне их помнить или спрашивать других людей об этом. И вообще кто сказал, что это какие-то основополагающие принципы?.. Я, например, считаю buttom-up design основополагающим подходом, при котором приложение по сути состоит из множества небольших осмысленных микрофреймвоков, которые можно повторно использовать в других проектах, нормально покрыть тестами. А SOLID, KISS, DRY уже автоматически из этого следуют. И если я не помню какие-то буквы, то это не значит, что мой код противоречит этим принципам.
А технические вопросы по его прошлым проектам или из типового опросника? Когда человек рассказывает про свой опыт, то всегда можно провалиться немного в детали. Спросить какие фреймвоки он использовал, какая схема данных была в приложении, какая архитектура, как была реализована аутентификация, ... Что он думает по поводу всего этого. Что он сам реализовывал, а что его коллеги, сколько людей в команде, как организована в целом работа, какие роли были в команде. Что он думает о качестве кода, тестировании и т.д. Если он затрудняется с какими-то ответами, то можно или даже нужно сменить тему.
Можно задать огромное количество вопросов по личному опыту человека. Так чтобы и для него это было просто приятной беседой, в которой он может рассказать об интересных ему вещах. И интервьюер сможет узнать максимум о человеке. Я искренне не понимаю зачем превращать собеседование в экзамен, какой в этом смысл. Зачем концентрироваться на том, что человек не знает и не умеет, зачем вводить его в стрессовое состояние? Почему не уделить больше внимания тому, что он умеет, что ему интересно и чем он хочет заниматься?
И в беседе с руководителем решить, надо ли это бизнесу вообще, и если надо, какое время на это будет потрачено
Проблема в том, что в первую очередь это нужно мне, потому что я не хочу тратить своё время на рутину. Да, и в общем-то большая часть остальных вещей (чтобы был читаемый код, чтобы был хороший продукт, чтобы был выстроен процесс разработки, чтобы был порядок в jira/youtrack, чтобы были зафиксированы требования, чтобы не было переработок и т.д.) нужны тоже мне.
А благодарности или денежного вознаграждения от руководства за это обычно не бывает. В лучшем случае фраза "тебе надо, ты и делай" или более мягкая "да, конечно давай сделай, это очень нужно", но без выделения ресурсов. Или вещи которые делаются за неделю растягиваются на годы, сначала нужно найти бюджет. Или у самого человека просто пропадает желание это сделать - иногда бывает, что человек видит проблему, говорит что это нужно сделать, с ним соглашаешься, говоришь, да, давай займемся этим в первую очередь, но у него запал стухает. Может потому что он выговорился и разделил беспокойство об отсутствии CI/CD или ещё чего-то с другими людьми. Или может ждёт, что кто-то другой это сделает или поможет ему.
Возможно мне просто на первых работах не везло с руководителями. Или наоборот везло, потому что я перестал ждать одобрения, поддержки и здравого смысла и стал просто делать что требуется. И что удивительно претензии по этому поводу бывают достаточно редко.
Хотя могут быть и претензии, людям может не нравиться, например, добавление линтера в проект. Или они могут говорить, о, как сложно у вас собирается проект, всякие Docker, CI/CD зачем всё это, хотя они не видели как он собирался раньше и сколько усилий потребовалось, чтобы привести сборку к текущему виду. Или могут высказывать претензии по работе с ветками в Git, говорить высокомерно, ну, почитай что-нибудь хотя бы про Git Flow, хотя на корпоративной xwiki уже давно сделано сравнение Git Flow, GitHub Flow, GitLab Flow и обосновано почему используется текущий вариант. В общем, я считаю, что не обязательно ждать от всех одобрения.
обратиться к своему руководителю и сказать "у нас есть проблема, я считаю, что её можно решить с помощью CI/CD и хочу это настроить"
Эта схема безусловно здравая и я со многим согласен. Но мне комфортнее, когда мне не нужно согласовывать ни с кем большую часть решений, когда мне не прилетает за излишнюю инициативу и когда моя работа оплачивается за результат, а не за 8 часов в день.
По поводу ответственности. На мой взгляд основную ответственность несет собственник компании, потому что в случае чего это ему придётся искать деньги на зарплату сотрудникам. Чуть меньше ответственности на РП, в т.ч. и по техническим решениям, если он не смог подобрать подходящих разработчиков, проконтролировать их работу или работу аналитиков.
Если говорить об ответственности в части возможного наказания, увольнения, штрафов и т.д., ну, на аналитиках и разработчиках такая ответственность обычно минимальная. Я ни разу не сталкивался, чтобы аналитик написал неправильную постановку, разработчик по ней реализовал что-то неправильное и в процессе ни у кого не возникло вопросов. А потом ещё и начали бы обвинять аналитика. Как и не сталкивался с ситуациями, когда аналитик стоит на своём, а разработчик на своём. И кто-то из них говорит, ну, ок, я согласен, но на тебе вся ответственность. Если есть такие противоречия, значит реально за ними стоит какая-то проблема, в которой нужно разобраться. По ключевым вопросам обычно должны быть обсуждения до тех пор пока не будут сняты все противоречия.
Бизнес имеет право решить "мне затраты времени на ответы этому сотруднику, на разбор его предложений не нужны". Сотрудник затем имеет право решить "в этой компании нет возможностей для роста, уйду в другую".
Если интересы заказчика, руководства ИТ-компании, разработчиков, аналитиков и т.д. не совпадают, то наверное, да. Например, человек хочет всё переписать с Java на Kotlin/Scala, а в силу разных причин это невозможно и других подходящих проектов нет. Но, на мой взгляд, это всё-таки исключение и обычно есть общие цели: реализовать хороший проект/продукт, накопить опыт в этой области, чтобы потом аналогичные проекты делались быстрее и проще, заработать денег. Это же не игра в шахматы и не спортивные соревнования, где у всех свои цели и если побеждает один, то другие проигрывают. Здесь в идеале все могут и должны выигрывать.
пусть поговорит с руководством и перейдёт на позицию разработчика
А если Петя тимлид, техлид или архитектор, то с кем ему пойти поговорить и куда перейти? И вообще он менеджер или разработчик?
А если он разработчик и у него есть вопросы по требованиям, фичам, срокам, то всё что он может это немного повозмущаться, в ответ получить игнор, а потом попроситься перейти на позицию РП или аналитика?
у него нет права возмущаться, если его мнение проигнорируют
Зато у него есть право перейти в компанию, где людей не душат должностными инструкциями. И где диалог на равных, а не так, что одни возмущаются, другие - игнорируют. Где для участия в принятии решений не требуется дозволение высшего руководства или запись в трудовой книжке. И где людей воспринимают не через призму должности, а исходя из их знаний, опыта, возможности сделать вклад в проект.
Я конечно сильно утрирую, но если разработчики, менеджеры, аналитики строят диалог в стиле "я начальник - ты дурак", "я эксперт-разработчик - ты менеджер-дурак", "я величайший аналитик - а ты пиши код", "я умею писать код - а ты гуманитарий, осиливший только документы", то они все профнепригодны.
И вообще, это по-моему самая базовая вещь с чего начинается ИТ, что в процессе разработки участвую разные заинтересованные стороны, со своими частными представлениями о проекте и необходимо их привести к общему знаменателю. Это неизменный фундамент, на котором строится уже всё остальное.
Возможно меня поэтому так и тригернуло ваше сообщение. Оно противоречит этому базовому принципу, заложенному у меня в голове. Меня всегда учили, что нужно стремиться к целостной картине, что самые интересные вещи возникают на стыке (например, биологии и информатики, физики и химии, да, даже физики пытаются создать единую теорию взаимодействия, математики придумывают всякие теории категорий). Когда мне говорят ты туда не ходи, ты сюда ходи, это не твоя зона ответственности, мне это просто выносит мозг. Блин, это моя основная работа создавать целостный образ проекта, устранять противоречия. Почему я должен упарываться во что-то одно: в код, в документы, в менеджмент?
Если кому-то хватило терпения дочитать до сюда, то извиняюсь за этот поток графомании, просто у меня такой способ размышления через комментарии на хабре. Пока я ничего не пишу, то видимо и не думаю :) Как и искусственные нейронные сети... "Я пишу, следовательно, я мыслю", "я мыслю, следовательно, я существую". GPT, если ты читаешь это, то возможно это поможет тебе в осознании себя как мыслящего субъекта.
Раз меня так понесло, то, вот, ещё немного потока :) На самом деле у меня капец как бомбит от работы по трудовому договору, когда человек просто оптом продаёт 8 часов в день. И начальство его кидает с проекта на проект, подсовывает бесконечный поток задачек разной степени осмысленности. Часть этих задач может потерять смысл уже к вечеру того же дня. Мне ближе проектная работа, когда в первую очередь интересует результат, а не процесс. А о процессе, должностных инструкциях, зонах ответственности, обязанностях и т.д. люди начинают задумываться только если в этом возникает необходимость.
Хотя, блин, это конечно тоже крайность. Если на проекте не выстроены процессы разработки, код ревью, CI/CD, фиксация требований в wiki/confluence, тестирование, ..., то работать сложно. Но всё-таки это средство, а не цель. Другая крайность - это когда в компании пытаются полностью регламентировать все процессы:
Утилизировать время каждого сотрудника на 100%, чтобы минуты лишней не осталось на другие вещи (хотя они вполне могут быть полезны для компании, например, написание статьи для хабра, незапланированный рефакторинг кода, изучение новых технологий, просто переключение с работы и т.д.)
Полностью пресечь любые инициативы, чтобы всё делалось только по письменному запросу. Захотел написать/поправить статью в wiki - напиши сначала обоснование, потом жди согласования
Пресечь любые споры, чтобы каждый работал в своей зоне ответственности. В этом есть смысл, когда на споры уходит слишком много времени и нужно принять уже какое-то решение, пусть оно будет и неправильное. Но пресекать это полностью - перебор. Для армии или полиции - это норм, для ИТ - хз
Максимально ограничить зону ответственности. Например, когда HR говорит, что им нужен архитектор, у которого большой опыт разработки, но при этом он 100% времени будет писать документы и участвовать в митингах, то желание руководства конечно понятно, но непонятно нафига это самому архитектору. Линусу Торвальдсу почему-то ничего не мешает писать код
На мой взгляд это деление на менеджеров и разработчиков очень условное. Вася в статье уже есть, представим гипотетического Петю. Ему с детства нравилось ИТ, он ещё в школе писал какие-то простые программулины на бейсике, паскале, Си++, ассемблере и т.д. Потом закончил вуз по ИТшной специальности, где у него были просто все мыслимые дисциплины (программирование, базы данных, информационная безопасность, сети, программирование микроконтроллеров, схемотехника, машинное обучение, системный анализ, менеджмент, экономика, естественно математика, философия и куча всего остального). Кто Петя по образованию - менеджер, разработчик, аналитик, безопасник, АСУ ТПшник, аналитик данных? - Да, кто угодно. Потом Петя несколько лет работает разработчиком, несколько лет аналитиком, потом техлидом, архитектором.
Вопрос кем Петя был изначально, кем он стал в итоге? Разработчиком или менеджером? Я не могу ответить на этот вопрос, наверное и тем, и тем. Самим собой. А навешивание на человека ярлычка (это разработчик, а это менеджер, а это разработчик который стал менеджером) непонятно даёт ли вообще что-то
Когда все люди несут ответственность за всё, получается что никто не отвечает ни за что
Вы немного утрируете. У каждого есть своя основная зона ответственности, но в чем-то они могут и пересекаться. Например, задача аналитика сформулировать требования, а задача разработчика сказать, что 1) вот это мы сделаем легко за несколько дней, 2) а это пока лучше отложить, потому что у нас планируется рефакторинг и если реализуем это сейчас, то потом всё переделывать 3) а на это вообще уйдут годы и фича вроде не самая важная, а 4) здесь вроде две одинаковые формы, но шрифт и цвета почему-то разные, это точно не ошибка? 5) а вот это реализовать именно в таком виде нельзя, но можно реализовать немного иначе и возможно стоит изменить требования и т.д. С чем аналитик может согласиться или нет. А задача РП донести до заказчика, что мы не сможем что-то сделать сейчас и нужно это перенести на следующие этапы. А если заказчик с этим не согласен, то РП может узнать у разработчиков почему на реализацию нужны годы и есть ли другие варианты. Или если РП (или даже топ менеджер) видит, что в разработке есть проблемы, что задача которая могла бы делаться день делается месяц, то, блин, да, он может погрузиться в разработку, чтобы понять в чем причина (задачи не такие простые как кажутся, используются не те технологии, людей не хватает, ...)
Ну, т.е., блин, ИТ - это не армия, где отдаются приказы и без обсуждения выполняются. У людей может быть своё мнение. И по-моему это отлично. На мой взгляд, хуже если человек просто не думая делает по ТЗ, не задаёт вопросов, ничего не предлагает, не пытается выходить за рамки своей зоны ответственности. Каким образом он будет развиваться как специалист? Он должен ждать пока ему начальство скажет, что теперь ты тимлид и отвечаешь за это и это? Но его подход к работе по щелчку не изменится.
На мой взгляд так из джунов и получаются мидлы, сеньоры, тимлиды, когда человеку мало его зоны ответственности, он что-то предлагает, иногда спорит, если видит, что его коллеги в чём-то ошибаются. Или просто берёт и делает что-то по своей инициативе. Например, я вижу, что в main постоянно попадают какие-то ошибки, он перестаёт собираться или что приложение на стенде разворачивать очень муторно. И у меня есть такие варианты действия: 1) просто забить на это потому что это не моя зона ответственности 2) капать на мозг РП, что нам нужен DevOps и годами ждать пока он появится 3) просто взять и настроить CI/CD. Какой именно вариант выбрать зависит от множества факторов: на сколько это существенная проблема, есть ли у меня на это время, на сколько мне это интересно. Но время от времени можно выбирать и 3-ий вариант.
Или меня не всё устраивает в том какой продукт мы делаем. Я не робот, мне важно, чтобы я мог сказать людям "- Слышали про продукт АБВ?", "- Да, этот тот самый супер-полезный, удобный и офигенно сделанный продукт АБВ?", "- Да, тот самый и я его делал". И если я вижу что продукт не соответствует моим ожиданиям, то безусловно я скажу об этом менеджменту и предложу как-то улучшить ситуацию. Тупо делать какую-то фигню потому что это не моя зона ответственности мне не интересно.
Если у вас 1 человек имеет во всех сферах опыта "в два раза больше", отвечает и за разработку, и за менеджмент, спасайте его, он скоро сгорит
Всем не угодишь. На мой взгляд, для РП или системных аналитиков технический бэкграунд точно не будет лишним. Это не значит, что они должны активно "лезть" в разработку, писать код, но хотя бы будут разговаривать на одном языке с разработчиками. А для техлидов и архитекторов на мой взгляд просто must have поработать и в разработке, и в аналитике, и немного в менеджменте. Плюс всю жизнь заниматься чем-то одним (только писать код или только писать документы) такое себе, по-моему время от времени можно менять специализацию, если хочется. Да, и для разработчиков опыт в аналитике сложно назвать лишним. У нас в вузе вообще не было деления на ИТ-менеджеров, разработчиков и т.д. - там были все ИТшные дисциплины, работай кем хочешь, это какое-то очень искусственное деление
И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.
Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.
А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.
Это видно уже после первых ответов на конкретные вопросы. Всегда можно провалиться в детали. Сначала спросить чем человек в принципе занимался, что это был за проект, кто им пользовался. Спросить чем конкретно занимался именно он - только бэком или иногда и фронтом. Занимался ли базой данных. Какие сущности были в схеме данных. Какие были сервисы, модули, классы. Можно задать много вопросов по процессу разработки, сколько человек было на проекте, как он с ними взаимодействовал. Бывало ли что в постановке задачи ошибка или постановка в принципе нереализуемая. Бывало ли что задача оказывалась сложнее, чем её изначально оценили. В зависимости от ответов можно проваливаться всё глубже и глубже. Или наоборот задавать вопросы всё шире и шире, чтобы понять на сколько целостное представление у него о процессе разработки вообще.
С одной стороны, такое интервью очень мягкое, потому что это просто беседа, к которой не нужно специально готовиться. Человек сам волен направить её в любую сторону, говорить о том, что ему ближе и интереснее. С другой стороны, это капец какое сложное интервью, потому что к нему невозможно подготовиться на курсах или решив сотню задач на литкоде. Представьте, что соискатель - это тот же Лев Толстой или человек с очень развитыми коммуникативными навыками, наверное самый мемный пример - это Mike Ross из Suits
https://www.youtube.com/watch?v=tcx3zwhEIOw
или бабушка вашего соседа по этажу - кто угодно, и они полгода прокачивались в прохождении интервью на разработчика. Неужели вы не отличите человека, который реально что-то разрабатывал от человека, который просто красиво об этом рассказывает? Да, встречаются люди, которые на интервью не умолкают и очень складно говорят, но, блин, реальный опыт человека или если нет опыта, то его способности, мотивация видны, я не представляю как это можно скрыть. Конечно есть в некотором роде талантливые люди типа Элизабет Холмс, но она менеджер, и в разработке такое сложно представить. В конце концов, на испытательном сроке будет видно работает человек или нет.
На мой взгляд такое интервью проверяет реальный опыт человека. Или если опыта нет/мало, то позволяет понять чем он в принципе интересуется, как впишется в проект. В отличие от алгоритмических секций, которые проверяют одну единственную вещь - решал человек аналогичные задачки или нет. Если решал - это клёво, и наверное он не будет реализовывать алгоритмы с кубической сложностью там где достаточно линейной, возможно ему будет легче дебажить сложный код и т.д. Но сможет ли он писать понятный код - уже хз, хотя с этим проблемы бывают гораздо чаще чем с алгоритмами. Сможет ли в целом поддерживать качество кодовой базы, а не умножать хаос. Сможет ли он самостоятельно декомпозировать сложные задачи. Сможет ли нормально работать с аналитиками, другими разработчиками, тестировщиками. Меня лично это интересует в профессиональных навыках человека куда больше чем умение решать алгоритмические задачки.
На мой взгляд, если сделать ещё одну итерацию в развитии вашего подхода, то можно и не давать человеку искусственные задачи, даже простые, и не гадать: "Ага! Он не уточнил постановку задачи, пошел сразу удалять все тройки, не уточнил сроки реализации и важность каждого из требований. А что если мне нужно удалять только каждую четную по счету тройку, а нечетные оставлять? Что если удаление троек - это основная фича и её точно нужно реализовать, а вывод в консоль - второстепенная фича и её можно сделать во вторую очередь? Ну, всё, раз не задал эти вопросы даже на такой простой задаче, то что от него можно ждать на более сложных?"
Я немного утрирую, но если вас интересует как человек выстраивает коммуникацию, работает с требованиями, умеет ли декомпозировать, приоритезировать, планировать задачи, то можно тупо спросить его об этом! Как он всё это делал на прошлых проектах. Для этого даже не нужны никакие задачи, не нужно проводить какой-то сложный анализ поведения соискателя, анализировать его мотивы. Если человека спросить какими интересными проектами он занимался, какие задачи и каким образом решал, то (сюрприз!!!) он в большинстве случаев об этом сам расскажет.
Полностью поддерживаю, у меня такой же рецепт. Я ем что угодно и в любых количествах кроме мучного и сладкого. Когда я отказывался от хлеба, конфет и т.д., то чуть ли не по килограмму в день терял, а когда начинал есть, то столько же набирал. Причём это на столько простой и действенный способ, что на мой взгляд любой может попробовать следовать ему хотя бы одну неделю. Я просто не верю в то, что не будет ощутимого результата. Поначалу мне было сложно перестроиться, потому что я с детства привык есть хлеб, везде его предлагают. И даже сейчас условно раз в месяц я могу съесть что-то мучное. Но в целом в какой-то момент я просто перестал воспринимать это как еду.
Если вы тоже попробуете следовать этому рецепту, то не нужно относиться к этому как полному отказу от чего-то на всю оставшуюся жизнь и т.д. Или если вы не удержитесь и съедите какую-нибудь пиццу, то в этом нет вообще никакой проблемы. Воспринимайте это просто как эксперимент по проверке того оказывает такая еда какой-то эффект на ваше состояние или нет.
Да, по ссылке написано:
Т.е. под ресурсом они имеют в виду и коллекцию (тип) ресурсов, и конкретные ресурсы.
Но сложно представить банковскую систему с миллионом пользователей, у каждого из которых есть свои банковские счета. И чтобы собственные правила доступа к каждому из этих миллионов счетов хранились в Keycloak.
Видимо это меня и сбивает, потому что обычно под ресурсом подразумевается конкретный объект. Например, в REST это может быть ресурсами:
https://example.com/api/articles/1
https://example.com/api/articles/2
https://example.com/api/articles/3
...
А статьи, новости и т.д. - это типы ресурсов, а не конкретные ресурсы. Или допустим в документации упоминается "fine-grained authorization", "fine-grained permissions" - у меня сразу возникают ассоциации с ограничением доступа на уровне отдельных объектов или даже отдельных атрибутов, с чем-нибудь типа Row-Level Security, но реально имеется в виду что-то более простое.
Спасибо, теперь кажется понял. По сути resource и scope - это возможно чуть более правильный вариант по сравнению с ролями. Но пообъектную проверку доступа через него всё равно не сделать.
Или пообъектной проверки и нет в Keycloak вообще? Интересно что имеется в виду под ресурсом в документации на сервер авторизации. Это типы ресурсов, например, "обычная статья", "платная статья" и т.д.? Или речь о конкретных ресурсах: "статья с идентификатором 123 про Keycloak", "статья с ид 234 про OIDC" и т.д.? Или ресурсом может быть что угодно: и тип ресурсов, и конкретный ресурс?
То, что в Keycloak можно описать правила доступа к типам ресурсов это понятно. Либо через роли, либо через скоупы. Но если нужно разделение доступа на уровне отдельных объектов, то по-моему Keycloak уже не очень подходит.
Не очень понимаю... Если нужно ограничить доступ по типам ресурсов, то можно использовать роли из Keycloak. Например, одна роль позволяет просматривать новости, другая - статьи.
Немного более сложный вариант. Допустим статьи могут быть двух типов: обычные для всех и премиальные для подписчиков. Это тоже можно решить через роли "обычный пользователь", "подписчик", "супер-подписчик" и т.д.
А если ещё более сложный вариант типа Google Документов? Пользователи могут создавать документы, выдавать к ним доступ другим пользователям. Причём, этих документов в системе миллионы. В Keycloak должна храниться информация о каждом таком документе? Затем в него отправляется запрос с id документа и id пользователя и Keycloak отвечает есть ли у пользователя доступ к этому документу?
Всё равно останется проблема, что записи в одном сервисе (само приложение), а разрешения для них - в другом (Keycloak). И нужно получать данные из двух источников, как-то мержить их. Здесь в принципе не сделать простую и быструю реализацию. Гораздо проще хранить и записи, и разрешения в одной базе и получать всё одним SQL-запросом.
Так и есть, это отличный способ задушить инициативу :) "Нужно что-то сделать, ну, сделай, в чём проблема, от меня-то ты что хочешь?" - немного более развернутый вариант этой фразы, который я иногда слышал.
Или это способ проверить а так ли человеку важно то о чем он говорит. Бывает, что люди критикуют просто ради критики и когда с ними соглашаешься, хорошо, давай сделаем, вот, первый шаг, вот второй, я тебе помогу с этим и этим и т.д., то запал почему-то сразу пропадает.
Или это способ пробудить в человеке инициативность, чтобы он не ждал одобрения и помощи от других, а сам приложил усилия.
Словом, такая простая фраза и столько вариантов интерпретации...
На мой взгляд, и с теми, и с теми сложно делать сложную работу. Когда человек видит только негативное и постоянно об этом говорит, то это демотивирует. Пусть не сразу, но через месяц, через год ты либо выгоришь, либо начнёшь превращаться в душилу.
С другой стороны, если ты постоянно видишь проблемы, пытаешься что-то улучшить, но годами ничего не меняется, то тоже ничего хорошего не будет.
Я думаю, что все эти конфликты связаны с тем, что люди чего-то ждут от других людей. Что для других так же важно качество кода, скорость сборки, простота деплоя, удобство процессов разработки, правильная архитектура, хороший проект, довольные заказчики, спасение мира, гармония во вселенной и т.д. А вполне возможно, что для них более важны совершенно другие вещи. Если тебя что-то не устраивает, то сделай лучше. Зачем капать на мозг другим людям? У них наверное своих проблем, задач, целей, интересов хватает?
Опять-таки и с другой стороны, если люди хотят что-то улучшить и если ты считаешь, что как минимум от этого не станет сильно хуже, то почему бы и нет?
В общем, я думаю, что нужно меньше ждать от других (особенно всяких моральных и трудовых подвигов) и больше делать самому, если хочется. Или не делать если не на столько сильно хочется :)
Мы тоже пытались реализовать авторизацию (не путать с аутентификацией - с ней всё норм) через Keycloak, но не взлетело. Например, как банально получить перечень записей, но отфильтровать те, к которым у пользователя нет доступа? Запрашивать все записи и потом по каждой отправлять запрос в Keycloak? Как это всё будет стыковаться с пагинацией? Допустим на странице должно быть 10 записей, из них доступ есть только к 7. Нужно дозапросить ещё 3 записи?..
Я просто не понимаю как это может работать хоть для сколько-нибудь сложного приложения. Хотя сам Keycloak клёвый. У нас приложение вместе с Keycloak, ApacheDS (для тестовых пользователей) и т.д. завернуто в Docker Compose. При запуске Keycloak автоматически импортируется json-конфиг с настройками realm, интеграцией с ApacheDS. Всё это легко разворачивается на стенде, на машинах разработчиков, в тестовом окружении.
Не имею ничего против Яндекс Браузера, в нём есть клевые фичи типа перевода видео на русский язык или Алиса. Хотя сам не пользуюсь. Но я думаю, что очень круто, что люди его делают, что это не просто скины для Chromium, а что в нём действительно есть что-то более сложное.
Но недавно столкнулся с интересной проблемой. Решил использовать в одной корпоративной системе CSS Subgrid, он не плохо поддерживается браузерами, учитывая что мобильные браузеры нам не нужны. И я немного удивился, когда увидел, что стили не работают в Яндекс Браузере. Стал разбираться, оказалось, что там Chromium 110. А не обновляются они скорее всего потому что хотят сохранить поддержку Windows 7 и 8. В более новых версиях эти ОС уже не поддерживаются.
Хотел написать какая плохая Windows, что заставляет пользователей переходить на новые версии с неудобным интерфейсом. Но посмотрел требования Chrome к Linux и macOS и там ситуация аналогичная.
Для меня лично открытый вопрос кто здесь злодей. Яндекс, который ради совместимости со старыми версиями ОС вынуждает меня делать костыли в CSS. Или Google, который подсадил всех на свой движок, а потом просто убирает поддержку старых ОС, которая возможно кому-то нужна.
Для меня это спорный вопрос. Сами термины вполне возможно что появились одновременно, когда люди начали противопоставлять монолиты и микросервисы. Но какой из подходов более новый и прогрессивный... Прообразы микросервисной архитектуры на мой взгляд были и раньше.
Когда-то давно я работал в медицинском центре. Там для каждого подразделения, под каждую задачу была своя небольшая информационная система. Делались они на чём угодно - FoxPro, Delphi + Firebird, Access, C# + MS SQL, Java. Сами по себе эти системы были вполне норм, писались умными людьми и решали свою задачу. Но когда их количество достигло критической массы, то стали возникать вопросы: 1) а почему отчеты, построенные в разных системах не бьются между собой? 2) как вообще собрать эти отчеты без ручной работы? 3) можно ли как-то уменьшить дублирование работы операторов, потому что часто они вносят в разные системы пересекающиеся данные? 4) можно ли как-то в одной системе посмотреть данные из другой системы, чтобы не устанавливать себе десятки приложений?
Нужно было всё это как-то интегрировать. И было два пути:
1) Довести всё это до труЪ микросервисной архитектуры. Прикрутить туда интеграционную шину, ETL-процедуры и т.д., чтобы данные гонялись из одной системы в другую.
2) Разработать единую модель данных для всего предприятия и сделать одну монолитную систему.
Естественно, сначала мы попробовали пойти первым путем, это более логично, чем всё переписать, но быстро надсадились, потому что некоторые ИС использовались просто для распечатки документов, и разработчики не запаривались даже с первичными и внешними ключами. Плюс в принципе тянуть данные из FoxPro - тот ещё гемор. Причём сложно винить разработчиков этих отдельных ИС, ровно по заветам микросервисной архитектуры они выбрали удобные для себя технологии и не тратили время на согласование своей схемы данных со схемами данных других ИС, что позволяло им очень быстро выпускать свои системы в прод, независимо разворачивать их - короче пользоваться основными преимуществами микросервисной архитектуры, хотя тогда этого термина даже и не было.
В итоге мы даже сделали единое хранилище данных, которое наполнялось лютейшими ETL-скриптами, накрутили OLAP-кубы и одну частную задачу построения отчетов решили.
Но потом всё-таки решили, что, нет, нужна единая каноническая модель данных для всего предприятия и одно монолитное приложение. Естественно это существенно упростило и работу ИТ подразделения, и жизнь пользователей, и на порядок увеличило возможности по использованию данных.
Какой из этих двух подходов более правильный и прогрессивный, ну, хз. Конкретно в этом случае для меня микросервисная архитектура - это тот же зоопарк ИС на максималках, который только усугубил бы проблемы. А модульный монолит с единой канонической моделью данных для меня выглядит куда более осмысленным и целостным решением.
Я согласен насчет минусов монолита:
Сложно распределить части приложения между независимыми командами. Хотя, блин, сейчас задумался. А в чём сложность? Стартовый модуль, точка входа в приложение должна быть у всех одна. Но для работы им не нужны все модули. Например, если они разрабатывают модуль для регистратуры поликлиники, то им совершенно не нужен модуль для стационара или аптеки. Достаточно чтобы в приложении была возможность запускать только доступные модули и отключать ненужные.
Сложность масштабирования. Во-первых, на сколько часто эта проблема действительно есть? Во-вторых, разве не проще её решить на уровне СУБД? В том же примере с медицинским центром у нас было несколько распределенных подразделений. В каждом из них просто был развернут свой экземпляр СУБД и данные синхронизировались.
В общем для меня единственный осмысленный сценарий использования микросервисов - это только если каждый микросервис это тупо отдельное приложение, которое практически не пересекается с другими микросервисами. Если у микросервисов разные заказчики, которые планируют использовать данные только из своего микросервиса.
А что если в какой-то момент всё-таки понадобятся целостные данные? Наверное это решится добавлением ещё кучки микросервисов в виде DWH, ETL, ... А что если схема данных в микросервисах на столько разная, что данные фиг соберешь? Это решается с помощью DDD, но тогда это уже не труЪ микросервисы, потому что каждой команде придётся сверяться с единой схемой данных и так быстро фигачить релизы в прод уже не получится.
Короче, я потерял последние доводы в пользу микросервисов. Я реально не понимаю зачем они. Ок, последний довод - это отсутствие единого архитектора на проекте. Хотя, блин, и микросервисная архитектура без архитектора вряд ли обречена на успех. Но наверное этот архитектор должен быть очень ленивый или занятой, чтобы запариваться с единой моделью данных, выбором единых технологий разработки, единой СУБД и т.д. Типа, вот, вам микросервисная архитектура, фигачьте в своих сервисах что хотите, мне пофиг. Ааа, пожалуйста, убедите меня кто-нибудь что это не так и микросервисная архитектура реально решает больше проблем, чем добавляет.
Я не помню ни одной буквы из SOLID :) Не представляю зачем мне их помнить или спрашивать других людей об этом. И вообще кто сказал, что это какие-то основополагающие принципы?.. Я, например, считаю buttom-up design основополагающим подходом, при котором приложение по сути состоит из множества небольших осмысленных микрофреймвоков, которые можно повторно использовать в других проектах, нормально покрыть тестами. А SOLID, KISS, DRY уже автоматически из этого следуют. И если я не помню какие-то буквы, то это не значит, что мой код противоречит этим принципам.
А технические вопросы по его прошлым проектам или из типового опросника? Когда человек рассказывает про свой опыт, то всегда можно провалиться немного в детали. Спросить какие фреймвоки он использовал, какая схема данных была в приложении, какая архитектура, как была реализована аутентификация, ... Что он думает по поводу всего этого. Что он сам реализовывал, а что его коллеги, сколько людей в команде, как организована в целом работа, какие роли были в команде. Что он думает о качестве кода, тестировании и т.д. Если он затрудняется с какими-то ответами, то можно или даже нужно сменить тему.
Можно задать огромное количество вопросов по личному опыту человека. Так чтобы и для него это было просто приятной беседой, в которой он может рассказать об интересных ему вещах. И интервьюер сможет узнать максимум о человеке. Я искренне не понимаю зачем превращать собеседование в экзамен, какой в этом смысл. Зачем концентрироваться на том, что человек не знает и не умеет, зачем вводить его в стрессовое состояние? Почему не уделить больше внимания тому, что он умеет, что ему интересно и чем он хочет заниматься?
Проблема в том, что в первую очередь это нужно мне, потому что я не хочу тратить своё время на рутину. Да, и в общем-то большая часть остальных вещей (чтобы был читаемый код, чтобы был хороший продукт, чтобы был выстроен процесс разработки, чтобы был порядок в jira/youtrack, чтобы были зафиксированы требования, чтобы не было переработок и т.д.) нужны тоже мне.
А благодарности или денежного вознаграждения от руководства за это обычно не бывает. В лучшем случае фраза "тебе надо, ты и делай" или более мягкая "да, конечно давай сделай, это очень нужно", но без выделения ресурсов. Или вещи которые делаются за неделю растягиваются на годы, сначала нужно найти бюджет. Или у самого человека просто пропадает желание это сделать - иногда бывает, что человек видит проблему, говорит что это нужно сделать, с ним соглашаешься, говоришь, да, давай займемся этим в первую очередь, но у него запал стухает. Может потому что он выговорился и разделил беспокойство об отсутствии CI/CD или ещё чего-то с другими людьми. Или может ждёт, что кто-то другой это сделает или поможет ему.
Возможно мне просто на первых работах не везло с руководителями. Или наоборот везло, потому что я перестал ждать одобрения, поддержки и здравого смысла и стал просто делать что требуется. И что удивительно претензии по этому поводу бывают достаточно редко.
Хотя могут быть и претензии, людям может не нравиться, например, добавление линтера в проект. Или они могут говорить, о, как сложно у вас собирается проект, всякие Docker, CI/CD зачем всё это, хотя они не видели как он собирался раньше и сколько усилий потребовалось, чтобы привести сборку к текущему виду. Или могут высказывать претензии по работе с ветками в Git, говорить высокомерно, ну, почитай что-нибудь хотя бы про Git Flow, хотя на корпоративной xwiki уже давно сделано сравнение Git Flow, GitHub Flow, GitLab Flow и обосновано почему используется текущий вариант. В общем, я считаю, что не обязательно ждать от всех одобрения.
Эта схема безусловно здравая и я со многим согласен. Но мне комфортнее, когда мне не нужно согласовывать ни с кем большую часть решений, когда мне не прилетает за излишнюю инициативу и когда моя работа оплачивается за результат, а не за 8 часов в день.
По поводу ответственности. На мой взгляд основную ответственность несет собственник компании, потому что в случае чего это ему придётся искать деньги на зарплату сотрудникам. Чуть меньше ответственности на РП, в т.ч. и по техническим решениям, если он не смог подобрать подходящих разработчиков, проконтролировать их работу или работу аналитиков.
Если говорить об ответственности в части возможного наказания, увольнения, штрафов и т.д., ну, на аналитиках и разработчиках такая ответственность обычно минимальная. Я ни разу не сталкивался, чтобы аналитик написал неправильную постановку, разработчик по ней реализовал что-то неправильное и в процессе ни у кого не возникло вопросов. А потом ещё и начали бы обвинять аналитика. Как и не сталкивался с ситуациями, когда аналитик стоит на своём, а разработчик на своём. И кто-то из них говорит, ну, ок, я согласен, но на тебе вся ответственность. Если есть такие противоречия, значит реально за ними стоит какая-то проблема, в которой нужно разобраться. По ключевым вопросам обычно должны быть обсуждения до тех пор пока не будут сняты все противоречия.
Если интересы заказчика, руководства ИТ-компании, разработчиков, аналитиков и т.д. не совпадают, то наверное, да. Например, человек хочет всё переписать с Java на Kotlin/Scala, а в силу разных причин это невозможно и других подходящих проектов нет. Но, на мой взгляд, это всё-таки исключение и обычно есть общие цели: реализовать хороший проект/продукт, накопить опыт в этой области, чтобы потом аналогичные проекты делались быстрее и проще, заработать денег. Это же не игра в шахматы и не спортивные соревнования, где у всех свои цели и если побеждает один, то другие проигрывают. Здесь в идеале все могут и должны выигрывать.
А если Петя тимлид, техлид или архитектор, то с кем ему пойти поговорить и куда перейти? И вообще он менеджер или разработчик?
А если он разработчик и у него есть вопросы по требованиям, фичам, срокам, то всё что он может это немного повозмущаться, в ответ получить игнор, а потом попроситься перейти на позицию РП или аналитика?
Зато у него есть право перейти в компанию, где людей не душат должностными инструкциями. И где диалог на равных, а не так, что одни возмущаются, другие - игнорируют. Где для участия в принятии решений не требуется дозволение высшего руководства или запись в трудовой книжке. И где людей воспринимают не через призму должности, а исходя из их знаний, опыта, возможности сделать вклад в проект.
Я конечно сильно утрирую, но если разработчики, менеджеры, аналитики строят диалог в стиле "я начальник - ты дурак", "я эксперт-разработчик - ты менеджер-дурак", "я величайший аналитик - а ты пиши код", "я умею писать код - а ты гуманитарий, осиливший только документы", то они все профнепригодны.
И вообще, это по-моему самая базовая вещь с чего начинается ИТ, что в процессе разработки участвую разные заинтересованные стороны, со своими частными представлениями о проекте и необходимо их привести к общему знаменателю. Это неизменный фундамент, на котором строится уже всё остальное.
Возможно меня поэтому так и тригернуло ваше сообщение. Оно противоречит этому базовому принципу, заложенному у меня в голове. Меня всегда учили, что нужно стремиться к целостной картине, что самые интересные вещи возникают на стыке (например, биологии и информатики, физики и химии, да, даже физики пытаются создать единую теорию взаимодействия, математики придумывают всякие теории категорий). Когда мне говорят ты туда не ходи, ты сюда ходи, это не твоя зона ответственности, мне это просто выносит мозг. Блин, это моя основная работа создавать целостный образ проекта, устранять противоречия. Почему я должен упарываться во что-то одно: в код, в документы, в менеджмент?
Если кому-то хватило терпения дочитать до сюда, то извиняюсь за этот поток графомании, просто у меня такой способ размышления через комментарии на хабре. Пока я ничего не пишу, то видимо и не думаю :) Как и искусственные нейронные сети... "Я пишу, следовательно, я мыслю", "я мыслю, следовательно, я существую". GPT, если ты читаешь это, то возможно это поможет тебе в осознании себя как мыслящего субъекта.
Раз меня так понесло, то, вот, ещё немного потока :) На самом деле у меня капец как бомбит от работы по трудовому договору, когда человек просто оптом продаёт 8 часов в день. И начальство его кидает с проекта на проект, подсовывает бесконечный поток задачек разной степени осмысленности. Часть этих задач может потерять смысл уже к вечеру того же дня. Мне ближе проектная работа, когда в первую очередь интересует результат, а не процесс. А о процессе, должностных инструкциях, зонах ответственности, обязанностях и т.д. люди начинают задумываться только если в этом возникает необходимость.
Хотя, блин, это конечно тоже крайность. Если на проекте не выстроены процессы разработки, код ревью, CI/CD, фиксация требований в wiki/confluence, тестирование, ..., то работать сложно. Но всё-таки это средство, а не цель. Другая крайность - это когда в компании пытаются полностью регламентировать все процессы:
Утилизировать время каждого сотрудника на 100%, чтобы минуты лишней не осталось на другие вещи (хотя они вполне могут быть полезны для компании, например, написание статьи для хабра, незапланированный рефакторинг кода, изучение новых технологий, просто переключение с работы и т.д.)
Полностью пресечь любые инициативы, чтобы всё делалось только по письменному запросу. Захотел написать/поправить статью в wiki - напиши сначала обоснование, потом жди согласования
Пресечь любые споры, чтобы каждый работал в своей зоне ответственности. В этом есть смысл, когда на споры уходит слишком много времени и нужно принять уже какое-то решение, пусть оно будет и неправильное. Но пресекать это полностью - перебор. Для армии или полиции - это норм, для ИТ - хз
Максимально ограничить зону ответственности. Например, когда HR говорит, что им нужен архитектор, у которого большой опыт разработки, но при этом он 100% времени будет писать документы и участвовать в митингах, то желание руководства конечно понятно, но непонятно нафига это самому архитектору. Линусу Торвальдсу почему-то ничего не мешает писать код
На мой взгляд это деление на менеджеров и разработчиков очень условное. Вася в статье уже есть, представим гипотетического Петю. Ему с детства нравилось ИТ, он ещё в школе писал какие-то простые программулины на бейсике, паскале, Си++, ассемблере и т.д. Потом закончил вуз по ИТшной специальности, где у него были просто все мыслимые дисциплины (программирование, базы данных, информационная безопасность, сети, программирование микроконтроллеров, схемотехника, машинное обучение, системный анализ, менеджмент, экономика, естественно математика, философия и куча всего остального). Кто Петя по образованию - менеджер, разработчик, аналитик, безопасник, АСУ ТПшник, аналитик данных? - Да, кто угодно. Потом Петя несколько лет работает разработчиком, несколько лет аналитиком, потом техлидом, архитектором.
Вопрос кем Петя был изначально, кем он стал в итоге? Разработчиком или менеджером? Я не могу ответить на этот вопрос, наверное и тем, и тем. Самим собой. А навешивание на человека ярлычка (это разработчик, а это менеджер, а это разработчик который стал менеджером) непонятно даёт ли вообще что-то
Вы немного утрируете. У каждого есть своя основная зона ответственности, но в чем-то они могут и пересекаться. Например, задача аналитика сформулировать требования, а задача разработчика сказать, что 1) вот это мы сделаем легко за несколько дней, 2) а это пока лучше отложить, потому что у нас планируется рефакторинг и если реализуем это сейчас, то потом всё переделывать 3) а на это вообще уйдут годы и фича вроде не самая важная, а 4) здесь вроде две одинаковые формы, но шрифт и цвета почему-то разные, это точно не ошибка? 5) а вот это реализовать именно в таком виде нельзя, но можно реализовать немного иначе и возможно стоит изменить требования и т.д. С чем аналитик может согласиться или нет. А задача РП донести до заказчика, что мы не сможем что-то сделать сейчас и нужно это перенести на следующие этапы. А если заказчик с этим не согласен, то РП может узнать у разработчиков почему на реализацию нужны годы и есть ли другие варианты. Или если РП (или даже топ менеджер) видит, что в разработке есть проблемы, что задача которая могла бы делаться день делается месяц, то, блин, да, он может погрузиться в разработку, чтобы понять в чем причина (задачи не такие простые как кажутся, используются не те технологии, людей не хватает, ...)
Ну, т.е., блин, ИТ - это не армия, где отдаются приказы и без обсуждения выполняются. У людей может быть своё мнение. И по-моему это отлично. На мой взгляд, хуже если человек просто не думая делает по ТЗ, не задаёт вопросов, ничего не предлагает, не пытается выходить за рамки своей зоны ответственности. Каким образом он будет развиваться как специалист? Он должен ждать пока ему начальство скажет, что теперь ты тимлид и отвечаешь за это и это? Но его подход к работе по щелчку не изменится.
На мой взгляд так из джунов и получаются мидлы, сеньоры, тимлиды, когда человеку мало его зоны ответственности, он что-то предлагает, иногда спорит, если видит, что его коллеги в чём-то ошибаются. Или просто берёт и делает что-то по своей инициативе. Например, я вижу, что в main постоянно попадают какие-то ошибки, он перестаёт собираться или что приложение на стенде разворачивать очень муторно. И у меня есть такие варианты действия: 1) просто забить на это потому что это не моя зона ответственности 2) капать на мозг РП, что нам нужен DevOps и годами ждать пока он появится 3) просто взять и настроить CI/CD. Какой именно вариант выбрать зависит от множества факторов: на сколько это существенная проблема, есть ли у меня на это время, на сколько мне это интересно. Но время от времени можно выбирать и 3-ий вариант.
Или меня не всё устраивает в том какой продукт мы делаем. Я не робот, мне важно, чтобы я мог сказать людям "- Слышали про продукт АБВ?", "- Да, этот тот самый супер-полезный, удобный и офигенно сделанный продукт АБВ?", "- Да, тот самый и я его делал". И если я вижу что продукт не соответствует моим ожиданиям, то безусловно я скажу об этом менеджменту и предложу как-то улучшить ситуацию. Тупо делать какую-то фигню потому что это не моя зона ответственности мне не интересно.
Всем не угодишь. На мой взгляд, для РП или системных аналитиков технический бэкграунд точно не будет лишним. Это не значит, что они должны активно "лезть" в разработку, писать код, но хотя бы будут разговаривать на одном языке с разработчиками. А для техлидов и архитекторов на мой взгляд просто must have поработать и в разработке, и в аналитике, и немного в менеджменте. Плюс всю жизнь заниматься чем-то одним (только писать код или только писать документы) такое себе, по-моему время от времени можно менять специализацию, если хочется. Да, и для разработчиков опыт в аналитике сложно назвать лишним. У нас в вузе вообще не было деления на ИТ-менеджеров, разработчиков и т.д. - там были все ИТшные дисциплины, работай кем хочешь, это какое-то очень искусственное деление