вот да. если интересно. только вот интересные задачи встречаются не у всех и не всегда. И кто то делает занудные задачи. и тут получается замкнутый круг - чем дольше ты делаешь типовые задачи, тем лучше и быстрее ты их делаешь. Чем лучше и быстрее ты их делаешь - тем меньше вероятность, что тебя переведут на другие задачи. чем дольше тебя не переводят на другие задачи, тем больше тебя воротит от типовых. И тут уже не то что описанные пункты практиковать начинаешь. а ещё десяток новых придумаешь.. причём если рука на эти задачах хорошо набита- снижения производительности никто особо и не заметит
И самое печальное, что когда таки решаешься свалить - на собеседование рассказать то нечего.. вот работаешь работаешь, кучу лет опыта.. А по итогу? Вот работал там то - на собесе обещали чуть ли не космические корабли к марсу запускать. По итогу несколько лет пилил отчётики и писал-читал десяток таблиц..
А чтобы были интересные задачи - в некоторых местах их тоже уметь выбивать надо. Вот был у меня проект - куча абсолютно тупой работы. Народ выл от неё. Коллега пошёл к начальству, покачал права- его перевели на другой проект. А меня пару месяцев завтраками кормили - так и пришлось, когда стало совсем невмоготу, идти искать хоть более менее адекватные задачи в другую контору
и не говорите.. и всё это мегаважно и супер нужно.. и это там нужно говорить, а то нужно говорить потом.. А по итогу сплошная говорильня и засилье говорунов. а уж если у них к длинному языку и умению говорить много и красиво ещё и не прилагается понимание того, что команда делает...
если руки растут не из того места и способность работать заменена способностью красиво вешать лапшу на уши - при чём тут формат работы? и если руководство ГОД снимало эту лапшу с ушей и продолжало выделять деньги при отсутствие видимого результата - то кто им доктор?
А "я сейчас к тебе подсяду и все покажу/расскажу " имхо зло. А если при этом категорически не любить жиру и ей подобные - это зло абсолютное
(ностальгически) эх, где ты мой проект по отладке станков с ЧПУ непосредственно в металлообрабатывающем цеху.. Просто волшебная тренировка, чтобы в дальнейшей карьере спокойно относиться к посторонним шумам :-)
ни при чём. как и написано в статье- говорить "нет" нужно уметь. Особенно когда долго и упорно накачивают, что сроки проходят, завтра/в понедельник/в конце недели крайний срок, после которого всех разгонят.. и опять таки - не все могут сопротивляться такому прессингу. На одном проекте джун под аккомпонемент стенаний, как всё горит 8 месяцев работал практически без выходных по 15 часов.
У него первая работа, он другого не видел и видимо считал, что так и надо. И это страшно - если вырастет поколение не знающих другого стиля работы и уже среди них заведутся выдающиеся по ИХ меркам энтузиасты..
опять таки - не всегда понятно, что случилось - кошмар или мелочь. например - сделали фичу, её почти без тестирования накатили на прод (не, ну там же мелочь. ну и ты же опытный разработчик, мы тебе доверяем!) Накатили в 6 вечера
(ну да, можно в принципе было накатить и с утречка. чтобы в рабочее время править если что.. ну вот как то руки не дошли. в очередной раз). А в 10 вечера прибегают с криками, что всё кошмар и ничего не работает. подрываешься, а потом выясняется, что на фронте кнопочка не на том месте. причём она там уже месяц и только сейчас заметили. при том, что ты вообще то бек.
А их не поощряют. Официально. И никого не заставляют. Ни официально, никак. На одном проекте у меня был коллега (умный человек!), который в 6 вечера уходил в офлайн и до утра не появлялся. о чём сразу предупредил. и после пары вежливых посылов с его стороны его оставили в покое. без каких либо последствий для него. что не мешало менеджеру прибегать в 5 вечера со словами "я обещала заказчику внести изменения до 9 утра, давайте постараемся" и по полночи дёргать менее мудрых работников. Причём раз за разом оказывалось, что заказчику эти изменения именно к 9 утра совершенно не нужны. да и в принципе он на них не настаивал - так черканул на бумажке мысли вслух и всё.
А поощряем, не поощряем.. ну сейчас же аджайл наше всё. У нас самоорганизующаяся команда. И если в этой команде заводится энтузиаст ( а он обычно заводится), то на доводы, не подкреплённые руководящим указанием, он обычно реагирует слабо.
А учитывая, что этот энтузиаст часто просто горит работой ( насколько много от этого горения пользы - вопрос другой. и часто довольно спорный) - он ещё и рвётся часто и многословно рассказывать, как нужно срочно что то сделать и как нельзя подождать.. не у всех хватает терпения начать выяснять в чём срочность и доносить мысль, что срочности то особой нет.
work-life баланс с началом удалёнки - это боль. то ли мне так "везёт", то ли это стало распространённой практикой, но уже на нескольких проектах обязательно находится кто то, кто в 9 вечера прибегает с воплями, что всё пропало или что ему в голову пришла гениальная идея, которую нужно реализовать вот прямо сейчас. я, пусть и с некоторым трудом, научился не реагировать на это. А очень многие коллеги по молодости или из сильно ответственного отношения к работе реагируют. и бросаются исправлять, разрабатывать, накатывать. Пашут вечерами, ночами.. А потом, когда спрашиваешь -а зачем это всё было? нельзя ли было до утра подождать? всё пожимают плечами и говорят "Ну да, можно было.. ну вот люди подтянулись и сделали! спасибо им большое!" А потом эти люди днём отсыпаются и никакие вопросы решить невозможно.. и только они начнут работать в рабочее время, как опять появляется какой-нибудь энтузиаст, которому что то СРОЧНО нужно сделать в 12 ночи. причём в чём срочность он обычно и сам не знает.
ИМХО - тут уже нужны административные меры руководства для соблюдения этого баланса. кто то не может отказать, когда его дёргают и что то требуют и выгорает напрочь, кто то может, но через некоторое время начинает чувствовать себя белой вороной, а кто то привык, что дёргают по всякой ерунде и при реальном форс мажоре даже не почешется
Не ротировать сотрудников, работающих на одной и той же позиции один-два года
ротация это конечно хорошо.. только обычно это что то из мира розовых единорогов. Если сотрудник работает хорошо - найдётся тысяча и одна причина, почему ему нужно чуть чуть задержаться на текущем проекте. И ещё чуть чуть. И ещё совсем совсем немного. А если сотрудник работает плохо - то в других проектах найдётся столько же причин его не брать
перечитал свои комментарии - выглядит так, как будто я агитирую за несколько работ. На самом деле - совсем нет. Я просто хочу сказать, что при некоторых условиях это может быть не плохим выбором. но далеко не всегда, не для всех и сделав этот выбор нужно всегда понимать, что возможны накладки при совпадение дедлайнов на разных работах, а также необходимо умение хорошо управлять своим временем, чтобы не уйти в режим работы 24/7 (хотя в такой режим некоторые и на одной работе спокойно уходят). И имхо - если хорошо подвешен язык и прокачан скил забалтывания начальника/рекрутёра/заказчика или ещё не дошёл до той суммы, когда на собеседованиях требуют уже чего то странного - то расти на одной работе/поменять её на другую, но тоже одну - оно будет поспокойнее и повыгоднее
Во многих, особенно крупных компаниях, работодателю выгодно держать некоторый лишний резерв специалистов, пусть даже они половину времени простаивают, но все равно платить им за время простоя выгоднее, чем содержать специалистов впритык, рискуя в случае бас-фактора попасть на гораздо большие деньги и проблемы.
Во многих, особенно крупных компаниях, зачастую количество, качество и загруженность работников определяются не производственной необходимостью, а аппаратными играми уважаемых людей в высоких кабинетах. Пока есть возможность выбивать из высшего руководства средства на обновления устаревших систем и переписывать их на новых технологиях, которые позволят (что нибудь. Я в аппаратные игры играть не умею, но в фантазии умеющих не сомневаюсь) - до тех пор будут существовать отделы в которых куча народу занимается ничем. И периодически у них будут случаться авралы. когда неожиданно надо показать хоть что нибудь. Но очень часто там бурная деятельность только имитируется. А если контора крупная и не бедная - то они могут в такие проекты набрать квалифицированных специалистов на вкусную зарплату. И тут у работника выбор - либо всей душой включиться в корпоративную шизу, либо найти подработку для души и немножко денег, либо бесконечно проходить различные курсы и читать умные книги, либо сидеть, тупить и деградировать. Курсы и книги дело безусловно хорошее. Но имхо без практики из головы всё выветривается моментально. Можно свои проекты пилить. но это нужна фантазия на придумать проект и мотивация не бросить его, когда он не приносит никаких материальных выгод. Есть ещё конечно вариант на основной работе либо текущий проект делать красиво, либо попытаться перейти на другой, интересный.. но в больших конторах там сталкивается много интересов и умение протолкаться там - это опять таки не про умение хорошо разрабатывать программы
не факт. Если работадатель бОльшую часть времени нагружает на 3-4 часа в день, то кто то в оставшиеся 4 часа в игрушках или соцсетях сидит, а кто то работает на других проектах и набирается опыта. который, возможно, пригодится в том числе и на первой работе.
работник подписался на то, что он будет выполнять поставленные задачи и согласен тратить на это N часов своей жизни. Если сеньёру ставят задачи уровня джуна и ждут от него скорости выполнения джуна, но при этом платят сеньёрские деньги - кто им доктор? Вы же не будете от таксиста требовать, чтобы он вас вёз со скоростью велосипеда мотивируя это тем, что вы оплачиваете его время? и если работник выполняет работу за время N/2, но все процессы заточены на то, что новые задачи появляются только через N часов - где тут нарушения со стороны работника?
но подход может и ущербный. но в его защиту можно сказать
Насколько я успел заметить - основные деньги в энтерпрайзе. А там местами и временами процессы довольно... своеобразные. И временами бывает недозагруженность. Причём с точки зрения менеджмента при этом бывает кажется, что все в трудах и заботах, аки пчёлы. А убедить их в обратном бывает долго, трудно и по большому счёту особо незачем.
Потолка конечно нет. Теоретически. Но начиная с некоторой суммы для смены работы с повышением, перекрывающим подработки, нужен хорошо прокаченный навык проходить собеседования. что совсем не то же самое, что способность хорошо работать. У каждого сумма своя но иногда проще желаемый полтинник (сотню, полторы ...) повышения получить найдя что то дополнительное и малонапряжное, чем пытаться доказать на собеседованиях. что ты не верблюд. Особенно если первая не особо балует загруженностью.
Но дело вкуса конечно. И умения распределять время. У меня есть знакомый, который умудряется даже на двух одновременных митингах присутствовать
А для кого пишут эти статьи интересно? не, ну просто желание поделиться - оно понятно и никакого отторжения не вызывает. но всё таки интересна предполагаемая целевая аудитория - кто не дошёл до ручки - ему это ещё не интересно. кто уже дошёл - ему уже ничего не интересно. кто пришёл в себя - ему уже не актуально. Напоминает клуб анонимных алкоголиков из фильмов :-)
Хосспади, когда же, наконец, исчезнет эта вера в священный грааль микросервисов
ну исчезнет эта - возникнет какая нибудь следующая. Когда то возникла и пропала мода всё что ни попадя выносить в dll (шарп, когда только появлялся как раз и декларировал одним из плюсов- уход от ада длл и локализацию всего, что нужно приложению в отдельных сборках), потом помнится была мода, что давать приложению хоть какой то доступ к данным это не секьюрно и на каждый чих писали хранимки... А по итогу - всё же упирается в деньги. Как только зарплаты специалистов по базам стали сильно большие - так расцвели всякие ORM и хранимки стали древностью, которые правильные программисты не должны использовать ни за что и никогда. И по итогу - я знаю реально хороших, опытных программистов, которые писали приложения, активно работающие с базой и которые были не способны написать на Sql простейший join.
Правильный, хорошо написанный монолит
Требует более высокой квалификации рядовых разработчиков и гораздо больше времени на погружение. И это дороже для бизнеса. В первом приближение. А микросервис в идеальном мире - ну что там, пять-десять классов и всё. и если они будут написаны кривыми руками стажёра - это не смертельно. Ну это конечно в идеальном мире. А в реальности - кривые руки стажёра, по которым никто не бил потихоньку вырастают в кривые руки архитектора этих самых сервисов.. что ничуть не более страшно, чем тот же архитектор, выросший на привычке лепить костыли сбоку монолита. потому что глубже лезть страшно.
Жёстко привязан к языку. а микросервисы декларируют, что писать их можно на чём угодно. Я, честно говоря, слабо представляю себе систему, где каждый сервис написан на своём языке.. но с точки зрения уменьшения рисков - приятно наверное осознавать, что если зарплаты тех же джавистов улетят в космос - можно нанять... ну не знаю - специалистов на VBA.
Сейчас, как мне кажется, зарплаты девопсов сильно рванули вверх. и не хватает специалистов, способных поддерживать растущий как на дрожжах зоопарк микросервисов. Есть подозрение, что скоро в моду войдёт что нибудь, что будет декларироваться как избавление команд от ада микросервисов и какую нибудь очередную унификацию. и это опять будут продвигать, как панацею от всех проблем и опять никто не будет читать книги с описанием технологии дальше предисловия. А ведь и сейчас в большинстве книг по микросервисам описано, когда имеет смысл их применять, а когда проще будет делать монолит. Обычно уже в первой главе.
А скрам.. ну тоже мода. и тоже вероятно из финансовых соображений. Нормальных аналитиков днём с огнём не найти. Программистов на выяснение задач и общение с заказчиком отправлять не модно. А поставить маааленькую задачку то, что в большинстве команд зовётся аналитиком ещё в состояние. А вот разобраться в бизнесе и написать нормальное большое ТЗ - уже далеко не всегда. и тут опять микросервисы -наше всё. если очередная маленькая задачка будет противоречить написанному за несколько предыдущих лет - маленький сервис переписать всё так легче. ну, если он действительно микро. а не разросся так, что иной монолит позавидует
во всём есть свои плюсы и минусы.. уверенность, что микросервисы нивелируют ошибки зачастую приводят к тому, что никто не тратит время на проектирование. И пишет так, как пишется здесь и сейчас. И через пару лет имеет кучу сервисов с непонятной архитектурой и неизвестными никому толком связями. И полным отсутствием какого либо общего стиля и подхода
вот да. если интересно. только вот интересные задачи встречаются не у всех и не всегда. И кто то делает занудные задачи. и тут получается замкнутый круг - чем дольше ты делаешь типовые задачи, тем лучше и быстрее ты их делаешь. Чем лучше и быстрее ты их делаешь - тем меньше вероятность, что тебя переведут на другие задачи. чем дольше тебя не переводят на другие задачи, тем больше тебя воротит от типовых. И тут уже не то что описанные пункты практиковать начинаешь. а ещё десяток новых придумаешь.. причём если рука на эти задачах хорошо набита- снижения производительности никто особо и не заметит
И самое печальное, что когда таки решаешься свалить - на собеседование рассказать то нечего.. вот работаешь работаешь, кучу лет опыта.. А по итогу? Вот работал там то - на собесе обещали чуть ли не космические корабли к марсу запускать. По итогу несколько лет пилил отчётики и писал-читал десяток таблиц..
А чтобы были интересные задачи - в некоторых местах их тоже уметь выбивать надо. Вот был у меня проект - куча абсолютно тупой работы. Народ выл от неё. Коллега пошёл к начальству, покачал права- его перевели на другой проект. А меня пару месяцев завтраками кормили - так и пришлось, когда стало совсем невмоготу, идти искать хоть более менее адекватные задачи в другую контору
какой жырный троллюга
и не говорите.. и всё это мегаважно и супер нужно.. и это там нужно говорить, а то нужно говорить потом.. А по итогу сплошная говорильня и засилье говорунов. а уж если у них к длинному языку и умению говорить много и красиво ещё и не прилагается понимание того, что команда делает...
если руки растут не из того места и способность работать заменена способностью красиво вешать лапшу на уши - при чём тут формат работы? и если руководство ГОД снимало эту лапшу с ушей и продолжало выделять деньги при отсутствие видимого результата - то кто им доктор?
А "я сейчас к тебе подсяду и все покажу/расскажу " имхо зло. А если при этом категорически не любить жиру и ей подобные - это зло абсолютное
(ностальгически) эх, где ты мой проект по отладке станков с ЧПУ непосредственно в металлообрабатывающем цеху.. Просто волшебная тренировка, чтобы в дальнейшей карьере спокойно относиться к посторонним шумам :-)
да. и это печально.
насчёт кнопочки я конечно утрирую.. но срочность и важность проблемы и её отношение к конкретному разработчику часто бывает примерно такого уровня
ни при чём. как и написано в статье- говорить "нет" нужно уметь. Особенно когда долго и упорно накачивают, что сроки проходят, завтра/в понедельник/в конце недели крайний срок, после которого всех разгонят.. и опять таки - не все могут сопротивляться такому прессингу. На одном проекте джун под аккомпонемент стенаний, как всё горит 8 месяцев работал практически без выходных по 15 часов.
У него первая работа, он другого не видел и видимо считал, что так и надо. И это страшно - если вырастет поколение не знающих другого стиля работы и уже среди них заведутся выдающиеся по ИХ меркам энтузиасты..
опять таки - не всегда понятно, что случилось - кошмар или мелочь. например - сделали фичу, её почти без тестирования накатили на прод (не, ну там же мелочь. ну и ты же опытный разработчик, мы тебе доверяем!) Накатили в 6 вечера
(ну да, можно в принципе было накатить и с утречка. чтобы в рабочее время править если что.. ну вот как то руки не дошли. в очередной раз). А в 10 вечера прибегают с криками, что всё кошмар и ничего не работает. подрываешься, а потом выясняется, что на фронте кнопочка не на том месте. причём она там уже месяц и только сейчас заметили. при том, что ты вообще то бек.
А их не поощряют. Официально. И никого не заставляют. Ни официально, никак. На одном проекте у меня был коллега (умный человек!), который в 6 вечера уходил в офлайн и до утра не появлялся. о чём сразу предупредил. и после пары вежливых посылов с его стороны его оставили в покое. без каких либо последствий для него. что не мешало менеджеру прибегать в 5 вечера со словами "я обещала заказчику внести изменения до 9 утра, давайте постараемся" и по полночи дёргать менее мудрых работников. Причём раз за разом оказывалось, что заказчику эти изменения именно к 9 утра совершенно не нужны. да и в принципе он на них не настаивал - так черканул на бумажке мысли вслух и всё.
А поощряем, не поощряем.. ну сейчас же аджайл наше всё. У нас самоорганизующаяся команда. И если в этой команде заводится энтузиаст ( а он обычно заводится), то на доводы, не подкреплённые руководящим указанием, он обычно реагирует слабо.
А учитывая, что этот энтузиаст часто просто горит работой ( насколько много от этого горения пользы - вопрос другой. и часто довольно спорный) - он ещё и рвётся часто и многословно рассказывать, как нужно срочно что то сделать и как нельзя подождать.. не у всех хватает терпения начать выяснять в чём срочность и доносить мысль, что срочности то особой нет.
work-life баланс с началом удалёнки - это боль. то ли мне так "везёт", то ли это стало распространённой практикой, но уже на нескольких проектах обязательно находится кто то, кто в 9 вечера прибегает с воплями, что всё пропало или что ему в голову пришла гениальная идея, которую нужно реализовать вот прямо сейчас. я, пусть и с некоторым трудом, научился не реагировать на это. А очень многие коллеги по молодости или из сильно ответственного отношения к работе реагируют. и бросаются исправлять, разрабатывать, накатывать. Пашут вечерами, ночами.. А потом, когда спрашиваешь -а зачем это всё было? нельзя ли было до утра подождать? всё пожимают плечами и говорят "Ну да, можно было.. ну вот люди подтянулись и сделали! спасибо им большое!" А потом эти люди днём отсыпаются и никакие вопросы решить невозможно.. и только они начнут работать в рабочее время, как опять появляется какой-нибудь энтузиаст, которому что то СРОЧНО нужно сделать в 12 ночи. причём в чём срочность он обычно и сам не знает.
ИМХО - тут уже нужны административные меры руководства для соблюдения этого баланса. кто то не может отказать, когда его дёргают и что то требуют и выгорает напрочь, кто то может, но через некоторое время начинает чувствовать себя белой вороной, а кто то привык, что дёргают по всякой ерунде и при реальном форс мажоре даже не почешется
ротация это конечно хорошо.. только обычно это что то из мира розовых единорогов. Если сотрудник работает хорошо - найдётся тысяча и одна причина, почему ему нужно чуть чуть задержаться на текущем проекте. И ещё чуть чуть. И ещё совсем совсем немного. А если сотрудник работает плохо - то в других проектах найдётся столько же причин его не брать
перечитал свои комментарии - выглядит так, как будто я агитирую за несколько работ. На самом деле - совсем нет. Я просто хочу сказать, что при некоторых условиях это может быть не плохим выбором. но далеко не всегда, не для всех и сделав этот выбор нужно всегда понимать, что возможны накладки при совпадение дедлайнов на разных работах, а также необходимо умение хорошо управлять своим временем, чтобы не уйти в режим работы 24/7 (хотя в такой режим некоторые и на одной работе спокойно уходят). И имхо - если хорошо подвешен язык и прокачан скил забалтывания начальника/рекрутёра/заказчика или ещё не дошёл до той суммы, когда на собеседованиях требуют уже чего то странного - то расти на одной работе/поменять её на другую, но тоже одну - оно будет поспокойнее и повыгоднее
Во многих, особенно крупных компаниях, зачастую количество, качество и загруженность работников определяются не производственной необходимостью, а аппаратными играми уважаемых людей в высоких кабинетах. Пока есть возможность выбивать из высшего руководства средства на обновления устаревших систем и переписывать их на новых технологиях, которые позволят (что нибудь. Я в аппаратные игры играть не умею, но в фантазии умеющих не сомневаюсь) - до тех пор будут существовать отделы в которых куча народу занимается ничем. И периодически у них будут случаться авралы. когда неожиданно надо показать хоть что нибудь. Но очень часто там бурная деятельность только имитируется. А если контора крупная и не бедная - то они могут в такие проекты набрать квалифицированных специалистов на вкусную зарплату. И тут у работника выбор - либо всей душой включиться в корпоративную шизу, либо найти подработку для души и немножко денег, либо бесконечно проходить различные курсы и читать умные книги, либо сидеть, тупить и деградировать. Курсы и книги дело безусловно хорошее. Но имхо без практики из головы всё выветривается моментально. Можно свои проекты пилить. но это нужна фантазия на придумать проект и мотивация не бросить его, когда он не приносит никаких материальных выгод. Есть ещё конечно вариант на основной работе либо текущий проект делать красиво, либо попытаться перейти на другой, интересный.. но в больших конторах там сталкивается много интересов и умение протолкаться там - это опять таки не про умение хорошо разрабатывать программы
не факт. Если работадатель бОльшую часть времени нагружает на 3-4 часа в день, то кто то в оставшиеся 4 часа в игрушках или соцсетях сидит, а кто то работает на других проектах и набирается опыта. который, возможно, пригодится в том числе и на первой работе.
работник подписался на то, что он будет выполнять поставленные задачи и согласен тратить на это N часов своей жизни. Если сеньёру ставят задачи уровня джуна и ждут от него скорости выполнения джуна, но при этом платят сеньёрские деньги - кто им доктор? Вы же не будете от таксиста требовать, чтобы он вас вёз со скоростью велосипеда мотивируя это тем, что вы оплачиваете его время? и если работник выполняет работу за время N/2, но все процессы заточены на то, что новые задачи появляются только через N часов - где тут нарушения со стороны работника?
но подход может и ущербный. но в его защиту можно сказать
Насколько я успел заметить - основные деньги в энтерпрайзе. А там местами и временами процессы довольно... своеобразные. И временами бывает недозагруженность. Причём с точки зрения менеджмента при этом бывает кажется, что все в трудах и заботах, аки пчёлы. А убедить их в обратном бывает долго, трудно и по большому счёту особо незачем.
Потолка конечно нет. Теоретически. Но начиная с некоторой суммы для смены работы с повышением, перекрывающим подработки, нужен хорошо прокаченный навык проходить собеседования. что совсем не то же самое, что способность хорошо работать. У каждого сумма своя но иногда проще желаемый полтинник (сотню, полторы ...) повышения получить найдя что то дополнительное и малонапряжное, чем пытаться доказать на собеседованиях. что ты не верблюд. Особенно если первая не особо балует загруженностью.
Но дело вкуса конечно. И умения распределять время. У меня есть знакомый, который умудряется даже на двух одновременных митингах присутствовать
когда их 4 - это не совмещение. это отчаянная попытка выжить. Мне на трёх то уже ни до чего было.
А для кого пишут эти статьи интересно? не, ну просто желание поделиться - оно понятно и никакого отторжения не вызывает. но всё таки интересна предполагаемая целевая аудитория - кто не дошёл до ручки - ему это ещё не интересно. кто уже дошёл - ему уже ничего не интересно. кто пришёл в себя - ему уже не актуально. Напоминает клуб анонимных алкоголиков из фильмов :-)
ну исчезнет эта - возникнет какая нибудь следующая. Когда то возникла и пропала мода всё что ни попадя выносить в dll (шарп, когда только появлялся как раз и декларировал одним из плюсов- уход от ада длл и локализацию всего, что нужно приложению в отдельных сборках), потом помнится была мода, что давать приложению хоть какой то доступ к данным это не секьюрно и на каждый чих писали хранимки... А по итогу - всё же упирается в деньги. Как только зарплаты специалистов по базам стали сильно большие - так расцвели всякие ORM и хранимки стали древностью, которые правильные программисты не должны использовать ни за что и никогда. И по итогу - я знаю реально хороших, опытных программистов, которые писали приложения, активно работающие с базой и которые были не способны написать на Sql простейший join.
Правильный, хорошо написанный монолит
Требует более высокой квалификации рядовых разработчиков и гораздо больше времени на погружение. И это дороже для бизнеса. В первом приближение. А микросервис в идеальном мире - ну что там, пять-десять классов и всё. и если они будут написаны кривыми руками стажёра - это не смертельно. Ну это конечно в идеальном мире. А в реальности - кривые руки стажёра, по которым никто не бил потихоньку вырастают в кривые руки архитектора этих самых сервисов.. что ничуть не более страшно, чем тот же архитектор, выросший на привычке лепить костыли сбоку монолита. потому что глубже лезть страшно.
Жёстко привязан к языку. а микросервисы декларируют, что писать их можно на чём угодно. Я, честно говоря, слабо представляю себе систему, где каждый сервис написан на своём языке.. но с точки зрения уменьшения рисков - приятно наверное осознавать, что если зарплаты тех же джавистов улетят в космос - можно нанять... ну не знаю - специалистов на VBA.
Сейчас, как мне кажется, зарплаты девопсов сильно рванули вверх. и не хватает специалистов, способных поддерживать растущий как на дрожжах зоопарк микросервисов. Есть подозрение, что скоро в моду войдёт что нибудь, что будет декларироваться как избавление команд от ада микросервисов и какую нибудь очередную унификацию. и это опять будут продвигать, как панацею от всех проблем и опять никто не будет читать книги с описанием технологии дальше предисловия. А ведь и сейчас в большинстве книг по микросервисам описано, когда имеет смысл их применять, а когда проще будет делать монолит. Обычно уже в первой главе.
А скрам.. ну тоже мода. и тоже вероятно из финансовых соображений. Нормальных аналитиков днём с огнём не найти. Программистов на выяснение задач и общение с заказчиком отправлять не модно. А поставить маааленькую задачку то, что в большинстве команд зовётся аналитиком ещё в состояние. А вот разобраться в бизнесе и написать нормальное большое ТЗ - уже далеко не всегда. и тут опять микросервисы -наше всё. если очередная маленькая задачка будет противоречить написанному за несколько предыдущих лет - маленький сервис переписать всё так легче. ну, если он действительно микро. а не разросся так, что иной монолит позавидует
во всём есть свои плюсы и минусы.. уверенность, что микросервисы нивелируют ошибки зачастую приводят к тому, что никто не тратит время на проектирование. И пишет так, как пишется здесь и сейчас. И через пару лет имеет кучу сервисов с непонятной архитектурой и неизвестными никому толком связями. И полным отсутствием какого либо общего стиля и подхода