Чему я научился за 30 лет работы программистом 

Ох, спасибо, Михаил. У меня опыта в программирований недавно стукнуло 3 года. И мне нравится тейк про то, что нужно осознанно подходить к задаче, и прежде чем что-то выбрать или начать производство - понять, а что это такое и нужно ли оно? Не идти просто так за всеми. Такой же подход в каком-то из подкастов говорил Соер, ну он собственно и топит за осмысленную разработку, когда ты понимаешь, что делаешь.

Благодарю, интересно. Записывайте еще, если не трудно.

Спасибо за свои программысли, очень помогают увидеть вещи под другим углом)

Отличный выпуск, спасибо! =)

Много новых терминов узнал, спасибо за рассказ)

Спасибо, личный опыт это драгоценно. Спасибо и Божьих благословений Вам и Вашим близким.

Михаил, спасибо что делитесь опытом. Очень интересно и затягивает в тему айтишечки)

Интересная история ❤

Выходить из vim….)))

Как хорошо, что попал на Ваш канал. Спасибо большое за творчество! Засмотрелся, подписался! Интересные мылси, хорошо поставленная речь! Очень интересно послушать матерого кодера)))

Забавно. Задавали ли я вопрос Why? Не часто, но задавал. Обычно ответом было - потому что так. И все. Я исхожу из одной простой мысли данной мне моим первым и наверно одним из лучших в моей жизни начальником еще в советском НИИ - лучшее враг хорошего. Ничего не надо улучшать, если оно и так работает. Я нажимаю кнопки с 1986 года, хотя и не все это время подряд. В 1992-94 работал дальнобойщиком, потом настраивал пневматические системы. Веселое время было, но в 1997 все же вернулся в программизм и уже в 1999 получил работу в США. Так что что в программизме самое важное, вопрос наверно открытый. На мой взгляд после примерно того же 30 летнего опыта (хотя с алголом я познакомился еще в школе в далеком 1979 году) ответ достаточно прост, хотя и другой - чем меньше ты нажимаешь кнопок, тем лучше для тебя и твоего продукта.

Чему я научился за 25 лет программирования - красиво делай, красиво будет

Начала изучать программирование с месяц назад, 90% терминов в видео не поняла от слова совсем, но уловила ваш посыл, спасибо)

Красиво!

Некоторых в настоящее время при слове "монолит" просто вводит ступор и ты в их глазах становишься самым непонимающим айтишником на самом низу эволюции) Мне нередко приходилось встречать такую реакцию людей на собеседованиях и на местах работы. Более свойственно это молодым людям, которые привыкли гнаться за модой и модными течениями, пытаясь все в мире перевести на эти новые рельсы, это лишь показывает их малый опыт в мире IT. Я встречал сеньоров, которые становились сеньорами в 23, и мидлов которым было под или за 50, при этом они работали в одной конторе, и имели за плечами разницу в опыте измеряющуюся в десятках лет) Первые просто угодили своей конторе, а вторые работали в соответствии с совсем другой философией) Все относительно как говорится. Хорошо что я посмотрел это видео, так как в нем именно это еще раз подтверждается и я теперь не буду себя чувствовать неуверенно при разговорах о монолите и его праву на существование в современном мире.

Мне 18 и я хочу стать программистом. Люблю посмотреть такие видео , очень мотивируют к продвижению в этой сфере 😁

Как я понял. Надо делать удобно и в зависимости от требования:)

