Организованное программирование

Друзья, привет. Это подкаст организованное программирование. С вами его ведущий Кирилл Макевнин. И в гостях у меня Михаил Флёнов, автор канала Программысли, ну и вообще человек, которого довольно многие знают, читали по его книжкам и по его видео, которых, в общем-то, на Ютубе, наверное, очень-очень много разного рода.

Миш, привет. Пару слов расскажи про себя. Где сейчас работаешь, чем занимаешься? Привет. А, работаю просто деф-менеджером. Основная моя работа. А, управляю командой в достаточно крупной компании. Она глобальная представлена на всех, можно сказать, рынках, на всех континентах. Мы есть и в Австралии, и в Америке, и в Мексике. Занимаемся тем, что софт типа 1Скадры. И я отвечаю за достаточно большой модуль. Это, ну, я не один менеджер, у нас несколько менеджеров. отвечаем за модуль, где оргструктура компании. Если мы так сим как можно проще скажем, то это оргструктура компании, менеджер, и найсли

честно, сейчас ничего особо интересного нет. Просто работаю менеджером на старости лет такая спокойная работа. Можно сказать, что без сильных таких вот вызовов потрясений сейчас не потрясения всегда есть, когда ты работаешь менеджером. обязательно есть какие-то проблемы, какие-то созвоны, там, что-то ломается, что-то. Эта неделя, кстати, была одна из таких, когда было много-много проблем, на удивление. Но я бы не сказал, что что-то какие-то вызовы. Работать, например, на такую компанию - это немножечко проще, чем работать в банке. Банк - это всё-таки ответственность. На старости лет я в банк не пойду. Я уже всё, я уже отработал своё дело на банковских системах. Всё, туда нет, ни ногой. Ну а кого-то пронесло, я забыл это сказать. Какая у нас с собой тема подкаста? А мы сегодня решили поговорить, у нас было несколько вариантов, а мы сегодня решили поговорить про паттерны проектирования, программирования в широком смысле этого слова. Сегодня будет без лай-кодинга, хотя последнее время я часто стал видео делать с лай-кодингом. И, кстати, ребят, если эта тема зайдёт и станет интересна, потому что иногда в таких видео говорятся, что всё довольно абстрактно, дайте конкретику, мы в каком-то виде сможем потом сделать именно что-то практическое, прямо с видео, с шарингом экрана, чтобы можно было прямо посмотреть, как это всё работает. Соответственно, сегодня мы поговорим про паттерны. И у меня есть, э, сразу небольшой списочек вопросов. Я начну с первого вопроса, который я заготовил. А, смотри, Миш, когда говорят про паттерны, в большинстве случаев имеют в виду банду четырёх, как ты вообще к этому относишься? нормально, потому что они были первыми, кто эту тему, можно сказать, поднял и популяризировал. Поэтому это как бы можно можно сказать отчасти дань а создателям. И когда мы говорим Linux, очень часто подразумевает Линуса Торвальдца, хотя он всего лишь ядро создавал когда-то и сейчас он давно уже о делает ревью, он ещё ещё связан. Но когда мы говорим Linux, очень часто мы подразумеваем Линукса и о нём говорим как основополагающего человека. Лицо Линукса. Здесь то же самое. Банда четырёх, которые первыми выпустили книгу Паттерно программирования, которые это популяризировали. И это нормально. Да, паттерны уже вышли далеко за это, далеко за книгу ушли. И их уже столько. Я не назову себя экспертом в них. Аэ, но я считаю себя фанатом хорошего паттернного программирования. Я очень люблю паттерны, и поэтому я нормально отношусь. Вот если коротко, норм. Я скажу, что меня беспокоит в этом и всегда беспокоило. Дело в том, что когда общаешься с людьми на эти темы и начинаешь говорить про какие-то паттерны, это рождает, знаешь, обратную ситуацию. То, что вот то, что они придумали - это паттерны, а всё остальное от лукавого. Они про это не писали, значит, это не паттерн. А вот к этому негативно отношусь. Точно так же опять жеш к Линуксу. Извини, я тоже фанат Линукса и этого не считаю себя опять же экспертом в Линуксе, но я его фанат. А и кто-то считает определённый дистрибутив. Вот это труди дистрибутив. Всё остальное - это фуфло. Точно так же и здесь кто-то считает только вот эти паттерны, только вот эти четыре человека, которые создали их, они основное, а всё остальное - это плохо. Нет, всё это паттерны. Их уже действительно можно, если поговорить так, их уже много. Я, наверное, все даже все направления даже не знаю. Все паттерны я точно не знаю, но все направления там и параллельное программирование уже выходили паттерны. Кто-то собирал архитектурные паттерны, их очень много различных группировок таких, если сгруппировать, которых не было в оригинальной книге и, наверное, никогда и не появятся. А, но это тоже паттерны, которые тоже показывают, как правильно программировать, как лучше решать задачи, с которыми программисты сталкиваются каждый день. Ну да. То есть они как бы это придумали, ну, в смысле, по крайней мере, популяризировали, но того, что только этим ограничивается мир, конечно, такого нет. И уж совершенно неправильно говорить, как знаешь, как Библия, вера какая-то получается, да? Вот в Библии этого не написано, значит, это не считается. А, но это частая распространённая точка зрения. Кстати, я реально с этим постоянно сталкиваюсь, когда общаюсь с людьми, что вот есть правильные вещи, есть неправильные. Да, правильные паттерны и неправильные паттерны. Такое, ну, в том числе, типа, если они про это не сказали, то как вообще можно рассуждать, что это типа вообще паттерн? Хотя на самом деле нет нет никакой, знаешь, этот университет о придумывании паттернов. Нет людей, которые могут одобрить или не одобрить паттерн. Паттерн даже это то, что ты придумал конкретно в своём кейсе для решения какой-то задачи. Это уже паттерн. Может, он станет известным, а может, и не станет известным. Одному Богу известно. Есть ведь вещи, которые уходят просто из-под конкретных людей. Вот они придумали какую-то концепцию, написали: "Я там придумал некий концепт". И он зашёл, например, да? Абсолютно. Но это зависит будет от того, насколько популярная задача. Ведь паттерны они были изначально это общие такие задачи, с которыми программист каждый сталкивается каждый день и как хорошо решать подобные задачи. И если ты найдёшь решение для популярной задачи и это решение будет красивым, да, оно станет популярным. Если оно будет некрасивым или задача не популярная, то такой паттерн, ну, никому не нужен будет, и он уйдёт куда-нибудь в архив. Смотри, перед тем, как ещё дальше вот в это копать, давай, знаешь, чтобы немножко приземлить на конкретику, прямо в двух словах поговорим о самых ключевых вещах. Вот для тебя лично, там, например, если брать даже эту книжку, вот какие штуки оказались наиболее ключевыми для твоего личного уровня программирования и принятия решений в твоём коде? Какие бы ты назвал? Прямо порассуждаем о них в двух словах. Обычно все вспоминают такие: "Абстрактная фабрика". На практике никто не использовал. Её, как правило, в библиотеках реализуют. Я использовал. Мне, кстати, приходилось использовать, аа потому что, когда я работал над собственностью CMS, ээ мне приходилось, я не совсем понял вопрос, ээ, можешь повторить, ну прямо конкретный паттерны разберём, которые вот для тебя одни из самых запоминающихся, как типа, ну, вот это вообще просто классика программирования, это важно, это влияет на стиль программирования и на архитектуру вашего проекта наиболее сильным образом. Если ты можешь выделить такой паттерн, ты знаешь, для меня все вот с с каким бы я не знакомился, для меня каждый является достаточно важным. И выделить какой-то вот без этого жить не можем никогда. Вот тут действительно нужна конкретика, конкретный пример, когда и что. Потому что, например, я се, если я сейчас скажу, э, dependence injection, мой самый любимый паттерн, например, скажу: "Всё, ништяк, я его люблю, обожаю". Но он же ж необходим в объектноориентированном программировании. Если мы пойдём в функциональчину, какая какой dependency injection мне скажет, братан, оно там тебе не особо и нужно. Там там другие паттерны в зависимости от языка программирования, в зависимости от того, где мы работаем. А дизайн паттерны бывают разные, важные бывают разными, где-то строится вокруг каких-то вещей. Например, в C-#шарпе действительно можно сказать, что Dependcy Injection - это один из основных, потому что всё крутится вокруг него, особенно в последнем C-#шарпе, последнем MVC, где мы работаем и веб-приложение, когда ты делаешь, без Dependcy Инжекна в наше время просто невозможно. Ты можешь всё остальное написать как угодно, но всё вот Dependjection ставится во главу, ты уже сразу строишь своё приложение, начиная с него. Наверное, я бы выделил его по двум причинам. Опять же, потому что я в C#R программист, и там он везде практически. А, во-вторых, он, наверное, оставил на моей памяти самое такое яркое впечатление, когда я о нём узнал. Я эту историю когда-то рассказывал на своём канале. Не знаю, имеет ли смысл сейчас в это погружаться или нет, но я выделю Defense Rejection. Расскажи историю. Это интересно всегда. О'кей. Это было очень давно, ещё больше 10 лет назад. Когда я работал уже в веб-программировании здесь, в Канаде приехал, я о дизайн-паттернах вообще ничего не знал. и хотел поменять как-то работу. Меня в очередной раз выговорил на своей работе, зарплата не устраивала. Всё, я пошёл проходить собеседование. Прохожу собеседование, и меня спрашивают: "Расскажи мне какой-нибудь дизайн паттерн". А я о них вообще не знал. Это тогда только появилось. Э говорю: "Я не знаю ни одного". Честно говорю, я не знаю. Меня спрашивают: "Ну, расскажи какой-нибудь пример, как ты что-то решаешь на рабо какое-нибудь интересное решение на работе, как ты как которое ты используешь каждый день для решения проблем своих". Я говорю: "Ну вот у меня есть, например, в продакшн код и есть тестовый код. Когда я гоняю тесты, мне нужно делать отдельные классы, которые я подключаю таким-то образом и прогоняю. Так, а когда мне в продакшене нужны, я подключаю другие классы, продакшн-классы, и они у меня работают." И таким образом у меня есть prodдакшн выполнение, есть тестовое. И мне говорят: "Спасибо, ты рассказал нам только что Dependency Injection". Я о первый, первый шаблонный паттерн программирования, который я узнал, хотя я его использовал, в принципе. Я его использовал каждый день. Я просто не знал названия. Я его использовал очень много. И опять же, если вот вернуться к книжке, книжка же ж не изобрела ничего нового. Уже до появления книжки Синглтон существовал, например. Тот же Синглтон существовал. Просто книжка сказала: "О'кей, вот есть Синлтон, вот он используется для таких вот задач". Мы используем его так. И вот там вам название. Используйте это название. Про Dependн ещё хотел такую штуку сказать, но по факту его реализовывать-то никогда и не нужно. Оно есть тебе как как бы дано, как правило, с базовым фреймворком или платформой, которую ты используешь, да, в дотнете. Или, например, если ты джависта, у тебя Springбot, там это просто вот на это надо против, знаешь, я называю это писать против ветра. Если ты работаешь в этих системах и не используешь dependency injection, на тебя будут смотреть коса. Но это уже является прямо такой типа как вот знаешь, как Git не использовать. То есть это уже на уровне вот ты должен так учиться даже, правильно? Ой, про гид я бы тоже поспорил бы очень сильно, но отчасти согласен, да, поэтому, наверное, я и выделил его, потому что без него в C#ARP, в котором я работаю, без depend, но просто никуда. Если в Goём, вот я Go недавно только начал изучать, для меня это что-то новое, интересное, но я там ничего такого вот пока ещё не увидел, чтобы мне сказали: "Ты должен обязательно его использовать в Питоне". Да, можно его использовать, но сколько я кода вижу, где даже не пытаются вот как-то абстрагироваться вот такими вещами, где просто всё в одном модуле и нету такого для cшаarпа и для Java, насколько я знаю, Java, я Java не эксперт, для cшарпа - это основа просто, без которой жить в наше время невозможно. Ну, они одинаковые в этом плане, да. Единственное, знаешь, хотел просто одно уточнение. Вот когда сказал, что у меня в девелопменте одно, в тестах другое, да, но я бы сказал в первую очередь, что ты полиморфизм использовал. А вот потому что полиморфизм можно использовать вот в зависимости от этой ситуации вообще в любом языке практически без проблем. А вот реализуешь ли ты его ещё посредством dependency- это уже следующий вопрос. Или у тебя там сразу было реализован dependency? Вот за счёт dependency было dependency injection в зависимости от того, как, например, email в когда мне нужно было отправлять email в prodдак, я отправляю реальный email и классу через dependency injection подключается класс для отправки и реальных имейлов, а во время тестов класса подключается через depend,

