Знаете, в те времена, когда начал программировать я, "плохим" первым языком считался бейсик, и люди у которых первым языком был паскаль, си или ассемблер очень сочувствовали тем, кто начинал с бейсика… считалось, что это будет мешает им стать хорошими программистами. Доля правды в этом, конечно, была, но по моим наблюдениям те, кто начинал с бейсика, просто разделились на две группы — одна с незначительными сложностями осилила си/паскаль и стала профессионально программировать, а вторая переключилась на разные варианты простых/специализированных языков — от уже непомню чего-то там для работы с БД времён DOS (Clipper?) до макросов в офисе и позднее 1C.
Мне лично учить PHP в своё время помешала сильная неконсистентность языка — как только увидел в начале изучения кучи стандартных функций с похожими названиями и делающие примерно одно и то же, но при этом принимающие примерно одни и те же параметры в совершенно разном порядке — так сразу с изучением и закончил. Чуть позже вышла та известная статья про "фрактал плохого дизайна", которая полностью описывала моё собственное впечатление, чем подтвердила что это просто "не мой" язык.
Я это к тому, что, да, плохих инструментов (почти) не бывает, и практически любому найдётся своё применение. И да, PHP за последние годы сильно развивался. И сильных разработчиков на PHP хватает. Но люди все разные, вкусы у них разные, и языки программирования тоже каждому подходят разные. И вот тем, для кого PHP попал в категорию "мой язык", осваивать другие современные языки действительно может быть сложнее. С другой стороны, PHP вряд ли грозит участь бейсика, так что им ничего не мешает и дальше писать на языке, который им нравится, и вполне эффективно решать проблемы бизнеса.
Можно ли считать "плохим программистом" того, кто вполне успешно решает проблемы бизнеса, но с точки зрения кого-то другого не знает чего-то такого, что "должны знать все хорошие программисты"? Лично я бы об этом вообще не парился, каждому своё. Для кого-то и я, со всем своим опытом, статьями и кучей опенсорсных проектов, выгляжу недостаточно образованным и не очень-то квалифицированным. Это — просто чужое мнение, не стоит уделять ему слишком много внимания. Лучше просто заниматься тем, чем нравится и писать на том языке, который нравится.
Кружок создавался на базе местного «Дворца пионеров» (МБОУ)
1) 2 группы — условно, «старшая» и «младшая». Печатать во время занятий дети успевать не будут — слишком длительный процесс, обычно печать запускается после занятий.
2) Примерно с 5 класса. Если ребенок «горит», можно и раньше.
3) 3 года. Первоначальный стимул — печатаем только то, что сами смоделировали, дальше — участие соревнованиях и их оргнанизация.
4) Используем 2 «Picaso» — главный критерий — надежность, за 3 с лишним года дети так и не смогли их толком поломать, хотя принтеры в открытом доступе.
Да та же ситуация, что и с акциями — скорее всего причина в том, что на рынке много «свободных» денег из-за политики поддержки в США ну и ситуации в целом повлиявшей на перераспределение средств в пользу возможности внезапно вкладывать в биржу.
Многие свежие инвесторы, это молодежь 20-30 лет. У меня несколько знакомых вот так стали одномоментно «инвесторами», после того как их сократили с низкооплачиваемых работы. Вот один знакомый работал на в гостиничном бизнесе, получал там тысячи 3000, после налогов, из них $1000 тратил на квартиру, $300-400 на еду. Но т.к. он не женатый, денег даже с этой суммы у него оставалось достаточно, чтобы за год выплатить кредит за rav-4.
А теперь потом пришло сокращение. Человеку внезапно сначала прилетел чек от государства на $1200 (ну это всем), а с начала апреля ему стали «капать» по $1000 в месяц (с которых он налоги не платил, поэтому получалось по $4k+ ). Местные магазины начали поддерживать тех кого сократили и выдавать бесплатные набор (причем магазины около премиум уровня). Чувак 3 месяца продукты не покупал от слова совсем. Ну и вот представьте — у него образовалось около $3000 халявных денег в месяц! Что он с ними сделал? Пошел на биржу. Купил какие-то акции, на фоне роста основных компаний неплохо сделал. Ему понравилось — он вложил еще $10k из своих сбережений. Потом продал rav4, все деньги опять на биржу, себе купил 10 летнюю короллу за 4000 кэшем.
То есть, вчерашний студент, внезапно влил на биржу за полгода около $45'000. И это пример из только из нашего штата, где пособия одни из самых маленьких. И это из того, что не на поверхности.
Удаленная работа также дала свои результаты — люди переезжают даже временно из дорогих штатов и получают экономию в десятки тысяч долларов. Это за счет сокращения расходов на жилье. Расходы на разные развлечения (зарубежные поездки, поездки в разные развлекательные места, да даже кинотеатры и рестораны), которые долгое время были не доступны это так же свободные деньги. Семьи с детьми получили за это время экономию (в обмен на нервы конечно), за счет того, что многие сады были закрыты (к примеру, мы так сэкономили около $7k, пока осенью сады не открылись)
Да что там с переездом — у меня местный знакомый устроился в сентябре в FB в NYc. При этому ему не нужно переезжать по крайне мере до конца лета 2021го. Зарплату он выторговал вполне хорошую даже для NYc, но там у него основную часть съедал бы рент в хорошему районе. Но, по сравнению с тем, что он получал тут — + 70% к зарплате! Он и на прошлую свою зарплату тут хорошо жил, а теперь посчитал, что сможет до релокейшена отложить как минимум $80k только с основной зарплаты (это без бонусов и акций).
Тут еще планируют по $600-$2000 в течении месяца где-то. Так что причины роста как биткоина, так и акций вполне очевидны.
Вопрос что будет, когда весь этот стимул себя исчерпает (это будет где-то следующим летом). Ну или когда все разом решать зафиксировать прибыль и вложиться в то же жилье (рынок жилья во многих штатах на пике роста — а нас риелторы работают без выходных говорят ;-) ). Вот тот мой знакомый из начала комментария, уже внезапно оказался с сумой, достаточной для первоначального взноса на дом в хорошем районе. С 10 летней ипотекой, выплаты были бы не намного больше, чем его предыдущий рент и к годам 35 он уже будет обладателем своего собственного дома.
Ryzen 5 1600
Мать MSI B450-A Pro Max
Видеокарта Radeon RX 570 RS 8GB XXX Edition
Оператива на 16 DDR4 (3000MHz)
Ну и остальное не сильно погоду делает.
PS Собирал в 2019, вышло на 15к грн (чуть больше 500$ на то время)
PSS Сейчас чекнул видюху на том же сайте, в х2 как минимум выросла.
Да. Могу. Очень тяжелая. Я писал, что потребовался геймерский комп (кроме видеокарты), чтобы она хоть как то начала ворочаться. А делов то, на полтыщи номенклатуры плюс ЕГАИС и база данных за 3 года.
Исходя из первого пункта — очень подвержена такому понятию — как битый кэш. Знаете об этом?
Очень сложная в настройке и в работе. Я уже писал о том, что писал инструкцию для продавцов на 4 листа. Это только для того, чтобы они смогли инвентаризацию сделать.
Чрезмерно усложнена система обмена данными.
Вообще чрезмерно утяжелена и усложнена. Зачем мне боинг, если я хочу просто каждое утро приезжать на работу и уезжать с работы. Достаточно матиза.
Очень глючная. Например шикарные сканеры Datalogic напрочь отказались работать с ней. Точнее 1С не видела эти сканера. Путем долгих (крайне сложная конфа) копаний в отладчике удалось найти и исправить ошибку. Несмотря на мои багрепорты, спустя 4 года ошибка все еще присутствует и мне приходилось после каждого обновления залезать в конфу, снимать с поддержки и править код. 0 на 1. )
Мы пишем приложение на react-native уже более 1.5 года.
Оно весьма крупное (eComm + eCare) и всё у нас, в общем-то, хорошо. В том числе и с дебагом. Особенно приятно с hot-reload в версии >0.61 и тайм-тревеллом.
Нерешаемых проблем не обнаружили, композиция компонент в реакт очень хорошо работает.
Довольно легко подключаются сторонние либы. Мы подключили проприетарную нативную либу по распознаванию лиц и документов с потока видео из камеры и это не заняло у нас много времени. Работает хорошо и на андроид и на айос.
Из проблем, столкнулись лишь с долгим временем запуска андроид приложений (на айос вполне нормально), т.к. для этого требуется запускать движок JS. Пробовали различные ухищрения, но они давали не очень существенный прирост. Сейчас смотрим в сторону Hermes, по заверениям, он может дать прирост х2
И да, у react-native есть потрясающая фича — обновление приложения «на лету», даже не надо обновлять само приложение в магазинах (play market, ios store).
Т.к. приложение запускает index.bundle.js, то его можно подгрузить с интернета во время запуска и пофиксить багу, без обновления основного приложения.
То есть каждую перерисовку LoggingButton внутренний button будет получать НОВЫЙ экземпляр функции и потому Реакт будет считать, что его необходимо обновить, хотя можно было бы использовать закешированный (старый) вариант, если бы экземпляр функции с контекстом был создан и сохранен изначально.
Следует понимать что это актуально только если реализовывается shouldComponentUpdate со сравнением функций переданных через props. Стандартная реализация shouldComponentUpdate просто возвращает true, поэтому компоненту глубоко плевать на то, новосозданная это функция или закешированная.
П.С. вот хорошая статья на тему производительности реакта http://blog.csssr.ru/2016/12/07/react-perfomance/
За 5000$ на банковском счету в Парагвае можете получить вид на жительство(седула), считается, что если вы зарабатываете деньги за границей, как фрилансер, то и налоги платите там, поэтому налог в Парагвае не платите, было по крайней мере так. Это «страна О'Генри», поле непаханное во всем.
Хорошая заработная плата, и не только она, а еще нужны нормальные условия труда, и это может привлечь специалистов.
Много денег, конечно же, не решат проблему, ну вот дать шанс, что изменения хоть будут, они точно могут.
Но, да, это все не про нас, у нас немного другие цели
Я просто оставлю это здесь www.turnkeylinux.org/. 100+ готовых виртуалок debian (squeeze/wheezy) под VirtualBox с преднастроенным Web Shell. Проще некуда.
Я попробую ответить. Для меня лично, это тоже больное место — эта терминология. В умных книжках, все эти моменты ненавязчиво опускаются (т.к. видимо являются чем-то сверхэлементарным для авторов, не требующим пояснений). Что для нас — перфекционистов — является большим испытанием. Я для себя решил разграничить эти вещи следующим образом:
Персистентность — свойство объекта/структуры позволяющее поддерживать множество его версий (это требование ФП мира). Тогда, персистентная структура — это коллекция, которая позволяет выполнять тот-же набор операций и для своей предыдущей версии. Такие структуры встречаются и в императивных средах, и могут быть построены на изменяемом внутреннем состоянии (с сайд-эффектами).
Неизменяемость — свойство объекта/структуры запрещяющее его любые изменения. Понятно, что неизменяемая структура после модификации представляет собой копию предыдущей версии + конкретные изменения (например новый элемент). При этом, неизменяемые объекты всегда персистентны (т.е. версию которую мы когда-то создали мы не можем изменить/удалить). Такие структуры тоже есть в императивном мире, например java.lang.String (моя любимая коллекция). Неизменяемость — это ограничение функционального мира (т.е. отсутствие деструктивных апдейтов). Может ли неизменяемая структура быть построена на изменяемом внутреннем состоянии? Я думаю да. Есть такое понятие как локализация мутации. Отличный пример такой мутации Паша Павлов рассказывает в этом видео на примере очереди банкиров. Т.е. формально коллекция неизменяемая (по набору элементов), но во внтуренней структуре есть некоторые места, которые подвержены мутациям, т.е. нельзя сказать, что такие структуры всегда без сайд-эффектов.
ЧФСД — это класс структур без сайд-эффектов. Баста.
Вы исходите из ложного предположения, что продуманы хорошо как интерфейсы, так и концепция взаимодействия этих микросервисов. Но если уж понадобилось их все переписать — можете быть на 95% уверены, что и в интерфейсах, и в общей концепции их взаимодействия есть серьёзные проблемы, и переписывать вы будете шило на мыло.
Кроме плохого кода самих микросервисов могут ещё быть:
плохая система аутентификации
плохой протокол взаимодействия микросервисов
плохая система оркестрации микросервисов
некорректно выстроенная модель сущностей в БД и API
да банально совершенно непродуманная система логирования
И этот список можно продолжать очень долго, и ни один пункт вы не сможете исправить, если будете переписывать только часть кусочков. В лучшем случае придётся переписать все их по-очереди, и долго жить в переходной схеме.
Отличным примером такого архитектурного изъяна на уровне протокола может служить wire протокол MongoDB: абсолютно ущербный механизм получения кода ошибок привёл к тому, что, фактически, используется вызов команды для записи/апдейта/удаления вместо соответствующей операции, которая нативно есть в протоколе:
Starting with MongoDB 2.6 and maxWireVersion 3, MongoDB drivers use the database commands insert, update, and delete instead of OP_INSERT, OP_UPDATE, and OP_DELETE for acknowledged writes. Most drivers continue to use opcodes for unacknowledged writes.
Так же стоит отметить, что и в монолитных системах точно так же существует понятие интерфейсов и модулей, которые через эти интерфейсы общаются друг с другом. Конечно, это не позволяет взять и переписать какой-то кусок на другом языке, или в другой парадигме программирования (скажем, асинхронный питон вместо синхронного), но не стоит ставить знак равенства между монолитом и неструктурированным спагетти-кодом. Я более того скажу, нормально спроектированный монолит будет проще поддерживать, чем плохо спроектированную груду микросервисов. А уж сколько геморроя вы начнёте огребать, если начнёте задумываться о микросервисной системе, которая не будет сыпать ошибками на каждый чих в сети, и при этом гарантировать приемлемое время ответа… LIFO очереди, exponential backoff, circuit breaker, всякие хитрые политики service discovery, которые позволяют работать системе в сдеградированном режиме — да там целый гигантский ворох проблем, про который никто особо и не думает, когда рассказывают, как"микросервисы всех спасут".
Знаете, в те времена, когда начал программировать я, "плохим" первым языком считался бейсик, и люди у которых первым языком был паскаль, си или ассемблер очень сочувствовали тем, кто начинал с бейсика… считалось, что это будет мешает им стать хорошими программистами. Доля правды в этом, конечно, была, но по моим наблюдениям те, кто начинал с бейсика, просто разделились на две группы — одна с незначительными сложностями осилила си/паскаль и стала профессионально программировать, а вторая переключилась на разные варианты простых/специализированных языков — от уже непомню чего-то там для работы с БД времён DOS (Clipper?) до макросов в офисе и позднее 1C.
Мне лично учить PHP в своё время помешала сильная неконсистентность языка — как только увидел в начале изучения кучи стандартных функций с похожими названиями и делающие примерно одно и то же, но при этом принимающие примерно одни и те же параметры в совершенно разном порядке — так сразу с изучением и закончил. Чуть позже вышла та известная статья про "фрактал плохого дизайна", которая полностью описывала моё собственное впечатление, чем подтвердила что это просто "не мой" язык.
Я это к тому, что, да, плохих инструментов (почти) не бывает, и практически любому найдётся своё применение. И да, PHP за последние годы сильно развивался. И сильных разработчиков на PHP хватает. Но люди все разные, вкусы у них разные, и языки программирования тоже каждому подходят разные. И вот тем, для кого PHP попал в категорию "мой язык", осваивать другие современные языки действительно может быть сложнее. С другой стороны, PHP вряд ли грозит участь бейсика, так что им ничего не мешает и дальше писать на языке, который им нравится, и вполне эффективно решать проблемы бизнеса.
Можно ли считать "плохим программистом" того, кто вполне успешно решает проблемы бизнеса, но с точки зрения кого-то другого не знает чего-то такого, что "должны знать все хорошие программисты"? Лично я бы об этом вообще не парился, каждому своё. Для кого-то и я, со всем своим опытом, статьями и кучей опенсорсных проектов, выгляжу недостаточно образованным и не очень-то квалифицированным. Это — просто чужое мнение, не стоит уделять ему слишком много внимания. Лучше просто заниматься тем, чем нравится и писать на том языке, который нравится.
1) 2 группы — условно, «старшая» и «младшая». Печатать во время занятий дети успевать не будут — слишком длительный процесс, обычно печать запускается после занятий.
2) Примерно с 5 класса. Если ребенок «горит», можно и раньше.
3) 3 года. Первоначальный стимул — печатаем только то, что сами смоделировали, дальше — участие соревнованиях и их оргнанизация.
4) Используем 2 «Picaso» — главный критерий — надежность, за 3 с лишним года дети так и не смогли их толком поломать, хотя принтеры в открытом доступе.
Многие свежие инвесторы, это молодежь 20-30 лет. У меня несколько знакомых вот так стали одномоментно «инвесторами», после того как их сократили с низкооплачиваемых работы. Вот один знакомый работал на в гостиничном бизнесе, получал там тысячи 3000, после налогов, из них $1000 тратил на квартиру, $300-400 на еду. Но т.к. он не женатый, денег даже с этой суммы у него оставалось достаточно, чтобы за год выплатить кредит за rav-4.
А теперь потом пришло сокращение. Человеку внезапно сначала прилетел чек от государства на $1200 (ну это всем), а с начала апреля ему стали «капать» по $1000 в месяц (с которых он налоги не платил, поэтому получалось по $4k+ ). Местные магазины начали поддерживать тех кого сократили и выдавать бесплатные набор (причем магазины около премиум уровня). Чувак 3 месяца продукты не покупал от слова совсем. Ну и вот представьте — у него образовалось около $3000 халявных денег в месяц! Что он с ними сделал? Пошел на биржу. Купил какие-то акции, на фоне роста основных компаний неплохо сделал. Ему понравилось — он вложил еще $10k из своих сбережений. Потом продал rav4, все деньги опять на биржу, себе купил 10 летнюю короллу за 4000 кэшем.
То есть, вчерашний студент, внезапно влил на биржу за полгода около $45'000. И это пример из только из нашего штата, где пособия одни из самых маленьких. И это из того, что не на поверхности.
Удаленная работа также дала свои результаты — люди переезжают даже временно из дорогих штатов и получают экономию в десятки тысяч долларов. Это за счет сокращения расходов на жилье. Расходы на разные развлечения (зарубежные поездки, поездки в разные развлекательные места, да даже кинотеатры и рестораны), которые долгое время были не доступны это так же свободные деньги. Семьи с детьми получили за это время экономию (в обмен на нервы конечно), за счет того, что многие сады были закрыты (к примеру, мы так сэкономили около $7k, пока осенью сады не открылись)
Да что там с переездом — у меня местный знакомый устроился в сентябре в FB в NYc. При этому ему не нужно переезжать по крайне мере до конца лета 2021го. Зарплату он выторговал вполне хорошую даже для NYc, но там у него основную часть съедал бы рент в хорошему районе. Но, по сравнению с тем, что он получал тут — + 70% к зарплате! Он и на прошлую свою зарплату тут хорошо жил, а теперь посчитал, что сможет до релокейшена отложить как минимум $80k только с основной зарплаты (это без бонусов и акций).
Тут еще планируют по $600-$2000 в течении месяца где-то. Так что причины роста как биткоина, так и акций вполне очевидны.
Вопрос что будет, когда весь этот стимул себя исчерпает (это будет где-то следующим летом). Ну или когда все разом решать зафиксировать прибыль и вложиться в то же жилье (рынок жилья во многих штатах на пике роста — а нас риелторы работают без выходных говорят ;-) ). Вот тот мой знакомый из начала комментария, уже внезапно оказался с сумой, достаточной для первоначального взноса на дом в хорошем районе. С 10 летней ипотекой, выплаты были бы не намного больше, чем его предыдущий рент и к годам 35 он уже будет обладателем своего собственного дома.
Мать MSI B450-A Pro Max
Видеокарта Radeon RX 570 RS 8GB XXX Edition
Оператива на 16 DDR4 (3000MHz)
Ну и остальное не сильно погоду делает.
PS Собирал в 2019, вышло на 15к грн (чуть больше 500$ на то время)
PSS Сейчас чекнул видюху на том же сайте, в х2 как минимум выросла.
Исходя из первого пункта — очень подвержена такому понятию — как битый кэш. Знаете об этом?
Очень сложная в настройке и в работе. Я уже писал о том, что писал инструкцию для продавцов на 4 листа. Это только для того, чтобы они смогли инвентаризацию сделать.
Чрезмерно усложнена система обмена данными.
Вообще чрезмерно утяжелена и усложнена. Зачем мне боинг, если я хочу просто каждое утро приезжать на работу и уезжать с работы. Достаточно матиза.
Очень глючная. Например шикарные сканеры Datalogic напрочь отказались работать с ней. Точнее 1С не видела эти сканера. Путем долгих (крайне сложная конфа) копаний в отладчике удалось найти и исправить ошибку. Несмотря на мои багрепорты, спустя 4 года ошибка все еще присутствует и мне приходилось после каждого обновления залезать в конфу, снимать с поддержки и править код. 0 на 1. )
Оно весьма крупное (eComm + eCare) и всё у нас, в общем-то, хорошо. В том числе и с дебагом. Особенно приятно с hot-reload в версии >0.61 и тайм-тревеллом.
Нерешаемых проблем не обнаружили, композиция компонент в реакт очень хорошо работает.
Довольно легко подключаются сторонние либы. Мы подключили проприетарную нативную либу по распознаванию лиц и документов с потока видео из камеры и это не заняло у нас много времени. Работает хорошо и на андроид и на айос.
Из проблем, столкнулись лишь с долгим временем запуска андроид приложений (на айос вполне нормально), т.к. для этого требуется запускать движок JS. Пробовали различные ухищрения, но они давали не очень существенный прирост. Сейчас смотрим в сторону Hermes, по заверениям, он может дать прирост х2
И да, у react-native есть потрясающая фича — обновление приложения «на лету», даже не надо обновлять само приложение в магазинах (play market, ios store).
Т.к. приложение запускает index.bundle.js, то его можно подгрузить с интернета во время запуска и пофиксить багу, без обновления основного приложения.
Очень приятная плюшка, а flutter так может? )
Следует понимать что это актуально только если реализовывается shouldComponentUpdate со сравнением функций переданных через props. Стандартная реализация shouldComponentUpdate просто возвращает true, поэтому компоненту глубоко плевать на то, новосозданная это функция или закешированная.
П.С. вот хорошая статья на тему производительности реакта http://blog.csssr.ru/2016/12/07/react-perfomance/
За 5000$ на банковском счету в Парагвае можете получить вид на жительство(седула), считается, что если вы зарабатываете деньги за границей, как фрилансер, то и налоги платите там, поэтому налог в Парагвае не платите, было по крайней мере так. Это «страна О'Генри», поле непаханное во всем.
Много денег, конечно же, не решат проблему, ну вот дать шанс, что изменения хоть будут, они точно могут.
Но, да, это все не про нас, у нас немного другие цели
Там по ссылке скачать форма для заполнения и после чего вам должно по идее прийти письмо на почту с инструкциями
Персистентность — свойство объекта/структуры позволяющее поддерживать множество его версий (это требование ФП мира). Тогда, персистентная структура — это коллекция, которая позволяет выполнять тот-же набор операций и для своей предыдущей версии. Такие структуры встречаются и в императивных средах, и могут быть построены на изменяемом внутреннем состоянии (с сайд-эффектами).
Неизменяемость — свойство объекта/структуры запрещяющее его любые изменения. Понятно, что неизменяемая структура после модификации представляет собой копию предыдущей версии + конкретные изменения (например новый элемент). При этом, неизменяемые объекты всегда персистентны (т.е. версию которую мы когда-то создали мы не можем изменить/удалить). Такие структуры тоже есть в императивном мире, например java.lang.String (моя любимая коллекция). Неизменяемость — это ограничение функционального мира (т.е. отсутствие деструктивных апдейтов). Может ли неизменяемая структура быть построена на изменяемом внутреннем состоянии? Я думаю да. Есть такое понятие как локализация мутации. Отличный пример такой мутации Паша Павлов рассказывает в этом видео на примере очереди банкиров. Т.е. формально коллекция неизменяемая (по набору элементов), но во внтуренней структуре есть некоторые места, которые подвержены мутациям, т.е. нельзя сказать, что такие структуры всегда без сайд-эффектов.
ЧФСД — это класс структур без сайд-эффектов. Баста.
Вы исходите из ложного предположения, что продуманы хорошо как интерфейсы, так и концепция взаимодействия этих микросервисов. Но если уж понадобилось их все переписать — можете быть на 95% уверены, что и в интерфейсах, и в общей концепции их взаимодействия есть серьёзные проблемы, и переписывать вы будете шило на мыло.
Кроме плохого кода самих микросервисов могут ещё быть:
И этот список можно продолжать очень долго, и ни один пункт вы не сможете исправить, если будете переписывать только часть кусочков. В лучшем случае придётся переписать все их по-очереди, и долго жить в переходной схеме.
Отличным примером такого архитектурного изъяна на уровне протокола может служить wire протокол MongoDB: абсолютно ущербный механизм получения кода ошибок привёл к тому, что, фактически, используется вызов команды для записи/апдейта/удаления вместо соответствующей операции, которая нативно есть в протоколе:
Так же стоит отметить, что и в монолитных системах точно так же существует понятие интерфейсов и модулей, которые через эти интерфейсы общаются друг с другом. Конечно, это не позволяет взять и переписать какой-то кусок на другом языке, или в другой парадигме программирования (скажем, асинхронный питон вместо синхронного), но не стоит ставить знак равенства между монолитом и неструктурированным спагетти-кодом. Я более того скажу, нормально спроектированный монолит будет проще поддерживать, чем плохо спроектированную груду микросервисов. А уж сколько геморроя вы начнёте огребать, если начнёте задумываться о микросервисной системе, которая не будет сыпать ошибками на каждый чих в сети, и при этом гарантировать приемлемое время ответа… LIFO очереди, exponential backoff, circuit breaker, всякие хитрые политики service discovery, которые позволяют работать системе в сдеградированном режиме — да там целый гигантский ворох проблем, про который никто особо и не думает, когда рассказывают, как"микросервисы всех спасут".
Этот подход настолько понравился нашей команд, что завели даже отдельные алиасы для git:
Очень удобно делать