Много написал. Считайте это выплеском боли человека, который работает на ужасном монолите и уже не в состоянии это терпеть =) С технической точки зрения и в идеальном мире не могу поспорить. Но в реальности мне кажется есть больше аспектов, чем только то, что монолит может выдерживать те же нагрузки. Я встречал однажды такой монолит, который сам с собой общался через внешнюю очередь и просто разные модули этого одного монолита подхватывали нагрузку, когда могли. Код - по сути монолит, но можно скейлить количеством задеплоенных инстансов почти, как в микросервисах, имея при этом более простую инфраструктуру. Главная проблема вылезает, когда растет команда. В такой команде получается, что каждый может вроде отвечать за какую то свою зону, но доступ имеет ко все кодовой базе. Даже если представить, что в изначальной версии мы имели идеальную архитектуру, что вряд ли, со временем начинается каша. На каждого девелопера сверху давят менеджеры по срокам и начинается срезание углов - где-то надо было использовать готовый код, но что-то не срослось и сделал запрос в общую базу в своем модуле, где-то не понял замысел архитектора и добавил свой код в не совсем верный модуль, следующий разработчик посмотрел на это и решил, что так и надо и пошло поехало. Через N лет получаем что-то невероятное мягко говоря =) Кроме того, чаще всего монолит - это одна общая база и все это ползет в нее тоже. У меня опыт, конечно, не гигантский, но я работал и на нескольких монолитах и на микросервисных проектах. Все монолиты, что я видел, были просто ужасающими. Сейчас уже пол года работаю над довольно крупным монолитом, команда опытная, сеньоры и архитекторы сохранились на проекте еще почти со времен его зарождения, код стандарты, код ревью довольно жесткие и аппрувить могут только несколько избранных. Но это не помогает. Во певых, даже эти избранные вообще ничего не помнят про большую часть проекта. Что в целом не удивительно, когда отвечаешь за все сразу. Проект превратился в полное месиво, где нет никаких разделений ответственности, все что угодно может происходить где угодно. Я так за эти пол года и не понял изначальной идеи архитектора, за слоями костылей этого уже не разглядеть. База данных - вообще кошмар. Под сотню схем, сколько таблиц вообще один господь бог знает. Есть много таблиц дубликатов или чего-то в стиле payments, payments1, payments_depricated и тд. В таблицах сотни полей, большая часть из которых пустые и никто не знает, зачем они нужны и нужны ли вообще. Делать релейшены между таблицами никто и не помышляет уже давно. Данные, которые вроде должны бы храниться где-то рядом, могут быть разбросаны по разным схемам в рандомном порядке. Микросервисная архитектура, что я видел тоже была не идеальной. Но она хотя бы устанавливает более четкие границы между зонами ответственности, которые нарушить очень сложно. Над разными зонами могут работать разные команды, что снижает объем того, что необходимо знать разработчику на своих участках. Сервисы сильно проще для понимания. По мне, если не иметь какую-то идеальную команду, где все дисциплинированы, одинаково хорошо разбираются в технологии и при этом еще и не меняются, то монолит будет эффективнее в разработке. У тебя все под рукой, ни с кем договариваться не надо. Берешь и делаешь. Но все упирается в команду, как по мне. Люди не идеальные, они меняются, знания теряются, а область ответственности растет. И вместе с этим растет сложность добавления новых фич. Микросервисы в начале сложнее. Дополнительные сложности с инфраструктурой, общением между командами и.т.д. Но эта сложность со временем растет предсказуемо и не так сильно. В то время, как сложность работы с монолитом в начале меньше, но со временем ускоряется все больше, пока компания не помрет в один момент. Мне кажется идеальный вариант начинать с монолита, который изначально планируется, под разбиение на сервисы в момент, когда сложности этих двух подходов пересекутся. И последний аспект, уже более относящийся к самому девелоперу. Возьмем девелопера, который проработал на монолите в котором из стека всего и есть, что C# и SqlServer. Кому он будет нужен на рынке, если его вдруг уволят или компания умрет? Это же просто конец карьеры, если только не найти точно такую же компанию.

Михаил, большое спасибо за видео и личный опыт! Хотелось бы также услышать Ваше мнение насчет ChatGPT и страшилок, что скоро developers, technical support engineers, QA engineers могут быть заменены искусственным интеллектом. Спасибо

Согласен с автором. Мне лично тоже запомнился случай, когда мой начальник снаряжал сервачок в какой-то технологический цех еще на 2000 винде и тамошний начальник айти завел речь, что надо бы автоматические обновления, антивирусы подрубить, на что начальник так же ответил: нафига? Сервак стоит, собирает свои данные с датчиков, в него никто не лезет, и так и будет работать годами. Поставь автообновления и начнется: то то не так, то это не так, здесь перезагрузитесь, здесь переустановите. А потом довелось немного коснуться японского айти, там вообще могут работать на доисторическом или самопальном софте и не париться как у нас: ах ох, надо срочно обновляться!

Очень крутое видео! Можете рассказать любопытному фронтендеру возможна ли такая нагрузка при которой понадобятся микросервисы или это нужно только для организационных вопросов в больших командах?

То, с чего следует начинать всем - монолит, его хватит условным 80% по принципу Парето, а на время выхода на IPO хватит всем. Золотая середина - это SOA, но не микросервисы. Микросервисы - это удел единиц, но это модно, поэтому они везде.

Спасибо за видео! Интересно, у монолитного Stackoverflow компиляция тоже занимает весь день?🤔

