Возможность иметь устаревший стек это скорее антивозможность, а старая версия фреймворка возможно не только старая но уже и дырявая. И то время, которое команда тратит на возню с микросервисами она могла бы потратить на обновление зависимостей и новую фичу и ее границы тоже бы изучила. В крупных корпорациях к обновлению зависимостей принуждает юротдел - выдают и отзывают разрешения на использование либов, могут за устаревший фреймворк сделать ай-йай-йай.
Чем больше технологий задействовано в создании продукта, тем острее проблема копметентности. Ибо или разработчик знает много разного, но крайне поверхностно, либо знает мало разного но сумел погрузится в некоторые важные детали. Но не все вместе. А мса за собой тянет лютый зоопарк обычно.
Касаемо различных языков, это то что упоминает автор, вот мол мс на гоу, а вот на пайтоне. Более того ходят слухи, что в нетфликсе, чтобы люди не шарили код, специально заставляют писать сервисы на разных языках. Так что разнородная языковая среда это вполне укоренившаяся идея в индустрии.
В амазоне, скажем, десятки тысяч раработчиков, конечно, им там было бы тяжело писать единый монолит. Они там разделились на мсы написали статьи про мса и живут себе спокойно. А потом эти статьи читает команда из 10 человек и применяет мса к себе и вот тут у меня возникают сомнения.
Может им монолит попробовать? Знаете как удобно когда можно сбилдить все одной командой. А запустить локально одним кликом на кнопку ран в ide. А как дебажить будет приятно, прошел по шагам топ-топ-топ дебагером - багу нашел. А коммуникации какие надежные внутри процесса - вызвал функцию, а она взялась и вызвалась, и никак иначе.
А гугл мне расскажет как в рамках единой атомарной операции проапдейдить базу и послать месседж в натс? Ну ведь не расскажет же. Отсутствует такая возможность в природе.
Если мне не изменяет память, Nats в дефолтной конфигурации (без jetstreams), вообще доставляет только тем подписчикам кто онлайн. А если все оффлайн то никуда не доставляет.
Но вообще, потеря месседжей это обычно неизбежная ситуация. Скажем, если мы апдейтим базу и посылаем об этом нотификацию через меccедж брокер. Эти два шага же не образуют единую атомарную операцию. А значит мы можем проапдейтить бд и тут же упасть и месседж просто не будет послан, хотя стейт и изменился.
Так что надежный сервис должен обычно иметь план Б на случай потери собщений (и их дупликации кста), а если такой план есть то надежность месседж брокера не столь важна, если не доставляет постоянно боль, то ну и ладно.
Прокоментирую. Чтоб применять практики как в Нетфликс и Убер, надо быть как Нетфликс и Убер - быть очень большими и нанимать квалифицированный персонал за 300 килобаксов. А если вы маленькие, бедные и умеренно компетентные - то лучше присмотрется к технологиям попроще. Монолит, единый яп и синхронный код - отличный выбор для огромного количества юзкейзов
Вот это я и имел ввиду когда говорил про скотское отношение как к рабам — выжать и выбросить.
Что значит выбросить? С чего вдруг увольнение — это выбросить? А самому уволиться по вашему это, видимо, предательство? Работа — это сделка обмена времени сотрудника на деньги компании, и как любая честная двусторонняя сделка действует она ровно до тех пор пока интересна обеим сторонам, и любая сторона вправе прервать ее в любой момент — это честно и логично, если сотрудник имеет право сам уволиться когда пожелает, то и компании имеет право уволить сотрудника и наоборот.
Более того — компания даже не осознает, что часто это она поставила сотрудника в такие условия.
Ни в какие «такие» условия взрослого дееспособного самостоятельного человека без его желания и согласия поставить невозможно, особенно когда речь заходит об айти, ладно б вы говорили об этом в контексте угледобычи в моногороде на краю света, но в айти? как?
Да даже и с автоматизацией — это все очень-очень грустно. Хоть многие QA инженеры и бодрятся, психологическая защита, наверное, какая-то. А а у кого эта психологическая защита сдала под напором объективной реальности — выгорают и киснут. Впрочем, чего спорить, кто не может с этим жить — идут в другие направления работать.
Дерьмовая работа — главная причина выгорания, а может даже и единственная. А работа в QA (как у автора) — одна из самых наидерьмовейших в АйТи, ну может саппорт еще дерьмовее. И все советы по сути о там как Игната заставить делать дерьмовую работу радостно и с песней (никак) и как самому Игнату убедить себя делать дерьмовую работу радостно и с песней (никак). Так что гнать надо такого сотрудника без всякого сожаления, нехай на стройке бетон лопатой пойдет покидает, раз ему в теплом офисе не работается.
Это работало в старые добрые времена, когда все кодили и коммитили как хотели. А сейчас ведь есть процесс: таска -> бранча на таску -> затем пул реквест с ревью. Подмешать туда левого кода нет ни особой возможности ни желания. Все проблемы нынче обрабатываются явно.
Есть ещё популярная ошибка #7 — недооценка важности инвестиций в инфраструктуру, в гигиену кода, консистентность дизайна и так далее. Отдачу от вложений в это почти не возможно оценить и иногда это становится огромной проблемой, превращая разработку в непрерывную боль у разработчиков.
Хочется спросить Google: ну зачем же вы ведетесь на политиканов и бюрократов?
Я вам отвечу почему они ведутся — потому что их иначе в тюрьму посадят. Вот например какое разъяснение давал sourceforge некоторое время назад по поводу отключения некоторых стран от доступа к свободному ПО:
However, in addition to participating in the open source community, we also live in the real world, and are governed by the laws of the country in which we are located. Our need to follow those laws supersedes any wishes we might have to make our community as inclusive as possible. The possible penalties for violating these restrictions include fines and imprisonment.
Сдается мне, автор все перевернул с ног на голову, фактически придумав конспиративную торию зарождения ООП. В общем, вот моя версия: сначала были структуры данных и были функции/процедуры, дальше люди заметили, что очень часто приходится ссылку на структуру передавать в функцию, а зачастую эти фунции вообще имеют ровно один параметр — собственно эту ссылку. Дальше улучшение путем объединения структур и этих функций в единую сущность лежало на поверхности. Ну а дальше встают вопросы расширения функциональности — отсюда вырастают наследование и полиморфизм, который выводится просто из здравого смысла. ООП готово. И никаких вам размышлений о сложности приложений, банальные итеративные улучшения ради немножко удобства. Но сложные программы писать стало легче, конечно, на то они и улучшения.
Ну если менеджерам (т.е. и компании) не нужно чтоб вы находили решение, «которое повысит роизводительность труда, снизит издержки и увеличит прибыль», то вам-то это зачем?
Ой. Это серьезно. При таких раскладах - мса без вариантов, что тут спорить.
Возможность иметь устаревший стек это скорее антивозможность, а старая версия фреймворка возможно не только старая но уже и дырявая. И то время, которое команда тратит на возню с микросервисами она могла бы потратить на обновление зависимостей и новую фичу и ее границы тоже бы изучила. В крупных корпорациях к обновлению зависимостей принуждает юротдел - выдают и отзывают разрешения на использование либов, могут за устаревший фреймворк сделать ай-йай-йай.
Пс. За тся извените.
Чем больше технологий задействовано в создании продукта, тем острее проблема копметентности. Ибо или разработчик знает много разного, но крайне поверхностно, либо знает мало разного но сумел погрузится в некоторые важные детали. Но не все вместе. А мса за собой тянет лютый зоопарк обычно.
Касаемо различных языков, это то что упоминает автор, вот мол мс на гоу, а вот на пайтоне. Более того ходят слухи, что в нетфликсе, чтобы люди не шарили код, специально заставляют писать сервисы на разных языках. Так что разнородная языковая среда это вполне укоренившаяся идея в индустрии.
В амазоне, скажем, десятки тысяч раработчиков, конечно, им там было бы тяжело писать единый монолит. Они там разделились на мсы написали статьи про мса и живут себе спокойно. А потом эти статьи читает команда из 10 человек и применяет мса к себе и вот тут у меня возникают сомнения.
Может им монолит попробовать? Знаете как удобно когда можно сбилдить все одной командой. А запустить локально одним кликом на кнопку ран в ide. А как дебажить будет приятно, прошел по шагам топ-топ-топ дебагером - багу нашел. А коммуникации какие надежные внутри процесса - вызвал функцию, а она взялась и вызвалась, и никак иначе.
А гугл мне расскажет как в рамках единой атомарной операции проапдейдить базу и послать месседж в натс? Ну ведь не расскажет же. Отсутствует такая возможность в природе.
Если мне не изменяет память, Nats в дефолтной конфигурации (без jetstreams), вообще доставляет только тем подписчикам кто онлайн. А если все оффлайн то никуда не доставляет.
Но вообще, потеря месседжей это обычно неизбежная ситуация. Скажем, если мы апдейтим базу и посылаем об этом нотификацию через меccедж брокер. Эти два шага же не образуют единую атомарную операцию. А значит мы можем проапдейтить бд и тут же упасть и месседж просто не будет послан, хотя стейт и изменился.
Так что надежный сервис должен обычно иметь план Б на случай потери собщений (и их дупликации кста), а если такой план есть то надежность месседж брокера не столь важна, если не доставляет постоянно боль, то ну и ладно.
Прокоментирую. Чтоб применять практики как в Нетфликс и Убер, надо быть как Нетфликс и Убер - быть очень большими и нанимать квалифицированный персонал за 300 килобаксов. А если вы маленькие, бедные и умеренно компетентные - то лучше присмотрется к технологиям попроще. Монолит, единый яп и синхронный код - отличный выбор для огромного количества юзкейзов
Что значит выбросить? С чего вдруг увольнение — это выбросить? А самому уволиться по вашему это, видимо, предательство? Работа — это сделка обмена времени сотрудника на деньги компании, и как любая честная двусторонняя сделка действует она ровно до тех пор пока интересна обеим сторонам, и любая сторона вправе прервать ее в любой момент — это честно и логично, если сотрудник имеет право сам уволиться когда пожелает, то и компании имеет право уволить сотрудника и наоборот.
Ни в какие «такие» условия взрослого дееспособного самостоятельного человека без его желания и согласия поставить невозможно, особенно когда речь заходит об айти, ладно б вы говорили об этом в контексте угледобычи в моногороде на краю света, но в айти? как?
Ага, пластиковый конус-колпачек к роботу приклеили.
В доступных девушках и быстрых тачках? Ну уж точно не в 80% коде каверидже.
Что значит «всего лишь»? Это так-то $1500 в месяц (в рублях -100 тысяч) — нормальная зарплата для хорошего аутсорсера из бедной страны.
Есть ещё популярная ошибка #7 — недооценка важности инвестиций в инфраструктуру, в гигиену кода, консистентность дизайна и так далее. Отдачу от вложений в это почти не возможно оценить и иногда это становится огромной проблемой, превращая разработку в непрерывную боль у разработчиков.
Я вам отвечу почему они ведутся — потому что их иначе в тюрьму посадят. Вот например какое разъяснение давал sourceforge некоторое время назад по поводу отключения некоторых стран от доступа к свободному ПО:
sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law