но только для тестов. Угу. Я понимаю, да. Ты ты исходишь из того, что у тебя как бы обязательно там контейнер есть. Просто бывает системы, в которых контейнера изначально нет, вокруг которого это строится, но это реализовано, скажем так, вот, знаешь, вот, как ты правильно сказал, там нету этого всеобъемлющего, но есть как бы на уровне конкретных элементов, что вот конкретно эта штука подменяется. Вот я скорее что имею в виду. Но это вот как раз вот другие языки, не Java и не C-#P, где обычно нету вот не построено всё вокруг контейнера, да. И у меня как раз-таки контейнера не было, потому что мы это сделали ещё, когда вот как раз-таки Dependcy Injection только появлялась, и мы сделали самописное, можно сказать, самописное. У нас это потом уже, когда я познакомился, узнал о том, что есть dependent injection, я пошёл уже, а гуглить после каждого интервью я обязательно чему-то учусь. Интервью - это хорошая вещь, поучиться чему-то нового узнать. Я узнал новое слово dependш. Пошёл. О'кей. Что ж я такое узнал на собеседование? Познакомился, узнал о паттернах, начал туда больше копать. И вот это мой драйвер был, первый паттерн, с которым я познакомился, с чего я вошёл и начал любить эту тему. А как ты видишь их вот в коде? Потому что часто же так, э в па про паттерны, когда говорят, происходит следующая ситуация. Обычно люди, которые только начинают ими увлекаться, я через это проходил тоже вот много-много лет назад, а когда ты такой сначала думаешь: "Блин, это такая классная штука, и я такой ищу, куда её воткнуть". А потом уже с течение времени, когда ты более-менее успокоился, начал понимать, ты просто видишь задачу. Хотя, кстати, в книжках это написано, да, что цель такая-то, но обычно это не читают или, по крайней мере, не до конца осознают, да, и начинают просто: "О, куда мне тут воткнуть композицию, шаблонный метод там или ещё что-нибудь?" А потом в течение времени ты начинаешь понимать, есть некий типовой круг задач, и вот оно туда подходит очень хорошим образом. Вот как ты определяешь, например, опять же, может, какой-то кейс конкретный, потому что для меня самый, я просто приведу пример, самый, наверное, тупой, самый распространённый паттерн вот, который бы я назвал, который вот просто со всеми нами везде на каждом шагу. Это стратегия, когда у тебя просто есть несколько вариантов расчёта, да, и тебе нужно подмену сделать. А вот гарантирую, что любого программиста спроси, он скажет: "Да у меня 100". Ну, у меня это было вот тут, вот тут, вот тут. И очень часто он скажет: "Вот тут свиtch просто был, тут Ивчик, а тут действительно я там классы навтыкал, потому что мне полиморфное поведение было нужно или мне нужно было динамически добавлять поведение, да, через конфигурацию". Это такое тоже бывает. Но обычно в продуктах, которые отчуждаемые, что ты не можешь в исходник залезть, там типа плагин какой-нибуд в виде классика дописал, да, и у тебя появляется какое-то дополнительное поведение. Вот как ты, э, распознаёшь эти штуки? У тебя есть такой паттерн, определение паттернов, я бы так это назвал. Я сейчас скажу такое противное слово, опыт, который все часто сравнивают с годами, а я сравниваю с количеством написанного кода. Я пишу очень, писал раньше очень много кода, сейчас как стал менеджером, только для себя что-то делаю, какие-то ппроекты, что-то постоянно изучаю, что-то делаю. А раньше я писал, ну, реально очень много кода. И через боль до этого доходил. И очень часто приходилось делать рефакторинг просто потому, что я вот написал плохой код, а потом понимаю, что да, это мне не работает, он нерасширяемый. Здесь я столкнулся с тем, что у меня невозможно расширяться, нужно превращать всё это в фак факторе. Э нужно как-то абстрагироваться. Начинал переписывать. Через боль дошёл до этого. А сейчас сейчас тоже я не могу сказать, что я определяю, где какой паттерн мне необходим. Что? Нужно ли здесь использовать, например, ту же фактори или можно просто создать класс? А нужно ли использовать какие-нибудь абстракции? Нет. А тоже через иногда через рефакторинг. И начинаю писать как можно проще всегда и делаю рефакторинг. Я очень много рефактори кода. Я очень я начинаю всегда с самого простого вот реализации. Вот я вижу, что там нужно реализовать в лоб реализовываю, потом рефакторию, опять реализовываю и reфакторию. Это как тест driven developмен, когда нам говорят: "Написал, а тестировал". Написал, а тестировал. Я не тестирую так много, к сожалению, хотя считаю тесты хорошая вещь, особенно когда работал на банковской. Без тестов невозможно работать. Э там спать невозможно, пока ты не не убедишься, что у тебя всё доллар к доллару подошёл. Но всё равно я тестов не так много пишу, но рефактор у меня кодрефакторин. Код reфакторин. И вот когда рефакторы вот тогда как раз-таки написал, увидел боль. О'кей, здесь у меня боль, надо как-то решить, и тогда уже смотрю, как что лучше заработает в этом случае. А это всегда очень интересный вопрос определить, типа вот когда говоришь расширяемость, это какая-то объективная проблема или необъективная? Потому что критериев нет, да? И очень часто люди вроде говорят об одном и том же, ты потом смотришь код и понимаешь, что, например, кто-то себе выдумал проблему, у кого-то он не в ту сторону подумал. То есть много нюансов. И в этом плане, а меня, например, всегда знаешь, что пугало? что слишком сильное увлечение вот этими штуками, когда у тебя вот такой вот гибкость, расширяемость, на самом деле может приводить к усложнению кода, потому что если у тебя весь код становится расширяемый, он становится слишком абстрактный. И вот эта вот граница - это большой вопрос. Нет, нигде не написано, где эта граница. Это каждый через свою собственную боль и пинки от коллег программистов начинает понимать, если начинает. Абсолютно согласен. Наверное, поэтому, если кто-то посмотрит на мой код, у меня, скорее всего, скажут, что у меня недостаточно абстракции, потому что опять же я начинаю писать вот практически влоб, а потом абстрагируюсь. И не факт, что я всегда это сделаю. Очень часто код может остаться. Я просто о'кей, я это исправлю потом. И если мне никогда не надо тро тронуть этот код, он может остаться таким же плоским и абсолютно безвкусным только потому, что, ну, работает и отлично, и мне никогда его не натролит. А вот если мне верн придётся вернуться к плоскому коду и я увижу, что да, он для меня плоский, он меня ограничивает, вот пора уже расшириться, что-то сделать, какие-то аэ вещи использовать, паттерны, абстракции, я не знаю, неважно. А вот тогда я уже делю. Так что у меня оринжениринг очень редко бывает. Я изначально стараюсь не прыгать в какие-то там сложности, не выдумываю для себя проблемы. Ну да, при этом ведь не все согласны с тезисом, что гибкость может приводить к сложности. То есть есть действительно мнение, что а код должен быть максимально гибким. Если не гибкий, значит он плохой код. Я вот, например, вижу не так. Я вижу, что если ты переходишь определённую границу гибкости, то код начинает утопать в сложных взаимосвязях. Ты с этим согласен или нет? Опять же ж, вот тут твоё хорошее в начале, что нужна быть, нужен быть конкретный пример, должен быть реально конкретный пример. Мы должны разбирать на хорошие вещи. Например, если посмотреть на мой сайт flenov.ru, где одна страница, вот одна буквально страница, там не используется никакого фреймворка, если посмотреть на код, там просто phpпишный файл и всё прямо в стиле девяностых годов. Там ноль фреймворка, потому что это одна страница. Там больше ничего нету. Если там кликать не на что. А если взять мой другой сайт флев. Там уже у меня и блог, и статьи, там у меня много чего интересного, и ссылки на книги на мои, там можно комментарии оставлять, писать мне. Там много функционала. Вот там уже используется фреймворк. Такое написать на PHP в стиле девяностых годов я себе не позволю никогда в жизни. А на чём он написан? Он на Симфоне. Написан. На Symphony? Да. PHP Symphony. Угу. Интересно, ты не рассматривал взять что-нибудь типа Тильды? И вообще ничего не писать. Нет, потому что я всегда на чём-то пишу, чтобы пробовать. У меня некоторые мои сайты были написаны на C#P в де не в 2000ных годах. Где-то в 2009, в 2010 году я создал на C#шарпе блог. Блог на C#шарпе. Это самоубийство. Я понял, что я вот это окиillл, это overgenниринг. Для простого блога использовать C#P глупо. Но я сделал это для того, чтобы учиться, чтобы что-то пробовать. и очередной раз набивать себе руку и практиковаться. Я писал очень много кода и ноу код технологии не использовал никогда, потому что потому что люблю писать и люблю создавать сам. Кстати, интересно, а вот можешь чуть больше раскрыть эту мысль? Это самоубийство, хотя казалось бы, там немного функционало, а в чём конкретно оно проявлялось? То есть чем так C#ARP был недостаточно выразителен, чтобы это сделать? Тогда даже MVC не было. Тогда были Webforms. И, во-первых, это было Webforms. Во-вторых, хостинг дороже был. И нужно было платить за Microsoft SK серверный хостик, который опять же очень дорого, очень дорого. Я использовал Microsoft SQL Server аnet. И это было проблемно, короче. Что просто минимальный сетап, да, сделать, это уже, блин. А это был блок. Это был просто блок, да. Тебе нужно конфигуровать, идти в iOS конфигурировать и поддерживать Webforms code. Ну он недаром умер. Он не зря умер. Это была ошибка со стороны Microsoft попытаться сделать десктопное программирование в вебе на бэкэнде. Я понял. Да, я понял. И это умерло. Я помню этот подход. Да, да, это оказалось действительно нерабочий подход. Сейчас это, кстати, так или иначе переизобретается в виде реаксерванных компонентов. Да, да, но это уже, конечно, немножко на других рельсах и под другим соусом, но концептуально всё равно пытаются делать как бкэнд, так чтобы можно было с этим нормально работать. Декларативное описание. Шарпе делают pages, когда ты можешь прямо вот тоже опять же C#ARP и этот Blazer код и HTML Blazer C#P всё это всё это на одной странице в одном коде. И я, когда открываю, у меня такое ощущение, что я вернулся в девяностые, когда вот опять же PHP вместе с HTMLм, с джаваскриптом, всё это в одном файле, в огромном. Ну да, чуть чуть больше флексибити. Сейчас сейчас всё-таки это фреймвор он добавляет там Pesсё-таки намного лучше, чем PHP девяностых годов без фреймворка. Намного лучше. Но всё равно, я смотрю, всё время народ пытается вернуться к этому, к одностраничникам, мне кажется. Просто пытаются решить проблему как раз-таки вот одностраничников, когда вот фленоф.ru Мне не нужен фреймворк, мне не нужны мерседесы, там мне нужен просто какой-то способ отобразить какую-то одну страницу. Там вообще HTML джаваскрипта достаточно, реально. Там PHP только, а я не помню, для чего у меня там PHP, но я точно помню, что у меня PHP файл. Я это создал э сколько-то лет назад, я уже не помню. Но мы ушли от паттернов. Но очень интересно очень. Да, да, да. Не, вообще, кстати, это отдельно большая тема. Я там периодически, у меня такое бывают подкасты, когда мы именно копаем в древние всякие штуки. И вот просто как такой пример. Тут год что ли назад кто-то, значит, конференция, там показывают NextGS, который вот там, значит, во фронтнде, и там прямо показывают, как внутри компонента реактовского ты SQL запрос пишешь, и они такие: "Вот достижения". И там народ в комментариях просто усывался, потому что говорит: "Ребят, вы же там всю жизнь рассказывали и глумились над ппэшниками, что они там запросы делают в htмле. Да, я говорю, вы вы вернулись к этому, да? Ну, понятно, что там есть, конечно, определённые отличия, но всё равно это довольно забавно наблюдать, когда ты через это прошёл. Так, о'кей. А, а по поводу паттернов вот окиillно не окиillл, я просто пример скажу банальный. Та же самая мм стратегия, когда ты просто можно ификами что-то разрулить, да, и часто бывает действительно ифики - это нормально, потому что гибкость тут, ну, целые там плодить классы под полиморфное поведение- это ещё большой вопрос. Я даже как-то рассказывал, у меня был кейс, знаешь, когда вот я прямо расскажу этот кейс, он интересен. Значит, у чуваков это было на собесе. Мне рассказал на собеседовании парень, как они решали одну задачу. Он рассказывал про доставку почты международной. Там есть старый протокол, который до сих пор работает. То есть ты хочешь посылку доставить куда-то в другое место. У тебя должен быть какой-то специальный файлик, в котором вот эти данные доставки зашифрованы определённым алгоритмом, и ты его по FTP куда-то кладёшь. Можешь себе представить? Это сейчас работающая типа система. Ну и кто-то там это считывает и, соответственно, поэтому что-то понимает. Так вот, зашифрован он может быть одним из пяти алгоритмов, который кодируется в начале этого файла текстового, по-моему. Ну и как бы человек, который с этим сем знаком, сразу понимает: "О, у тебя пять разных алгоритмов, соответственно, ты выбираешь его". Это, причём неважно, это стратегия по смыслу, это не стратегия по паттерну, да? То есть я имею в виду, что там тебе надо прямо классы городить и так далее. Если это задача в одном месте, ну, сделай это в одном файле, да, и всё, она скрытая, она как бы такая как бы абстракция не течёт, что называется, да. Так вот, ладно бы они там сделали пять классов и вообще целую систему построили, я бы ещё понял, ну, потому что можно как-то это объяснить, там мало ли новые типы добавляю, все дела. Они пять микросервисов сделали. То есть у них, грубо говоря, каждый тип алгоритма расшифровывался микросервисом. И суммарно, по-моему, там было семь микросервисов. Один считывал, дальше он распределял это по одному из пяти, то есть по микросервису на каждый алгоритм. И в конце какой-то там, который это собирал и уже куда-то дальше передавал. Вот это я называю овеженирингом. Ты вначале сказал хорошую вещь. Опять же, ты из-за опыта сразу же у тебя пять возможных алгоритмов. Ты сразу же, о'кей, если у меня пять, что я могу использовать в этот момент, когда у тебя один шифрование, а ты о'кей, я напишу, как как попало. Два уже начнёшь думать, а стоит ли мне что-то добавлять. Когда три, ты уже всё, 100%. Мне надо стратегию уже, всё, дальше без стратегии невозможно. И вот точно так же и я пишу. Я начинаю, если у меня один, о'кей, написал сплошняком. Да. Слушай, а как ты относишься к производительности? У меня был как-то разбор доклада Егора Бугаенко, где он как раз рассказывал, почему зафейлилось оп. Ну он как бы там объяснял, что, например, там память сейчас уже её много, что те проблемы производительности, которые мы описывали, ну да, там где-то есть, но в целом типа сейчас это небольшая проблема чаще всего. Как ты вообще к этому относишься, что эти вещи, ну, дают нехилые накладные расходы? В том числе Dependy Injection. Это же такая рантаймовая штука с рефлексией, да? Это не с не даётся нам бесплатно. Тот же ООП не даётся нам бесплатно, стратегия не даётся нам бесплатно. Если мы захард-кодим, всё намного быстрее будет работать. Но если сравнить накладные расходы на тот же даже на самый дорогой паттерн, я даже не могу представить себе, какие расходы могут быть, чтобы думать об этом. Тогда зачем мы вообще пишем на Питоне, который самый медленный? И все прекрасно знают, что написать на любом дру Ну ладно, любой, я, наверное, сейчас меня накидают в комментариях, но на большинстве других языков, если написать, это будет намного быстрее, чем Python. Мы пишем на Python, потому что это создаёт нам удобство. Мы быстрее пишем, мы решаем наши задачи, мы достигаем того, что нам необходимо. Точно также и с паттернами, если они нам дают удобство, если они решают нашу проблему поддержки кода в будущем, но тормозят выполнение, да, чёрт с ним, выполнение, стоимость выполнения кода сейчас намного дешевле, чем стоимость разработки, даже несмотря на яишку, которая ускоряет разработку. разработка дороже, чем выполнение. Ну, мы сейчас, кстати, тоже об этом поговорим. Я хотел одну вещь сказать, которую я помню. Может, уже сейчас это не так, но просто скажу, да, я знаю, что в Сишарпе в Геймдеве под, господи, как его зовут-то? Unти. Unнити, да, я слышал это много лет назад, может быть, сейчас всё не так. Там прямо были рекомендации, что нужно только статикой пользоваться, чтобы, не дай бог, там у тебя вот эти вот все виртуальные методы и, соответственно, вот эта фигня не происходила. Это не так. Сейчас создание объектов, проблемы. Я в Юнити не эксперт, но нет, наоборот, за такие вещи за статику по рукам надают. Там статика очень это такой самый дешёвый способ коммуникации между объектами. Самый дешёвый, но самый ужасный. И нет, я такой рекомендации ни разу не слышал. Ни раньше, ни сейчас. Ну, это это в тех местах, где у тебя просто гигантское количество создания мелких объектов. И, соответственно, особенно если у тебя стейта нет там я точно слышал, что такие рекомендации для повышения производительности были. Конечно же, ценой того, что лишается всё то, о чём мы с тобой говорили, у тебя по сути, ну, совершенно другой подход по разработке, мягко говоря, неодобряемый. Повторюсь, я в Юнити не эксперт. Возможно, потому что UnЮнити - это достаточно специфичная вещь - это геймф. В геймдеве тебе нужна производительность. И, э, в геймдейве ты не можешь так просто решить проблему масштабирования. Если у человека компьютер без игровой видеокарты, то он просто не сможет играть. Ты не можешь сказать: "Пойди, купи видеокарту и будешь играть". Он не купит просто игру. И там придётся, когда это я в основном веб-программирования, 90% моего веб и, может быть, 10% я немножечко занимаюсь игрушками там на Юнити. И и надо бывает для себя что-то делаю, на Свифте игрушки делаю для себя, но веб, где масштабирование железом спокойно решается, и не надо заставлять пользователя купить себе последний MacBook на M5 для того, чтобы запустить себе браузер, я надеюсь и можно серверами всё это подправить, масштабировать серверами. Там выполнение дешевле всё-таки. Я говорю, а именно вот вепрограммировании не не могу прямо не пожаловаться. Ты может быть слышал на маках после? Я не знаю, это у тебя маг, наверное, тоже. Да, у меня 2. Да, у меня тоже 2 сейчас. А гт глаз, да, появился. Так вот, как только этот глаз заехал ко мне, ну, я имеду новый интерфейс, новой этой системы, у меня тормозить начало везде. То есть я, когда на Айфоне просто тупо в список контактов перехожу, там задержка почти секунду просто перед тем, как свичится один экран на другой. Это не я один. Я смотрел, что люди там пишут. Там очень многие, конечно, очень расстроены тем, что происходит. А он действительно по энергопотреблению и вообще ресурсам на то, чтобы вот эту красоту показывать, э, ай-ай-ай. Я могу поверить, что это ещё с чем-то связано. У меня, по-моему, пятнадцатый iPhone. Но, в общем, так к слову, что есть, короче, тормоза. Да, есть тормоза. Я их чувствую. Я пошёл проверить, потому что я не помню, какой у меня. А у меня пятнадцатый тоже. Я же проверил, какой у меня. Вроде, вроде недавно покупал. Вот я реально, мне плевать, какой у меня телефон, потому что я только звоню и особо им не пользую. Короче, там какие-то переходы начинают реально подтормаживать. То есть раньше они были моментальные, а сейчас ты чувствуешь задержку. В общем, короче, что-то там они напрограммировали. Это интересно. А сейчас интернет весь завален вопросиками к ним, что они будут делать дальше с этим. Там не всем понравилось, скажем. На айпаде скажу. Да, я заметил, у меня он начал больше лагать, но у меня прошка 2 2020, кажется, пандемии его покупал. Пусть и прошка, но всё равно уже пятилетней давности про Да, лагает. Вот на прошке скажу, лагает. На телефоне я говорю, я практически не пользуюсь им. Угу. Надо поспрашивать, что они там пишут. Хорошо. Допустим, человек решил изучить паттерны. Есть ли какой-то список, который можно было бы порекомендовать или подход к изучению, или книжку для изучения, вот что-то, потому что получается, что банда четырёх в каком-то смысле, ну, всё-таки подустарела, да, а чтобы в чистом виде только на неё ориентироваться. А что сейчас-то делать, если прямо совсем начинать? Как бы это банально не было, я бы посоветовал Head First. Я не знаю, как она по-русски называется. Есть такая серия Head First, прямо совсем для начинающих, где очень много рисунков. Очень много рисунков. и синенькая такая, да, там я её выкинул, потому что я её покупал для дочки и сына, когда они только начинали учиться. Но я её всё равно прочитал, и мне она очень понравилась. И понравилась тем, что как раз-таки они очень много заходят, не они они всегда заходят не сразу же к паттерну. Вот вам паттерн, вы должны его использовать, а они сначала описывают проблему. Очень много как раз-таки есть жизненная проблема. Вот у нас есть проблема, мы пишем код. Если мы напишем так, то будет плохо, а если мы напишем так, то будет намного лучше. И понимая вот как раз-таки проблему, какая может быть у программиста проблема, он может решить её. И как раз-таки это может помочь потом с определением, когда какой паттерн использовать. Она очень банальная, но там очень простые паттерны, самые основные, типа фабрики, Сенлтон, стратегия, э, дай мне бог памяти, что там ещё может быть, я не помню. Они основные там. Я готов поспорить, что там что-нибудь типа композиции какого-нибудь прокси. Это вот такие типовые вещи, которые всегда встречаются. Прокси. Именно прокси нет, но опять же, дай мне бог памяти, когда мы обёртку делаем. Сейчас я открою, посмотрю. 95 баксов канадских стоит эта книга, кстати. Да, я что-то тоже видел, что подорожали очень сильно все книжки. Но она, даже несмотря на то, что она по Java, там все примеры на Java, я C#arptник без проблем её почитал, с удовольствием прочитал в своё время. И, а, deкоратор factory singleton, command template method, в принципе база. В принципе база, которой мы сталкиваемся каждый день. Шаблонный метод очень часто. А, прокси есть. О'кей, прокси есть. Command Pattern. Команда тоже, кстати, очень даже популярный паттерн. Я его, в принципе, вижу. Хотя я не так часто сам использую. Ну, кстати, тут есть ещё интересный вопрос, связанный с этим. Знаешь, как часто говорят, и это, я отчасти согласен с этим, о том, что часть паттернов - это попытка выразить что-то в языке, который не позволяет это сделать какими-то другими выразительными средствами. Команда - хороший пример. Это не означает, что команда совсем не нужна, но, например, почему в языке, который у тебя весь в интерфейсах, этого слова никто не знает? Я имею в виду, вот если ты берёшь, э, фронтEN, да, у тебя там же по сути всё есть команда, так-то уж по-хорошему. Вот эти лиснеры, которые ты вешаешь на кнопочку, которая там что-то выполняет, просто потому что когда этот паттерн описывался в Джаве в первую очередь, да, или, кстати, они на плюсах, я, кстати, забыл, они, по-моему, на плюсах, да, показывали примеры или на Джаве. Ну, это неважно. Важно, что тогда лямп-то не было по сути в этих языках. И получается, что, грубо говоря, когда люди в современных языках часто про это читают, они немножко недоумевают, потому что ты в даже в современной Джаве часто у тебя, а, команда как класс с экзекьютом заменяется просто на лямбду. Опять же, есть места, где это нужно именно в таком виде, но очень много, где это, а, просто лямдочка, которую ты в лист нар передаёшь, и дальше он делает действие, которые тебе нужно. Я просто к тому, что насколько часто ты это видишь, что всё-таки паттерны - это прямо фундаментальное решение какой-то задачи, которое просто является программистской задачей. И паттерн - это обход ограничений дизайна твоего языка, если ты так смотрел на этот вопрос. Это и то, и то. Это и то, и то. Иногда это бывает реально обход ограничений. Тут я могу вспомнить книгу. Я как-то читал книгу, когда я, я помню ехал на поезде в Москву по это в этот в посольство Канады, как раз-таки, когда я только планировал уехать в Канаду и читал книгу какую-то парифакторингою, я не помню, ну, знаменитого автора, вот сейчас не помню названия, точно помню автора любитель писать. Возможно, и он там говорил, что вы должны писать не с помощью, не на языке, а с помощью языка. Если что-то нет в языке, вы должны это изобрести и вы должны это создать. И как раз-таки вот это может быть вот как раз-таки ответом на твой вопрос решение. А с другой стороны, например, классический пример с Джаваскриптом. Сколько человек ненавидели прототипа в Джаваскрипте, а потом раз и появляется паттерн, прототип. Оказывается, можно назвать это паттерном и использовать. Просто паттерн говорит, когда мы должны это использовать, что действительно в нём есть преимущество, что прототип, когда мы не наследуем, а копируем, копируем объекты и наделяем их новым функционалам, это действительно может быть хорошо использоваться для каких-то решений вещей. И появился паттерн, прототип, он стал паттерном. Кстати, как ни странно, JavaScript, вот когда я его активно учил и преподавал прототипы, это было одно из ключевых знаний, которая должно, ну, сопровождал обучение, потому что без прототипов как ты мог пользоваться джаваскриптом? Современные джаваскрипты, его использования настолько далеко от этого ушли, что я, честно говоря, вообще сомневаюсь, что программисты, которые вот за последние, допустим, 7 лет научились, ну, стали фронтендерами, вообще представляют себе, как оно там работает. А я даже не удивлюсь, если многие не в курсе, что там внутри какие-то прототипы есть. Настолько это стало сейчас неактуально. Ребят, кстати, напишите об этом, пожалуйста, в комментариях, потому что супер интересно. Но я вообще этого слова от людей, связанных вот с разработкой на фронтде, не слышал много-много лет, чтобы хоть что-то кто-то об этом говорил. А раньше вообще все библиотеки, если ты знаешь, помнишь, даже был протопpe JZ, они строились как бы через патчинг прототипов. Но в какой-то момент все поняли, что это очень плохая идея, потому что, особенно, когда у тебя пришли типы нормальные, это стало полной жестью, потому что ты просто, ну, как бы меняешь ядерные, так сказать, функциональность. У тебя там появляется новое поведение на, казалось бы, стандартных вещах. И как бы как с этим жить вообще непонятно. То есть неожиданное поведение в разных местах, изменение глобального стейта там и так далее. В общем, всякие весёлые сюрпризы. Поэтому все современные либо они просто как бы как функции существуют. Ну, паттерн, прототип чуть-чуть отличается от паттерна, от реализации прототипа в JavaSриpt, да, это цепочка там, да, немножко разные вещи, да. Паттерн, прототип - это когда ты к клонируешь, клонируешь себе, не наследуешь, а клонируешь, и получается у тебя прототип, который ты куча объектов себе получают, и каждый объект будет, как бы он клонировал себе часть, но оригинал-то, оригинал, если ты его попашь, клон останется клоном. С портативы вообще интересны, несмотря на то, что когда я тоже читал про этот паттерн, если вот так вот посидеть и подумать: "А где я в жизни это реально использовал? Это стало популярным?" Как будто нигде. То есть мне кажется, это осталось какой-то плюс-минус теоретической конструкции. Нет, возможно, да, возможно, потому что это прямо такой узконаправленный паттерн, когда тебе это нужно, да. Но вот интересно, дай прямо пару слов про разные паттерны, которые 100% э очень важны, даже не с точки зрения прямо имплементации, потому что, кстати, вот тоже хочется сказать, да, когда мы берём с тобой книжку, там же прямо конкретно нарисована картинка. Очевидным образом она неприменима ко всем языкам, потому что у тебя в разных языках очень по-разному некоторые вещи делаются, но концепция это никуда не девается, потому что та же самая, как мы говорили, там, стратегия - это смысл, это не имплементация, да, и можно по-разному, но ты понимаешь, что это стратегия. Знаешь, какая, я не могу не назвать штуку, которая есть вообще везде, особенно сейчас это визитор, потому что весь инструментарий наш, который там лспишка, линтеры, всякие преобразователи и так далее, что они делают? Они строят деревья, по которым, соответственно, ходят и, соответственно, там что-то смотрят и делают. И вот этот обход, он всегда делается через какого-то визитора. Да, у тебя есть некая общая функция, которая знает, как обходить, но ты, когда хочешь обойти дерево, тебе не надо писать этот алгоритм обхода. Всё, что тебе надо - это передать, ну, допустим, в простейшем случае колбк, который просто перенимает на вход ноду, а тебе просто по очереди передают ноды всего дерева в каком-то там порядке. Вот, например, я, знаешь, где очень часто с этим сталкиваюсь и как бы опять же зная паттерна, такой: "Ага, это понятно, посетитель", да, он называется визатор рендеринг маркдауна, как это ни странно. То есть вот у меня много на фронтде рендеринга маркдауна, когда определённые ноды надо обрабатывать прямо сильно определённым образом. Например, кастомные директивы. То есть, знаешь, вот, да, простейшая задача у тебя в блоге есть. Вот блог, ты же, наверное, видел, что часто вот там раз там идёт абзац, два, потом херакс, вставка какая-то, да? Угу. А текст-то на Маркдауне написан и статей, допустим, тысячи. Вот как это делать? Ты же заколебёшься, если ты будешь ходить и везде прямо этот блок вставлять. Это, во-первых, динамики нет. Во-вторых, это просто геморрой. А если ты что-то поменял, заставлять переписывать все статьи, это полная [ __ ] Как мы, например, это делаем? То есть, например, во фронт-энде есть липки, там, ну, их много, да, для маркдауна. И у них есть, например, такая штука, которая называется кастомные директивы. То есть там есть прямо синтаксис определён, например, двоеточие, двоеточие и название. Это прямо как некая директива Маркдауна. То есть ты таким образом его расширяешь. И дальше, когда ты, а, работаешь с рендерером, рендерер - это штука, которая, собственно, его рендерит, да, у неё есть прямо такая опция, как задать кастомные директивы. И ты говоришь ей: "Я хочу вот такую директиву". Ну, вот двоеточие, двоеточие, например, каталог мы её называем, да? И в этот момент он, когда её встречает, он вызывает тот колбэк, который ты ему передаёшь. А в этом калбэке как бы ты принимаешь на вход саму эту директиву, потому что там опции ещё можно задать, и возвращаешь любую херню, которую ты хочешь. И мы можем отрисовать там каталог. Ну, в нашем случае это курсы, да? Мы знаем, что это за статья, и мы подставляем, например, курсы, которые соответствуют этой статьи. Простое решение, понятное решение, классное решение, универсальное решение. Вот в этом случае паттерн имеет значение, но он, знаешь, как имеет значение? Тебе-то самому это реализовывать не надо, а концепт понимать надо для того, чтобы знать, как это примерно работает. Ты знаешь, самый популярный паттерн, наверное, который все используют и даже не обращают внимания, что это паттерн - это итератор. Потому что for each, когда мы используем, это уже паттерн итератора. А до ича мы его, ну, ещё в C++ там, в C#P, э, хотя в C#P сразу же Forge появится. В C++се, в C был просто for, for while и do while, а потом for each появился. И вот как раз-таки итератором мы можем итерировать всё, что угодно. И это, наверное, самыйсамый, ну, с итератором там связано именно понимание вот именно запоминания текущей позиции, потому что у тебя там раньше с этим проблема была, да, но это при условисовести ты с этим стался. Как он внутри работает? Это понимание, как оно внутри работает. For это просто next, next, next, next, пока ты не дойдёшь до конца. И ты можешь итерировать всё, что угодно, не обязательно массив. Можешь получать откуда-то данные из сети там и закидывать их тут же forage. А итератор может по-разному, но просто самый, мне кажется, на фарче просто это незаметно, потому что он, грубо говоря, одинаково работает плюс-минус. Ну то есть это обычно даже скрыто часто от тебя бывает, даже если ты как будто массив обходишь. Я имею в виду, что вот если ты, например, создаёшь итератор и делаешь его через while, то тут разницу ты прямо видишь, потому что если ты делаешь обход по массиву, то тебе надо запоминать текущую позицию, то в итераторе тебе не нужно запоминать текущую позицию. В этом как бы и смысл, что итератор запоминает позицию. Но кроме того, итератор же ещё что позволяет. Опять же, почему это не всегда очевидно, не все работают с бесконечными коллекциями, но это уже ближе к генераторам, да, когда у тебя фактически итератор же может возвращать, превратиться в генератор и возвращать коллекцию динамически. То есть, когда она генерируется в процессе. Вот, кстати, ну, может быть, я тут не прав. Может быть, тут только с генераторами сработает, потому что как ты каунт тогда посчитаешь? Надо подумать. Нет, а тебе каунт не нужен. Итератору не нужен каунт. У него только два метода. Каунт не является частью итератора. Нет, у него даже вообще next. Итератор даже, кажется, вообще только next. Да. Next. Current. Current. Next. И может быть всё, да? Countable - это не его. Да. А 100 лет я его не видел уже. Итераator C#P Next Cent - это точно. Да, вот countable, по-моему, может быть, ты прав. Это отдельно идёт. Он ему не нужен, да? Ну, он ему не нужен, да? Просто я не помню, он входит обычно в него или нет. Нет, блин, у меня не открывается. На на рабочем компьютере хотел открыть этот. У меня тут очень много ограничений. Смотри, относишь ты вот есть паттерны такого уровня, которые мы с тобой рассматриваем, а есть паттерн, например, MVC. MVC также как Deppendcy Injection - это довольно большая ведь вещь, которая очень сильно влияет на организацию кода, но он настолько фундаментален с точки зрения того, что интегрирован просто абсолютно во все фреймворки, что как бы знание MVC, как помнишь когда-то, там надо знать MVC, надо понимать тра-та-та, даже слов таких нет. Никто про это не говорит. При этом он никуда не делся. Просто он тебе сейчас обеспечивается инфраструктурой. И ты как бы, если специально не делаешь зла, то ты как бы работаешь в рамках этого паттерна. Даже если ты считаешь, что он не нужен в современном мире. Это, знаешь, примерно как эти вакцины, поскольку их все принимают, никто не болеет, и поэтому может кто-то считает, что они не нужны, но то, что у него есть, оно только потому, что все принимают вакцины. Вот для меня, мне это очень сильно напоминает эту историю. И видишь, получается, что часть паттернов уходит на инфраструктурный уровень, так же как dependenнcy в дотнете. Ну, если ты работаешь на C#ARP и Java, то, конечно же, без MVC я даже не представляю себе мало кто. Опять же в Сшарпе сейчас вводят pages, где можно всё в одно место засунуть и отказаться можно от Можно отказаться от MVC, но я не совсем понял вопроса. Что я считаю, а выделяю ли я этот паттерн как-то в отдельный? Нет. Да. Да. То есть ты считаешь, что это надо выделять и знать? Нет. Не считаешь так? Не не выделяю по сравнению с остальными, потому что, ну, для сишарпников это очень важно понимать, что они как писать код. Я тут хочу сказать, опять же, это тут может быть такая вещь, что из моего опыта мне писал паренёк один, говорит, говорит: "Миша, я не понимаю, как работает MVC". Я говорю: "Вот ты за мной повторяешь, делаешь вот такие вещи?" Он говорит: "Да, я делаю". Вот я создал контроллер, я создал там вьюшку, я создал там модель, но я не понимаю MVC. Я говорю: "Так, ты его уже используешь. Что тут понимать? Ты уже используешь". Очень мно много даже не задумываются о том, что они используются. Возвращаясь к к тому моменту, который мы уже чуть-чуть затронули, иишка, с иишкой как раз-таки немножечко подрастает необходимость понимания. Он уже тебе сгенерирует всё, а тебе нужно понимать, что да, мне нужен здесь MVC, да, здесь мне нужно разбросать это вот так вот, а дальше раскладывай мне. А важность понимания MVC чуть-чуть, наверное, в современном мире повышается. Это не не что-то, что ты можешь скопировать сок Overflow, если алгоритмы. Вот почему алгоритмы я не люблю, там, да, к ним можно относиться по-разному на интервью или ещё где-то. А как они показывают знания, они легко копируются с любого стекаflow. Сорт взял, скопировал себе всё один к одному. Скопировать MVC ты не можешь. Ты его должен понимать, чтобы использовать. Вот если ты его понимаешь, ты можешь использовать. Ты можешь сказать иишки, сказать чего-то, за написать ТЗ, написать задание. джуниором, программистом или ещё что-то, что сделает. Так, заметь, самое интересное с точки зрения обучения, это нигде не всплывает. То есть вот когда ты говоришь про книжки по паттернам или даже если банду брать, там вот эти вот очень локальные штуки, а как будто такой книжки, которая объясняет архитектурные штуки и нет, да? Или ты знаешь такое? Нет, не могу сказать такое. Не могу. Наверное, потому что, э, спроса нету. Моё мнение, как автора книг, который писал много книг, спроса меньше. Большинство покупает всё-таки по основам языка. Изучают основы языка, а дальше не движутся. Но основы языка - это ещё не ты не научился. Основы языка я вообще я с машиной люблю приводить пример. Это ты, например, познакомился, что в машине есть руль. Ты его покрутишь, да, колёса покрутятся, ты знаешь, где это ручка переключения передач. Если ты нажмёшь на педаль, то всё это вот книжка по основам, которая тебе покажет, что есть это циклы, ифы. переменные. Ты узнал, а как всём всем этим пользоваться вместе? Вот это паттер, как управлять машиной, что ты там нажимаешь сцепление, газ по чуть-чуть это подаёшь, скорость переключаешь. Вот это паттерны движения. И точно также в программировании знать основ недостаточно, знать циклов или условных операторов и переменных недостаточно. Нужно знать и уметь паттерны. а почему-то по ним меньше изучают, на мой взгляд, из моего опыта, опять же, проводя большое количество интервью в последнее время чуть меньше, к сожалению, текущая ситуация на рынке, но я проводил очень-очень много интервью. И, к сожалению, из паттернов, вот мой опыт, спрашиваешь: "Расскажи мне какой-нибудь паттерн". Все рассказывают Синлтон. Я знаю Синглтон сразу. О, я сейчас расскажу, что Синлтон - это объект, который существует в одном единственном экземпляре. Отлично. Как ты добиваешься того, чтобы он был в одном единственном? Как сделать так, чтобы его нельзя создавать инстанцы? Не знаю. Всё. И таких очень много, к сожалению, не понимают. А вот это понимание как раз-таки то, что ты не скопируешь сок Overflow. Но что ты можешь сказать? Ишки, ты меня, кстати, удивил, потому что я паттерна на собесах не спрашиваю, но в целом в моей картине мира до сих пор осталось, что, ну уж синглотон, что он там в статике GE instн хранится, это довольно такое, знаешь, базовое знание. И ты говоришь, что сейчас этого не знают. Это интересно, насколько уровень абстракции поднялся, что люди не вникают. Вот для них это уже детали, они в них уже не вникают. Нет, статик они понимают. Они говорят: "Ты берёшь статик в private, static и оно будет доступно". О'кей. А вот у тебя как ты сделаешь так, чтобы только ты мог напрямую privк экземпляр класса. Как ты можешь экземпляр класса защитить? Не знают. А экземпляр класса тоже privёшь privт конструктор и всё. Если прават конструктор, ты уже не можешь создавать экземпляры. Единственный способ обратиться к статичной переменной приватной через статичный метод getance какой-нибудь обычно называют. Тут можно, конечно, знаешь, так чисто в научном, так сказать, эксперименте сказать, что если рефлексию подключить, то тут, наверное, ещё можно что-нибудь обойти будет легко. Я просто не знаю, как в Сишарпе, но ты сам знаешь, во многих языках рефлексии позволяет тебе всякие чудеса делать, которые просто так нельзя. Ну, это так чисто, да, научный такой эксперимент, не более того. А, кстати, по поводу синглотонов. Действительно, мы что-то говорили, говорили, а про самый, так сказать, известный паттерн считаешь его паттерном или антипаттерном? Паттерном. Он может быть и тем и тем. Я его и тем, и тем считаю, потому что я видел, когда его используют паттерном, а когда я видел, когда его используют антипаттерном. Всё зависит от того, когда и как его используют. И у нас было, помню, прикол. Вот программист пришёл как-то в компанию, и он всё писал через Синглтона. Поддерживать это было нереально. Только потому, что Синглтон, да, он его его обоснование было то, что когда он создаёт синтон, объект в одном экземпляре в памяти. И для веба - это экономия. Не надо создавать новые экземпляры класса. У меня постоянно в памяти один и тот же. Но это создаёт другие проблемы. То есть, да, с точки зрения оптимизации его объяснение в принципе имеет смысл. Но с другой стороны, когда у тебя многопоточность и кто-то может мм что-то наделать в многопоточности, это может оказаться очень большим злом. То есть в каких-то случаях это действительно необходимо просто даже, например, для оптимизации памяти и сокращения количества обращений, например, к чему-то. Как кэш использовать можно, как кэш использовать. Варианты возможны, возможны, но я использую силн в крайних случаях, я бы так сказал. Вот в своём коде, когда я пишу что-то своё, это очень редко. А в C-#P есть такое вот как как опять же с точки зрения Dependency injection, ты можешь настроить свой контейнер, чтобы он возвращал тебе объекты как single, scoped или transentend. Singletлon он в одном экземпляре будет класс. Это если бизнес-логика, если чистый код, то норм создать. Вот такое норм создать. И силтон очень часто используется вот для таких вещей. И вот здесь я его использую очень много. Когда я пишу какие-нибудь свои библиотеки, свой код, я не помню, когда я последний раз использовал синтон. Вот именно вот для своего чего-то, для с точки зрение библиотек. Это самое последнее, наверное, к чему я обращаюсь. Ну, смотри, погоди. Разве в DI у тебя не обеспечивается это самим фреймворком? То есть, грубо говоря, это у тебя обычный объект, который нормально создаётся, просто за его лайфсайклом следит Dependency injection, он содаёт объект и даёт тебе один. То есть как такового синглотона там нет в плане глобальной переменной, если Ну он синглтон, нет, но там нет глобальной переменной. Вот просто для меня, наверное, вот это главное, потому что вот вот эта путаница есть. Типа просто через диайку управляем его жизненным циклом. И когда мы реально в обход диаййки по сути херачим глобальные переменные, которыми у тебя всегда, знаешь, это как вот раньше говорили: "Ну как же баз данных у тебя одна?" Ну, конечно, у тебя реплика на чтение, это на запись, у тебя обязательно в тестах подмена и так далее. То есть так не бывает. И это касается практически любой херни, которую когда-то все описывали даже в книжках, что, ну, смотрите, она у вас в одном экземпляре. Все абсолютно штуки оказываются в конечном итоге не в одном экземпляре. Вот сколько я не видел проектов, никогда такого не было. А даже если существует в одном экземпляре, нужно быть аккуратным, потому что опять же доступ, параллельный доступ может привести к проблемам. Как минимум при форках надо пересоздавать. Ну то есть у тебя всегда есть всякие штуки, которые нужно иметь возможность сделать, особенно а это бессмысленно, если у тебя диаййка, которая сама это разруливает. Типа зачем переть против ветра, что называется. Там, где это реально нужно- это паттерн. Но да, это может быть и антипаттерном, когда его суют там, где это не нужно. Кстати, хотел у тебя спросить, мы тут как-то обсуждали, ты знаешь раньше вот тоже был популярный список именно антипатронов, и там среди всех мой любимый был Паблик Морозов. Знаешь, такой это классный антипаттерн? Нет. Нет, не Паблик Морозов. Значит, как раньше люди подходили к вопросу, э, значит, любители юни-тестов хотят протестировать что-то закрытое. Как это сделать? Очень просто. Приват меняешь на протеed, наследуешься классом, в котором переопределяешь на паблик, и, соответственно, тестируешь паблик Морозов. Ага. Вот. Потому что приватные ты не можешь переопределить на паблик в наследниках в большинстве языков, а протекто ты можешь переопределить на паблик. Да, да, да, да, да. Их прямо десятки было. Ну я использовал рефлексию для тестов. Рефлексию использовал. Я такого ни разу не делал. Да, я тестировал рефлексии. Я в основном тестирую только паблики, но были у меня очень редкие случаи, когда мне приходилось тестировать прайваты, когда вот реально вот какой-то функционал в Прайвате есть и его желательно протестировать отдельно, тогда, да, рефлексию несколько раз использовал. А так, если у меня публичные методы возвращают всё, что мне необходимо, мне всё равно, что на что делают, если у них нету никакой там бизнес-логи, которую нужно как-то отдельно протестировать. Мне плевать. Главное, паблик работает так, как мне надо, и всё. Как ты смотришь на происходящее с Иишкой в плане паттернов в первую очередь? Э, нет ли ощущения, что всё это становится бессмысленным, потому что Ишка сама сделает, подскажет, такие тонкие знания на таком низком уровне просто будут неактуальны для программиста в ближайшее время? Я бы так сказал, она уже заменила алгоритмы. Первое, что она заменила - это алгоритмы, которые вот реально можно легко а сгенерировать, потому что это прямо совсем чёткие задачи. А с точки зрения паттернов она может помогать Ишка. Вот помогает, да, тот же MVC ты особо не заменишь. Тут реально она может помочь, а, ускорить разработку, сделать как можно проще и снизить накладные расходы на огромное количество раскла абстракций. Если кто-то любит их делать с самого начала абстракции, кто не любит рефакторинг, вот для них ишка - это отличная помощь. Для меня это как раз-таки опять же с точки зрения рефакторинга, это отлично. Рефакторинг. Я могу сказать: "О'кей, я хочу вот сделать так, мне вот так нравится, Ишка, помоги мне". и она мне переделает. Так что это отличный помощник, но не замена. Я не думаю, что замена. Это не за ишка, не замена программистов. Ишка не замена с точки зрения паттернов. А вот для алгоритмов это для таких вот для основных алгоритмов, которые мы используем каждый день - это замены. Мм, слишкой же интересная история. Она, как правило, копипастит. То есть вот когда ты говоришь про рефакторинг, это работает только в том случае, если ты чётко знаешь, что ты хочешь отрефакторить. А это, в свою очередь, означает, что ты всё-таки понимаешь проблематику, да, и ты говоришь: "Я хочу, например, обобщить, я хочу создать абстракцию". Сама по себе она тебе никогда в жизни её не предложит. Она увидит, как ты что-то делал, и продолжит делать то, как ты делал. Я не видел ни разу, чтобы она могла сама обобщать и думать: "О, смотри, у тебя тут повторяется код. Давай как бы выделим это в абстракцию". То есть как будто бы возникает наоборот ещё большее требование к тому, чтобы люди понимали смыслы, иначе у тебя весь код будет просто копипасты и сплошной. Что, кстати, вполне возможно устраивает гошников, потому что они не любят абстракции. Не устаю про это говорить. Да, я вот вот с этим я согласен. Это не конкретное решение. Большинство паттернов - это не конкретное решение. Это как нужно мыслить, как нужно рассуждать, вот я бы так сказал, а не конкретно вот прямо один к одному решению, которое вот всегда работает именно так. Тот же фактори можно факторим этот можно использовать для разных случаев. Синглтон можно использовать для разных случаев. И можно себе на навредить, а можно сделать себе хорошо. И точно также яишка, она может навредить, когда если попытается что-то сама сделать неправильно, а может сделать хорошо, если хорошо дать задание ей и сказать: "Да, мне здесь вот именно здесь мне нужен синглтон, используй его". Так что Ишка, Ишка здесь помощник хороший, но я я считаю, это не замена. Моё мнение, это абсолютно не замена. И пока что пока что с ней можно жить и с ней нужно жить. Какой у тебя, кстати, сетап? У меня в основном это Copilot, я так использую, или CH GPT. У меня просто лицензия по работе чат GPTшная и гиitхабовская. Ну, тхабовский копат. И то, и то я могу использовать. Я и то, и то использую. А к редактору подцеплено или? Да, у меня в код Visual Studio Code поддержано и Visual Studio полноценный тоже есть, потому что, ну, опять же, лицензия позволяет на работе, почему нет? А платить что-то своё? Я как-то использовал курсор. Курсор использовал бесплатно, пока пока вот не появилась лицензия. Как только появилась рабочая лицензия, забыл уже курсор и в принципе ещё стоит и редактор стоит курсор, и, возможно, там что-то ещё есть. Я я просто 100 лет уже не запускал. Да, я, знаешь, тоже замечаю, что последнее время всё больше и больше оно быстрее думает, лучше соображает, если, особенно ты всё хорошо описываешь. Всё больше, больше смещаюсь в эту сторону. Меня немножко пугает о том, что большое количество знаний, тонкостей и понимания, которое у меня было в плане того, как писать код прямо до мельчайших деталей, там не только паттерны, а в принципе понятный код, именование и так далее, всё это становится неактуальным. Либо если правильно кишке подходить, она тебе делает очень многие вещи так, как бы ты в жизни никогда не сделал. И я пока до сих пор не понимаю, что с этим сделать. как бы как отфильтровать тот набор типа знаний, который является фундаментальным и с которым ты можешь всё это делать, и тот, который уже является мусорным. То, что вот в нас накопилось там за последние там много-много лет и, например, сейчас это не нужно. Мне кажется, ещё сложно пока отделить, потому что, знаешь, ты не всегда, знаешь, такое называется проклятие знания, ты не всегда себе отдаёшь отчёт, как твои знания влияют на действия. То есть, например, если бы я этого не знал, я бы понимал, что Иишка это сделает или не сделает, и я её попрошу это сделать. Вот я, например, как человек, который обучаю, постоянно нахожусь в вот сейчас в этом таком непонимании, типа, где вот эта вот база, а где вещи, которые на самом деле просто не нужны, потому что Ишка это делает. Вот у тебя сформировалось такое мнение или ещё нет? Не, нет. Ещё тоже не знаю. Не знаю, какие знания понадобятся. Точно архитектурные, точно паттерны, я считаю, паттерны понадобятся. Ну, хотя бы понимание структур данных. знать их вообще не надо, но хотя бы какое-то понимание структур данных нужно, потому что те же, например, алгоритмы, я решаю иногда, э, видосы записываю политкод решение, и там я было у меня соревнование, можно так сказать, записывал соревнования с Иишкой, кто лучше сгенерирует. И пока тышки не расскажешь, а сделай так. Так, она она проигрывала мне, но это было, правда, полгода назад или год назад. Возможно, уже она так сильно не тупит. Возможно. Она растёт. И я действительно тоже не понимаю, что именно в ближайшее время нам понадобится. Мы точно идём на новый уровень абстракции, точно ээ не должны уже задумываться о каких-то вещах. Как мы перестали 10 лет назад задумываться о выделении памяти и перестали вызывать функции МАК, там я уже не помню все функции диалог, который я вызывал в C++се. Как только перешёл на C#P, я забыл, что такое выделение памяти. Да, я ещё должен всё равно понимать, как работает память, потому что если не понимать, можно себе, опять же, выстрелить ногу даже в C#шарпе, несмотря на то, что он управляет памятью, если не использовать какие-то, ну, самая банальная вещь, ээ это с connction стрингами к базе данных. Если их не закрывать, то да, C#P закроет их. DNET DNET без проблем почистит память и когда-нибудь закроет, но это будет когда-нибудь. И мы должны писать всё ещё хороший код, чтобы они закрывались сразу же и не расходовали ресурсы. Точно так же, когда мы работаем с иишкой, да, он многое за нас додумает, он сделает. Точно так же, как мы перестали думать о выде о конкретном выделении памяти. Мы работаем уже на более высоком уровне, думая о памяти сверху. Точно также и о программировании. Мы будем думать как бы с какой-то более высокой лавочки такой, я бы так сказал. Но где эта лавочка будет? что нам необходимо будет, а какие знания. Вот это, наверное, чем больше, тем лучше. Чем больше, тем лучше. А какие реально необходимые, я не знаю, сложно сказать. А как ты, поскольку я знаю, ты много собеседуешь, ну, ты сейчас сам сказал, что чуть меньше, но всё же опыта в этом плане полно. Ты замечаешь, как всё это влияет на людей? Понимание ноль. Вообще понимание где-то вот тоже вот такие вещи спрашиваю. Например, кодвю даём. Мне очень нравится кодрев давать. Я сейчас не даю, опять же, сейчас как менеджер я код-рев вопросы не спрашиваю, но я мне нравится, когда мои программисты спрашивают. У меня технические спрашивают мои программисты. Я в основном бихвер менеджер бихверуal. И вот когда я ещё спрашивал сам, я очень любил код. И я вот очень любил спрашивать про а вот этот conneнеction string. Это потому что это самое популярное. Это мы используем каждый день. Когда ты используешь каждый день базу данных и должен знать, что действительно её нужно закрывать. И об этом знает один из двадцати. Понимает, что это работает. Просто понимает, тебе же не надо знать, что выделяется память, не надо знать про конекшн пулol, просто понимать, когда это произойдёт, что произойдёт. Базовые понимания о garbage коллекторе необходимы. И мало кто понимает. Ты хочешь сказать, что хуже стало со временем? Я не знаю, как сейчас, потому что опять же технически не я веду, а вот когда я ещё 5 лет назад спрашивал, было хуже, чем 10 лет назад. Я вот так скажу, 5 лет назад было. Сейчас иишкой, к сожалению, у меня в последнее время не так много интервью. И если я интервью провожу, в основном это интернец вот таких вот фултайм программистов с опытом каким-то ещё сравнить с ними сложно. Интерны приходят, они это те, которые в институте учатся, они как раз вот сейчас вот должны по идее а вот свежие знания у них хорошие. И я заметил, что канадские институты хорошо, в принципе, их прокачивают по алгоритмам. Особенно наш университет, он в Канаде считается самым крутым. Недаром там Blackberry рядом втерло и институт там самый крутой ещё один из крутых, по крайней мере, в Канаде. Из того, что я интервью проводил, Телон Loлон студенты самые крутые. Ну он и самый дорогой институт, если там учиться. И если спрашивать их по алгоритмам, полид Ткод, они в основном решают Т-код на ура. Но как только спрашиваешь, что такое жизненное, практическое, что ты будешь использовать каждый день, паттерны или о garbage коллекторе, вот таких вещах, ноль. Дальше вот к сожалению приходится вот этому учить. После того, как мы нанимаем, приходится учить. Ну это реальность практически всех, да, так или иначе, то есть об об этом знают студенты только те, которые там с третьего курса, допустим, работают. Это вот прямо самые золотые ребята. Но они обычно самые крутые, сам знаешь, они уже в это время в Фейсбуке, поэтому они просто к вам не придут, скорее всего. Да, у нас зарплата с Фейсбуком не сравнится. Понятно. Миш, большое тебе спасибо за разговор про паттерные и не только. Да, и не только про паттерные. Ребят, если вам понравилось, отвлекается, напишите, что вы об этом думаете, поставьте плюсик. Если нет, считаете, что всё не так. А я вполне допускаю, особенно зная, какие обычно комментарии оставляют, что и это не актуальные знания, что паттерны больше не нужны и вообще никогда не были нужны. Тоже пишите, интересно будет почитать и посмотреть. Миша, большое спасибо за то, что пришёл, этим поделился. Спасибо за приглашение. До следующих встреч, ребят. Пока.