10/10. Для меня первый не нудный и не убитый жизнью автор, который так позитивно и интересно доносит тему. Всегда приятно освежить свои знания, и полезно услышать мнение человека с опытом. Лайк подпеска
Всегда считал себя тормозом, когда несколько часов обдумывал варианты и искал правильный способ реализации того, или иного функционал, перед реализацией "Время не ждет, просто возьми и напиши код". Теперь я более менее спокоен
Однозначно один из лучших канонов по java и ООП в целом! Полезны любые видео по лучшим практикам написания кода, синтаксис выучить легко, а научиться правильно писать гораздо сложнее...
@@alexlightweight Я просто недавно столкнулся с тем, что мой код разросся и стало сложно его модифицировать, а раз его сложно поддерживать, значит он -говно, я конечно сейчас перепаковываю всё в отдельные классы и функции, но интересно было бы знать, что ещё предпринимают для улучшения кода специалисты, такие как Сергей.
@@alexlightweight ваши слова словно бальзам на душу. А то сидишь такой и думаешь "хоть бы мой код никто никогда не увидел, а то сразу скажут "что за дурак это проектировал"".
Огромное спасибо, что записали это видео. Программирование - это великая наука. А интересная просто ЖУТЬ как)))))))))))))))))) Однажды создав маленькую программу данный процесс уже не остановить!!!
Сергей, смотрел ваши ролики раньше только потому что вы такой жизнерадостный пирожочек, но редко было такое, что тема была настолько понятно раскрыта чтобы я мог скидывать видео коллегам которые что-то не поняли, но в этот раз это прямо шедевр, самое главное что понятны жизненные ситуации, когда соблюдение такого принципе предотвратит серию катастроф.
Дякую шановний ! Дуже цікавий приклад Ви розглянули. Геть по іншому сприймав цей принцип. Насправді, тут можна багато прикладів різних типів класів. Тонна корисної інфи, варто це обережно пробувати ручками 🤝
обожаю такие видео, где ты смотришь про то, что используешь - но при этом не знаешь как оно в мире зовется :) то что здесь рассказывает человек - ну это же "естественные" вещи, ну или меня так учили в 2000-х годах
Спасибо Вам большое) Очень интересно Вас слушать на эти темы. Примерно год назад слушал это видео, но был, как я сейчас понял, даже еще не новичком, а пересматривая сейчас, понимаю, что эти принципы очень даже логичны и даже не осознанно сам так делаю) еще раз спасибо Вам за такие видео, однозначно лайк )
тема определенно интересна, хотелось бы побольше таких видео - коротенько, суть, так сказать. Ведь самое сложное - дойти до простого. Когда большой тутор новичок теряется. Важно сначала понять суть, а потом уже можно вникать в детали. А у Сергея очень хорошая подача, что тоже очень важно
5:45 В книге "Чистая архитектура" дядюшка Боб говорит о том, что обычно этот принцип озвучивают про "одну обязанность", но это не совсем верно! Потом он вводит действующее лицо "Пользователь или группа пользователей. Назовем их авторами" и потом дает точную формулировку принципа: Модуль должен изменяться только из-за одного актора.
Спасибо! Я тоже программист с большим опытом (вероятно, не меньшим, чем у автора), и не то, чтобы меня настигло откровение в этом видео, но ещё разок вспомнить основы, рассказанные с чуть нового угла - всегда полезно и приятно.
Ну наконец-то. Хоть кто-то использует адекватные примеры. А то везде натыкаюсь на примеры, от которых возникает только один вопрос: "как про такую чушь бесполезную столько книг понаписали?" Теперь хоть понятно, что и так всегда его использовал) Спасибо
Касательно самого принципа, ну я бы немного придрался :) Все таки SRP также должен учитывать и функциональные требования, особенно это касается когда люди еще любят DRY применять всегда и везде. То что в данный момент некоторые куски кода или некоторые классы у вас выглядят одинаково совсем не значит, что в дальнейшем они будут одинаковы. SRP больше говорит о том, что причины для изменения одного класса должны лежать только в одной функциональной области. Например, не должно быть так, что один и тот же класс у вас правится, если вам необходимо поменять формат вывода счет фактуры в pdf и правило расчета цен для этой же фактуры. Расчет цен условий - одна функциональная область, вывод документа на печать - другая. Менять один и тот же класс(а тем более метод) в обоих этих случаях - чет хрень какая-то :) То что вы описали, все таки ближе именно к DRY(ну или очень сильно с ним пересекается), но тут опять такая загвоздка - не всегда код который выглядит одинаково - отвечает за один и тот же функционал с точки зрения бизнес логики. Тогда переиспользование таких классов - это только вред, т.к. рано или поздно(и с очень большой попаболью) придётся эти зависимости разрывать. Да и вообще SRP может быть(и должен) обоснован без упоминания переиспользования как такового, т.к. решает другую проблему - проблему раздутых и god классов. Упоминание переиспользования только добавляет каши и может привести к неверному выводу, что если я не хочу переиспользовать этот функционал где-то еще, то можно его в принципе и не выносить. Clean Code у Мартина очень спорная книга, большинство пунктов полезные, но есть и прям вредные моменты. Намного более нейтрально и основательно практически 90% пунктов(если не 100) из чистого кода также описаны в Совершенном коде Макконнелла. Не категорично, не безусловно, а скорее как раз так просто описательно. Что они дают и чего помогают достичь. Именно из-за того, что сначала читал Совершенный код, чистый код во многом казался уже вторичным продуктом. При этом намного более грубым в подаче, с невразумительными примерами. При этом в Совершенном коде кроме того что есть у Мартина дана еще куча полезной инфы. Так что я бы брал её и можно, в принципе, больше не читать книг именно касательно качества кодовой базы с точки зрения её организации. При этом обе книги я бы рекомендовал не сразу прям, а лучше где-то после нескольких месяцев(может даже полгода) работы. Чтобы уже была база и был опыт работы с большими кодовыми базами. Только тогда многие моменты будут понятны, иначе многие пункты просто ни за что не зацепятся(не будет опыта, на основе которого постоянно будет кликать в голове "а вот как это делается" или "блин, и так можно было"). Т.е. сначала немного покопаться, набить пару шишек и потом уже всё это разложить по полочкам. Читать эти книги при прохождении каких-то курсов, когда у вас опыта особо еще нет - трата времени, имхо конечно же. С паттернами "банды 4х" та же история, вообще не понимаю людей, которые эту книгу советуют новичкам. Обычно, когда человек "дорос" до этой книги, он о ней уже сам прекрасно знает :)
clean code довольно таки широко принятый подход...вполне можно сказать даже стандарт де факто, по крайней мере когда речь идет об современных ооп языках.
@@ergo_____3491 Волне возможно, только вот у Матрина такой же перекос, только в сторону длины методов, лишних . Не дай бог метод будет длинным! "Первое правило: Функции должны быть компактными. Второе правило: функции должны быть еще компактнее. Желательно, чтобы длина функции не превышала 20 строк". Не, я не спорю, может на основе его опыта это и так, но возводить это в правило? Или то что заголовочные комментарии javadoc к каждому методу - это трата времени. Абсолютно не упоминая контекст, когда это может быть необходимо для банальной сдачи проекта на поддержку, т.к. это требование было прописано в договоре, что все интерфейсы должны быть задокументированы. Да и по примерам с кодом есть вопросы. У вас наверняка есть эта книга, посмотрите примеры 6.1 и 6.2. Почему Мартин считает, что пример 6.2 лучше, без вопросов. Что он не раскрывает реализации(хотя это не так, геттеры без проблем раскрывают реализацию. При этом это интерфейс, и мы должны его реализовать, чтобы получить возможность использовать точки. А чтобы его реализовать, нам надо реализовать все методы, а что если они нам не нужны? Тут уже идет явное нарушение принципе YAGNI, зачем в интерфейс зашивать полярные координаты, если в требовании явно говорится что мы будем хранить координаты точки на декартовой плоскости? В каждой из этих книг есть перекосы, просто в книге Макконнелла они более нейтральны. Там меньше "правил" и "требований" в жестких формулировках. Ну и конечно когда читаешь эти книги надо понимать, что информатику может и можно отнести к точным наукам, но уж не в разрезе прикладного программирования с точки зрения структуры кода. Тут мы ближе к лингвистике. Так что любые советы надо не просто принимать, а анализировать и пропускать через себя и свой опыт. Именно поэтому я читал обе книги, именно поэтому и посоветовал эти книги(какую бы вы ни выбрали) читать уже получив какой-то свой, собственный опыт. Иначе это может превратится в слепое поклонение принципам. Я все эти книги воспринимаю больше как мнение старших товарищей, нежели как правила или требования, которые являются для меня отправной точкой, чтобы не пришлось самому набивать некоторые шишки. Но если в какой-то момент я решу написать метод длиннее 20 строк и мне это будет казаться более разумной идеей, нежели дробление его на 5 других методов - то почему нет?
@@dmitriyobidin6049 Методы должны быть максимально короткими, 1-5 строк идеально. Все остальное - рассадник багов, боль для тех, кто пишет тесты и тех, кто работает с этим кодом в будущем.
Хороший принцип. Я часто встречал разработчиков, которые считали, что применение этого принципа усложняет код: грубо говоря, вместо одного класса получаем два. Приходилось долго убеждать.
Сергей, предлагаю новую рубрику: рефакторинг с Сергеем Немчинским. Чтобы на практике увидеть "code smells" и как с ними бороться. У вас охрененный опыт, мне кажется он максимально раскроется в таком формате.
Спасибо за видео! Как говорил мой преподаватель в универе - Код должен сначала заработать у вас в голове, а уже потом в калькуляторе)) ИМХО, лучше всего думается на теплом песочке, рисуя палочкой))
Сам я ни сколько не програмист. Но пришлось сделать автоматизацию рутины, которая сберегла кучу времени и нервов целому коллективу преподавателей. Писал в vba. Часть кода записал с помощью рикодера ворда, часть нагуглил в рунете. Вот тогда я интуитивно стал понимать что я столкнулся с проблемой правильной декомпозиции, а также создания правильных "классов". То есть коды на отдельные операции я где-то нагуглил, а где-то записал с помощью рикодера и изначально привязывал их к соответствующим горячим клавишам, с помощью которых их последовательно запускал. Но с увеличением количества таких макросов, запуск этих команд также стала превращаться в рутину. И меня осенило, что я их могу объеденить по определенным блокам, в зависимости от очередности исполнения кода. Я объединял их с помощью другого vba кода. И привязал исполнение всего кода лишь к одной комбинации горячей клавиши. Самое главное, этот макрос я мог переносить на любой пк, где после минутной настройки он становился рабочим и им мог пользоваться лбой юзер.
Шедеврально! Коротко и ясно. Смотрел видео по патернам 2 года назад, и слабо понял из-за малого опыта. Поработал на двух проектах, поднабрался опыт, пересметриваю и понимаю что да. Сталкивался с похожими проблемами в реальных приложениях! Спасибо!
💪Новый поток advanced тренинга Enterprise patterns стартует 2.12 - go.foxminded.ua/3zXtslk
Ждём видео про "запахи кода".
Поддерживаю, ждём!
Очень
да!
плюс стопицот! очень-очень интересно :)
Smells like teen spirit. It stinks of beer and drugs.
10/10. Для меня первый не нудный и не убитый жизнью автор, который так позитивно и интересно доносит тему. Всегда приятно освежить свои знания, и полезно услышать мнение человека с опытом. Лайк подпеска
Всегда считал себя тормозом, когда несколько часов обдумывал варианты и искал правильный способ реализации того, или иного функционал, перед реализацией "Время не ждет, просто возьми и напиши код". Теперь я более менее спокоен
Спасибо за видео. Да, интересно и про SOLID и про ошибки.
Видео топ. Обращу ваше внимание, товарищи, что мы с вами живём в тот день, когда стаж нашего слуги стал не большим, а ОЧЕНЬ большим!
Однозначно один из лучших канонов по java и ООП в целом! Полезны любые видео по лучшим практикам написания кода, синтаксис выучить легко, а научиться правильно писать гораздо сложнее...
Про code smell очень интересно было бы послушать. А так, спасибо за видео.
+
+
+. хочется понять степень говенности моего кода)), так как самоучка
@@alexlightweight Я просто недавно столкнулся с тем, что мой код разросся и стало сложно его модифицировать, а раз его сложно поддерживать, значит он -говно, я конечно сейчас перепаковываю всё в отдельные классы и функции, но интересно было бы знать, что ещё предпринимают для улучшения кода специалисты, такие как Сергей.
@@alexlightweight ваши слова словно бальзам на душу. А то сидишь такой и думаешь "хоть бы мой код никто никогда не увидел, а то сразу скажут "что за дурак это проектировал"".
Спасибо! КОнечно ДА!
п.с. спасибо что всё так подробно объясняете вплоть до "это ромбик", чтобы мы не додумывали и не тупили)
Огромное спасибо, что записали это видео. Программирование - это великая наука. А интересная просто ЖУТЬ как)))))))))))))))))) Однажды создав маленькую программу данный процесс уже не остановить!!!
Сергей, смотрел ваши ролики раньше только потому что вы такой жизнерадостный пирожочек, но редко было такое, что тема была настолько понятно раскрыта чтобы я мог скидывать видео коллегам которые что-то не поняли, но в этот раз это прямо шедевр, самое главное что понятны жизненные ситуации, когда соблюдение такого принципе предотвратит серию катастроф.
Дякую шановний !
Дуже цікавий приклад Ви розглянули.
Геть по іншому сприймав цей принцип.
Насправді, тут можна багато прикладів різних типів класів.
Тонна корисної інфи, варто це обережно пробувати ручками 🤝
Пиши на человеческом
@@RandomForest-es6yp не розумію болгарської
обожаю такие видео, где ты смотришь про то, что используешь - но при этом не знаешь как оно в мире зовется :)
то что здесь рассказывает человек - ну это же "естественные" вещи, ну или меня так учили в 2000-х годах
Сергей, ваше видео просмотрело и пролайкало больше людей, чем лекцию самого Дяди Боба. Это же нонсенс!!! Вайти-вайти...
Мне хоть уже и знакомы SOLID принципы, все равно с удовольствием прослушал. Повторение - мать учения.
Хотя это и самореклама, но. Очень приятный грамотный человек. Спасибо за труды. Не сомневаюсь что автор прекрасный преподаватель!
спасибо за разжевывание SOLID. очень нужная тема и простым языком.
Спасибо большое за видео)
Крутой формат, и видео как раз оптимальной длины
Определённо нужно больше таких видео!
Сергей сказал в августе про SOLID, значит в августе про SOLID! )) Спасибо!
круто, продолжайте эту серию, и делайте про другие принципы, наконец-то качественный контент, а не жевание одного и того же много раз.
Крутяцьке відео, получилося вогень
Сергей, огромное спасибо за видео! Очень подробно и понятно! Вы отлично умеете объяснять
Спасибо за такое подробное объяснение принципов SOLID!
Идеальный формат, быстро и доходчиво!
Спасибо! Очень интересно! Продолжайте про все принципы!
Всё интересно! Всё делайте!
Очень интересно про SOLID, продолжайте)
Ураааааааа))))Спасибо, дождались наконец-то)
Спасибо Сергей, еще не смотрел,но я думаю это будет отличное объяснение👍🏻👍🏻👍🏻👍🏻👍🏻
Спасибо Вам большое) Очень интересно Вас слушать на эти темы. Примерно год назад слушал это видео, но был, как я сейчас понял, даже еще не новичком, а пересматривая сейчас, понимаю, что эти принципы очень даже логичны и даже не осознанно сам так делаю) еще раз спасибо Вам за такие видео, однозначно лайк )
Отличный формат видео!
Ждал это видео от вас, еще не смотрел но уже знаю что все будет на уровне)))
тема определенно интересна, хотелось бы побольше таких видео - коротенько, суть, так сказать. Ведь самое сложное - дойти до простого. Когда большой тутор новичок теряется. Важно сначала понять суть, а потом уже можно вникать в детали. А у Сергея очень хорошая подача, что тоже очень важно
Тема супер, решил посмотреть сразу не смотря на то что опаздываю на работу.
code smell тоже очень интересно
5:45 В книге "Чистая архитектура" дядюшка Боб говорит о том, что обычно этот принцип озвучивают про "одну обязанность", но это не совсем верно! Потом он вводит действующее лицо "Пользователь или группа пользователей. Назовем их авторами" и потом дает точную формулировку принципа:
Модуль должен изменяться только из-за одного актора.
Сергей, разъясняете очень интересные и актуальные вопросы, продолжайте делиться знаниями по SOLID. Спасибо Вам за то, что делаете!
Отличное объяснение! Видео короткое, 15 минут. Но чтобы реально все из него осмыслить, нужно побольше времени))
Интересно было, хорошие примеры.
Спасибо за видео!)
P.S. Возьмите черный маркер, нечего не видно
Ждём продолжения. Молодец Серёга.
Браво 👍❤ жду продолжения
Спасибо. Очень познавательно и, главное, понятно.
Побольше таких видео. Здорово получается.
Супер! Продолжайте
Это любимая тематика видео
Спасибо вам за ваше видео!
Отличное видео, продолжайте. И да, не стесняйтесь длинных видео.
Большое спасибо за выпуск!!!
Спасибо! Я тоже программист с большим опытом (вероятно, не меньшим, чем у автора), и не то, чтобы меня настигло откровение в этом видео, но ещё разок вспомнить основы, рассказанные с чуть нового угла - всегда полезно и приятно.
Хорошо, что перешли к техническим видео, не помешает.
Спасибо за видио! Интересное тема, жду продолжения
Очень круто! Спасибо за видео.
Спасибо за ваше время, если можно больше про принципов.
Всё интересно. И про запахи и про всё остальное! Ждём-с )
ооо, вот это действительно классная тема ))))) спасибо, за Ваши видео ))))))
Ну наконец-то. Хоть кто-то использует адекватные примеры. А то везде натыкаюсь на примеры, от которых возникает только один вопрос: "как про такую чушь бесполезную столько книг понаписали?"
Теперь хоть понятно, что и так всегда его использовал)
Спасибо
Огонь тема! Продолжайте!
Спасибо за детальное видео. Видимо придётса смотреть раз 10 что бы запомнить а затем через пол года забыть.
Касательно самого принципа, ну я бы немного придрался :)
Все таки SRP также должен учитывать и функциональные требования, особенно это касается когда люди еще любят DRY применять всегда и везде. То что в данный момент некоторые куски кода или некоторые классы у вас выглядят одинаково совсем не значит, что в дальнейшем они будут одинаковы.
SRP больше говорит о том, что причины для изменения одного класса должны лежать только в одной функциональной области. Например, не должно быть так, что один и тот же класс у вас правится, если вам необходимо поменять формат вывода счет фактуры в pdf и правило расчета цен для этой же фактуры. Расчет цен условий - одна функциональная область, вывод документа на печать - другая. Менять один и тот же класс(а тем более метод) в обоих этих случаях - чет хрень какая-то :)
То что вы описали, все таки ближе именно к DRY(ну или очень сильно с ним пересекается), но тут опять такая загвоздка - не всегда код который выглядит одинаково - отвечает за один и тот же функционал с точки зрения бизнес логики. Тогда переиспользование таких классов - это только вред, т.к. рано или поздно(и с очень большой попаболью) придётся эти зависимости разрывать. Да и вообще SRP может быть(и должен) обоснован без упоминания переиспользования как такового, т.к. решает другую проблему - проблему раздутых и god классов. Упоминание переиспользования только добавляет каши и может привести к неверному выводу, что если я не хочу переиспользовать этот функционал где-то еще, то можно его в принципе и не выносить.
Clean Code у Мартина очень спорная книга, большинство пунктов полезные, но есть и прям вредные моменты. Намного более нейтрально и основательно практически 90% пунктов(если не 100) из чистого кода также описаны в Совершенном коде Макконнелла. Не категорично, не безусловно, а скорее как раз так просто описательно. Что они дают и чего помогают достичь. Именно из-за того, что сначала читал Совершенный код, чистый код во многом казался уже вторичным продуктом. При этом намного более грубым в подаче, с невразумительными примерами. При этом в Совершенном коде кроме того что есть у Мартина дана еще куча полезной инфы. Так что я бы брал её и можно, в принципе, больше не читать книг именно касательно качества кодовой базы с точки зрения её организации.
При этом обе книги я бы рекомендовал не сразу прям, а лучше где-то после нескольких месяцев(может даже полгода) работы. Чтобы уже была база и был опыт работы с большими кодовыми базами. Только тогда многие моменты будут понятны, иначе многие пункты просто ни за что не зацепятся(не будет опыта, на основе которого постоянно будет кликать в голове "а вот как это делается" или "блин, и так можно было"). Т.е. сначала немного покопаться, набить пару шишек и потом уже всё это разложить по полочкам. Читать эти книги при прохождении каких-то курсов, когда у вас опыта особо еще нет - трата времени, имхо конечно же. С паттернами "банды 4х" та же история, вообще не понимаю людей, которые эту книгу советуют новичкам. Обычно, когда человек "дорос" до этой книги, он о ней уже сам прекрасно знает :)
А с чем именно не согласны с Мартином, не могли бы в двух словах рассказать?
clean code довольно таки широко принятый подход...вполне можно сказать даже стандарт де факто, по крайней мере когда речь идет об современных ооп языках.
Интересная точка зрения, спасибо за советы!
@@ergo_____3491 Волне возможно, только вот у Матрина такой же перекос, только в сторону длины методов, лишних . Не дай бог метод будет длинным! "Первое правило: Функции должны быть компактными. Второе правило: функции должны быть еще компактнее. Желательно, чтобы длина функции не превышала 20 строк". Не, я не спорю, может на основе его опыта это и так, но возводить это в правило? Или то что заголовочные комментарии javadoc к каждому методу - это трата времени. Абсолютно не упоминая контекст, когда это может быть необходимо для банальной сдачи проекта на поддержку, т.к. это требование было прописано в договоре, что все интерфейсы должны быть задокументированы.
Да и по примерам с кодом есть вопросы. У вас наверняка есть эта книга, посмотрите примеры 6.1 и 6.2. Почему Мартин считает, что пример 6.2 лучше, без вопросов. Что он не раскрывает реализации(хотя это не так, геттеры без проблем раскрывают реализацию. При этом это интерфейс, и мы должны его реализовать, чтобы получить возможность использовать точки. А чтобы его реализовать, нам надо реализовать все методы, а что если они нам не нужны? Тут уже идет явное нарушение принципе YAGNI, зачем в интерфейс зашивать полярные координаты, если в требовании явно говорится что мы будем хранить координаты точки на декартовой плоскости?
В каждой из этих книг есть перекосы, просто в книге Макконнелла они более нейтральны. Там меньше "правил" и "требований" в жестких формулировках. Ну и конечно когда читаешь эти книги надо понимать, что информатику может и можно отнести к точным наукам, но уж не в разрезе прикладного программирования с точки зрения структуры кода. Тут мы ближе к лингвистике. Так что любые советы надо не просто принимать, а анализировать и пропускать через себя и свой опыт. Именно поэтому я читал обе книги, именно поэтому и посоветовал эти книги(какую бы вы ни выбрали) читать уже получив какой-то свой, собственный опыт. Иначе это может превратится в слепое поклонение принципам. Я все эти книги воспринимаю больше как мнение старших товарищей, нежели как правила или требования, которые являются для меня отправной точкой, чтобы не пришлось самому набивать некоторые шишки. Но если в какой-то момент я решу написать метод длиннее 20 строк и мне это будет казаться более разумной идеей, нежели дробление его на 5 других методов - то почему нет?
@@dmitriyobidin6049 Методы должны быть максимально короткими, 1-5 строк идеально. Все остальное - рассадник багов, боль для тех, кто пишет тесты и тех, кто работает с этим кодом в будущем.
Спасибо, ждём продолжения
Очень интересно. Жду продолжение
Спасибо огромное за видео по SOLID, сейчас прохожу обучение и надо во всем этом разобраться.
Хороший принцип. Я часто встречал разработчиков, которые считали, что применение этого принципа усложняет код: грубо говоря, вместо одного класса получаем два. Приходилось долго убеждать.
Интересно прослушать все затронутые темы
Прекрасно, как всегда!
Супер. Спасибо. Ждемс еще
Спасибо, Сергей. Замечательное дополнение к книге дяди Боба.
Зашёл чтобы лайкнуть серьёзную тему на канале
О! Класс! Большое спасибо!!!:)
Круто! Спасибо. Самое главное что в подаче материала нет заумных терминов/слов.
Про котиків і соцмережі- це ваще крутяк. Сміюся)))
Сергей, предлагаю новую рубрику: рефакторинг с Сергеем Немчинским. Чтобы на практике увидеть "code smells" и как с ними бороться. У вас охрененный опыт, мне кажется он максимально раскроется в таком формате.
Да всё интересно, всё записывайте!
конечно интересно про code smells.Спасибо за видео
Сергей, благодарю!
Очень интересно. Про анти-паттерны прям надо!!!
Спасибо за видео!
Как говорил мой преподаватель в универе - Код должен сначала заработать у вас в голове, а уже потом в калькуляторе))
ИМХО, лучше всего думается на теплом песочке, рисуя палочкой))
Дичайше интересно, спасибо!
Спасибо за видео. Нужно продолжение!))
Так спокойно и размеренно все объясняешь. Хоть для медитации включай)
Интересно, спасибо Сергей!
Супер-пупер интересно, спасибо)))
Пеннивайз реально годноту делает. Лайк подписка!)
спасибо за примеры и видео!
Сам я ни сколько не програмист. Но пришлось сделать автоматизацию рутины, которая сберегла кучу времени и нервов целому коллективу преподавателей. Писал в vba. Часть кода записал с помощью рикодера ворда, часть нагуглил в рунете. Вот тогда я интуитивно стал понимать что я столкнулся с проблемой правильной декомпозиции, а также создания правильных "классов". То есть коды на отдельные операции я где-то нагуглил, а где-то записал с помощью рикодера и изначально привязывал их к соответствующим горячим клавишам, с помощью которых их последовательно запускал. Но с увеличением количества таких макросов, запуск этих команд также стала превращаться в рутину. И меня осенило, что я их могу объеденить по определенным блокам, в зависимости от очередности исполнения кода. Я объединял их с помощью другого vba кода. И привязал исполнение всего кода лишь к одной комбинации горячей клавиши. Самое главное, этот макрос я мог переносить на любой пк, где после минутной настройки он становился рабочим и им мог пользоваться лбой юзер.
Кайф, только сколько не смотрю семенары с вашим участием всегда не видно что вы пишете на доске) а так все очень доходчиво и понятно, спасибо)
Супер. Ждем все принципы)..
Сергей, с Новым Годом! Желаю Вам и всей команде успеха и гармоничного развития. Сберегайте и приумножайте! Вас всегда полезно и интересно слушать.
13:10 - не, ну чё сразу котики, я вот Немчинского смотрю)
а вдруг он тоже котик?
@@Mr43046721 он лиса
Denis ору)
Круто! Спасибо!
Продолжайте!
Супер! Как же дождаться последнего принципа теперь...
Супер! Все по делу.
спасибо за видео
Конечно будет интересно послушать про Code Smells
Спасибо. Данная тематика интересна)
Запах кода очень интересно)
Тема отличная!! Побольше таких видео!!
Шедеврально!
Коротко и ясно. Смотрел видео по патернам 2 года назад, и слабо понял из-за малого опыта. Поработал на двух проектах, поднабрался опыт, пересметриваю и понимаю что да.
Сталкивался с похожими проблемами в реальных приложениях!
Спасибо!