Сделайте, пожалуйста, выпуск "Куда уходят умирать программисты за 50". Есть куча роликов, как стать джуниор программистом, а вот ничего про то, как/куда продолжить быть программистом. Опыт в программировании 20+, бэк на java, застоявшийся мидл, никак не сдвинуться дальше. На своём месте работаю качественно. Работал в монолитах, умею в микросервисы. Освоить новое - не проблема. Но, наверное, гореть только работой уже не готов, когда днем и ночью только код, курсы, постоянные флешмобы "лучшей версии себя". Всё-таки семья, хобби, ложиться костьми не хочется. Возраст - сорокет с хвостом. Оглядываюсь по сторонам - практически не вижу своих ровесников рядом. Куда они уходят умирать, с какой скалы сбрасываются? Знаю, некоторые перешли в аналитиков. Кто-то - в админов/девопсов. Кто-то в бухгалтерию(раньше был тренд). Кто-то в архитекторов или в административную работу, управление. В чём причина этого, боятся, что год-3-5 и мозг сдаст, не смогут конкурировать с молодняком на равных? Как вы видите возможный путь? Есть ли вариант переквалифицироваться в датасайнс или еще во что-то смежное интересное перспективное(понятно, что это нифига не просто, тут скорее речь о возможном рывке в 2-3 года). Понятно, что в Канаде/США и России этот путь - он разный, но всё же. Спасибо.

ещё один хороший навык: умение спрашивать: а почему нет? особенно когда в команду приходит новенький и модный мальчик и спрашивает: а почему вы это делаете на монолите, а не на микросервисах? или а почему вы используете TFS, а не модный сейчас git. В ответ спросить его: а объясни почему по-твоему мы должны переходить на эту технологию? Пусть объяснит. А самому внимательно послушать. Кстати, вопросы почему? и зачем?: они принципиально отличаются друг от друга. И в английском тоже их часто путают: Why - meaning: what caused this? And: what for - meaning: what will be the outcome or the result if you do this?

Относительно cloud vs 'on premises'. Есть такой зверь: Azure on premises Он спасет мир :-)

Не часто на старых технологиях проекты хороши и востребованы, если хочется расти по карьере, то только актуальный стек, в целом можно и не бежать за стеком, но тогда надо быть уверенным, что не останешься без работы завтра (в РФ на легаси можно не найти то что хочешь)

Здраствуете Михаил можно вопрос стоит ли изучат Xamarin для мобильной разработка

Привет, что думаешь о гос службе в IT? Я имею в виду фсб или кгб какое-нибудь. Как считаешь стоит ли начитать свою карьеру там? Будет ли это хорошим опытом? Да и вообще общее мнение интересно насчет этого.

А мы с коллегами второй месяц уже Apache nifi в кубер пытается запихнуть, а что поделать, а что поделать, никакого монолита))

Добрый день! А где можно посмотреть что за сайт на бусти?

У монолитной и майкросёрвис архитектуры есть у обоих свои преимущества и недостатки, как вы и сказали. Майкросёрвисы можно можно более точечно скэйлить. Монолит же можно скэйлить только полностью. Всё решает use case а не хайп

Вообще так как ты авторитетный дядька, можно было записать небольшой ролик про нейросети, я понимаю не твоя стезя в целом, мнения на этот счёт, может личный опыт использования в жизни и в разработке, насколько это перехайп, ибо в целом есть две волны мнений : "Нейросети отберут хлеб у всего живого или Нейросети фуфло и до настоящего профи им далеко", ибо художников они уже неплохо так уделали, хочется посмотреть на вопрос со всех сторон

Спасибо за интересную информацию. Но насчет микросервисов: оптимизация работы конечного продукта может быть не всегда является окончательной целью. Если проект ОЧЕНЬ динамично развивается и на нем сидит с пол тысячи сотрудников, то прогонять, к примеру, через CI\CD работу каждого сотрудника может значительно замедлить общий процесс, тк dev окружение не всегда такое "щедрое", как prod)) А замедление процесса на таких объемах может конвертироваться в солидные финансовые потери. Возможно для Netflix с их штатом в 15000 этот переход решил какие-то проблемы в бизнес процессах. У стека, я смотрю, около 200 сотрудников. Что скажете если посмотреть на эти програмысли с такой точки зрения?)

попробуйте открыть для себя "serverless" патерн, вместо монолитов и микросервисов.

ссылку на интервью так и не разместили)

OOOOOooooooooooooo двигаца вперёд быстрее ПОчему Зачем

Крутой дядька) Сам фронтом интересуюсь. Но когда смотрю про бэк ребят, то понимаю какие они лютые) И, наверное, понимаю, почему ребята из бэка не считают фронтменов за прогеров)

Профи фигни не посоветует: думай что и зачем делаешь и не забывай про бабки))

Очень неудобно поправлять, но не flash mode, а flash mob (толпа).

я заметил про монолит и микросервисы рассуждают только менеджеры ) ... программисты работают с тем что есть ) ... решит архитектор делать микросервисы, хорошо, нет, то-же неплохо )

Учу с#, и докер кажется пока сложно. Но все таки придётся учить его

Второй после если вести счёт

Привет. Посмотрел произношение build на американском англ. и на британском - оно одинаковое. Я думаю, что это дикция конкретного человека была - 'булд'

Жизненно, особенно когда твой сервис и так является Микросервисом в большой системе, а вас заставляют распиливать ещё на 100 разных сервисов его) это не всегда нужно Это как с базами, иногда нужна и денормализация

Привет. Услышал много раз слово монолит. Это о чём?

Помогите пожалуйста мужу устроиться на работу, он программист C#, проработал 15 лет в компании, уволили, ищет работу, но пока отказы, у нас ребёнок инвалид, работать я не могу, муж один кормилец в семье, а у нас ещё кредиты, помогите пожалуйста, может быть кто нибудь сможет помочь, ему удаленка нужна 🙏

Если вы задаете вопрос зачем это вам и честно не можете на него ответить, то это значит что вы выгорели и уже физически не тянете конкуренцию с молодыми и тупыми, которые такие вопросы не задают. Они знают ответ. Затем чтоб получить вашу зарплату вместо вас.

У меня пермоментое состояние того, что ты только подумал что, чему то научился. А потом понимаешь что ничего не знаешь

Стоит ли 45 летним программистам переезжать в Канаду?

20 мин про то, что научился задавать вопрос why.

Почему я не увидел это видео два года назад когда начал изучать бэк)

Я в шоке что вы уже 30 лет работаете) Вы выглядите на 35, надеюсь не с 5 лет работаете))

А с кофе прикольно получилось то!) Буква "Р" такая картавая, акцент американский будто))

Что такое трафик?

Прямо задел за живое. Мы распиливаем свою срм на отдельные части и связываем микросервисами. Наняли кучу девелоперов, тестировщиков, аналитиков, ушли в клауд. Но блин новые девелоперы ничего не знают про нашу систему. Куча созвонов, митингов. Обычная ситуация когда у девелопера в день 2 часа митингов. В таком режиме полтора года. В результате юзеры по-прежнему используют старую репортинговую систему вместо новой потому что с новой куча проблем. А у нашей старой дев команды кроме обычного добавления фич в систему прибавилось куча дополнительной работы с интеграцией.

За 30 лет работы программистом научился быть ДевОпсом)

Миша, детей твоих давно не видно... Покажи хоть как-нибудь!

Первый!!!

Это оно? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-nZX13dVxnJw.html

Как понять, что ты стал програмистом?

монолиты дорого масштабировать, по этому все сразу делают микросервисы

Казалось бы название "Чему я научился за 30 лет работы программистом" а по итогу пересказ истории , а чему научился - нет ...

Я бы сказал, что мейнстрим и хайлоад вообще плохо совместимы, мейнстрим ориентируется на скорость разработки и на то, что удобно массам, а под высокие нагрузки обычно наоборот приходится отказываться от удобного в пользу более простого и предсказуемого (и быстрого).

А зачем 30 лет работать программистом?

Послушал 9 минут. Ничего не понял.

Микросервисы решают проблему менеджмента. Поэтому толковые книжки об этом сразу начинаются с Conway’s law. Если монолит не соответствует орг-структуре, то начинаются проблемы с временем доставки фичей до пользователя. Да, есть технические преимущества, но они менее значительны. При желании можно хорошую архитектуру сделать с монолитом и десятком сервисов вокруг. Но если у вас 40 команд работают изолированно с разной скоростью, вас это не спасёт. А вот если 20 программистов в пяти командах, то нафиг это не надо. У них просто на тулинг времени не будет и они вечно будут заняты проблемами интеграции своих сервисов.

Программировать? Лол

Удивительный канал, программист с опытом вместо того чтоб работать собирает донаты со зрителей. Успешный успех? Докер это отстой, они используют виртуал бокс а в них имиджи из говна и палок слеплены. Лучше Фотон ОС и ВМваре.

А почему Миша записывает это видео?

Надоели микросервисы. Из-за этого хайпа столько ресурсов уходит.