@@alexlightweight Я просто недавно столкнулся с тем, что мой код разросся и стало сложно его модифицировать, а раз его сложно поддерживать, значит он -говно, я конечно сейчас перепаковываю всё в отдельные классы и функции, но интересно было бы знать, что ещё предпринимают для улучшения кода специалисты, такие как Сергей.
@@alexlightweight ваши слова словно бальзам на душу. А то сидишь такой и думаешь "хоть бы мой код никто никогда не увидел, а то сразу скажут "что за дурак это проектировал"".
10/10. Для меня первый не нудный и не убитый жизнью автор, который так позитивно и интересно доносит тему. Всегда приятно освежить свои знания, и полезно услышать мнение человека с опытом. Лайк подпеска
Всегда считал себя тормозом, когда несколько часов обдумывал варианты и искал правильный способ реализации того, или иного функционал, перед реализацией "Время не ждет, просто возьми и напиши код". Теперь я более менее спокоен
5:45 В книге "Чистая архитектура" дядюшка Боб говорит о том, что обычно этот принцип озвучивают про "одну обязанность", но это не совсем верно! Потом он вводит действующее лицо "Пользователь или группа пользователей. Назовем их авторами" и потом дает точную формулировку принципа: Модуль должен изменяться только из-за одного актора.
Сергей, смотрел ваши ролики раньше только потому что вы такой жизнерадостный пирожочек, но редко было такое, что тема была настолько понятно раскрыта чтобы я мог скидывать видео коллегам которые что-то не поняли, но в этот раз это прямо шедевр, самое главное что понятны жизненные ситуации, когда соблюдение такого принципе предотвратит серию катастроф.
Однозначно один из лучших канонов по java и ООП в целом! Полезны любые видео по лучшим практикам написания кода, синтаксис выучить легко, а научиться правильно писать гораздо сложнее...
Огромное спасибо, что записали это видео. Программирование - это великая наука. А интересная просто ЖУТЬ как)))))))))))))))))) Однажды создав маленькую программу данный процесс уже не остановить!!!
обожаю такие видео, где ты смотришь про то, что используешь - но при этом не знаешь как оно в мире зовется :) то что здесь рассказывает человек - ну это же "естественные" вещи, ну или меня так учили в 2000-х годах
Дякую шановний ! Дуже цікавий приклад Ви розглянули. Геть по іншому сприймав цей принцип. Насправді, тут можна багато прикладів різних типів класів. Тонна корисної інфи, варто це обережно пробувати ручками 🤝
Касательно самого принципа, ну я бы немного придрался :) Все таки 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" и как с ними бороться. У вас охрененный опыт, мне кажется он максимально раскроется в таком формате.
Хороший принцип. Я часто встречал разработчиков, которые считали, что применение этого принципа усложняет код: грубо говоря, вместо одного класса получаем два. Приходилось долго убеждать.
тема определенно интересна, хотелось бы побольше таких видео - коротенько, суть, так сказать. Ведь самое сложное - дойти до простого. Когда большой тутор новичок теряется. Важно сначала понять суть, а потом уже можно вникать в детали. А у Сергея очень хорошая подача, что тоже очень важно
Спасибо за видео! Как говорил мой преподаватель в универе - Код должен сначала заработать у вас в голове, а уже потом в калькуляторе)) ИМХО, лучше всего думается на теплом песочке, рисуя палочкой))
Спасибо! Я тоже программист с большим опытом (вероятно, не меньшим, чем у автора), и не то, чтобы меня настигло откровение в этом видео, но ещё разок вспомнить основы, рассказанные с чуть нового угла - всегда полезно и приятно.
На самом деле SRP говорить о том, что класс должен использоваться только для одного actor (пользователя/группы пользователей). В этом видео описание больше похоже на ISP, но если быть точнее, то это принцип согласованной абстракции (Совершенный код Стив Макконелл) (не SOLID)
Тема очень важна и подача хороша.Ждем скорее продолжения)Спасибо) Еще ,если будет время,интересно послушать о ЛЯМБДА-ВЫРАЖЕНИЯХ и ФУНКЦИОНАЛЬНЫХ ИНТЕРФЕЙСАХ. Еще интересно послушать о классах String Builder и String Buffer. Про многомерные массивы и еще куча всего)))
💪Новый поток advanced тренинга Enterprise patterns стартует 2.12 - go.foxminded.ua/3zXtslk
Ждём видео про "запахи кода".
Поддерживаю, ждём!
Очень
да!
плюс стопицот! очень-очень интересно :)
Smells like teen spirit. It stinks of beer and drugs.
Спасибо за видео. Да, интересно и про SOLID и про ошибки.
Крутяцьке відео, получилося вогень
Про code smell очень интересно было бы послушать. А так, спасибо за видео.
+
+
+. хочется понять степень говенности моего кода)), так как самоучка
@@alexlightweight Я просто недавно столкнулся с тем, что мой код разросся и стало сложно его модифицировать, а раз его сложно поддерживать, значит он -говно, я конечно сейчас перепаковываю всё в отдельные классы и функции, но интересно было бы знать, что ещё предпринимают для улучшения кода специалисты, такие как Сергей.
@@alexlightweight ваши слова словно бальзам на душу. А то сидишь такой и думаешь "хоть бы мой код никто никогда не увидел, а то сразу скажут "что за дурак это проектировал"".
10/10. Для меня первый не нудный и не убитый жизнью автор, который так позитивно и интересно доносит тему. Всегда приятно освежить свои знания, и полезно услышать мнение человека с опытом. Лайк подпеска
Видео топ. Обращу ваше внимание, товарищи, что мы с вами живём в тот день, когда стаж нашего слуги стал не большим, а ОЧЕНЬ большим!
Спасибо за видео!)
P.S. Возьмите черный маркер, нечего не видно
Всегда считал себя тормозом, когда несколько часов обдумывал варианты и искал правильный способ реализации того, или иного функционал, перед реализацией "Время не ждет, просто возьми и напиши код". Теперь я более менее спокоен
5:45 В книге "Чистая архитектура" дядюшка Боб говорит о том, что обычно этот принцип озвучивают про "одну обязанность", но это не совсем верно! Потом он вводит действующее лицо "Пользователь или группа пользователей. Назовем их авторами" и потом дает точную формулировку принципа:
Модуль должен изменяться только из-за одного актора.
Сергей, смотрел ваши ролики раньше только потому что вы такой жизнерадостный пирожочек, но редко было такое, что тема была настолько понятно раскрыта чтобы я мог скидывать видео коллегам которые что-то не поняли, но в этот раз это прямо шедевр, самое главное что понятны жизненные ситуации, когда соблюдение такого принципе предотвратит серию катастроф.
Однозначно один из лучших канонов по java и ООП в целом! Полезны любые видео по лучшим практикам написания кода, синтаксис выучить легко, а научиться правильно писать гораздо сложнее...
Хотя это и самореклама, но. Очень приятный грамотный человек. Спасибо за труды. Не сомневаюсь что автор прекрасный преподаватель!
Огромное спасибо, что записали это видео. Программирование - это великая наука. А интересная просто ЖУТЬ как)))))))))))))))))) Однажды создав маленькую программу данный процесс уже не остановить!!!
Спасибо за ваше время, если можно больше про принципов.
Сергей, ваше видео просмотрело и пролайкало больше людей, чем лекцию самого Дяди Боба. Это же нонсенс!!! Вайти-вайти...
Крутой формат, и видео как раз оптимальной длины
спасибо за разжевывание SOLID. очень нужная тема и простым языком.
Спасибо! Очень интересно! Продолжайте про все принципы!
Спасибо большое за видео)
Спасибо! КОнечно ДА!
п.с. спасибо что всё так подробно объясняете вплоть до "это ромбик", чтобы мы не додумывали и не тупили)
обожаю такие видео, где ты смотришь про то, что используешь - но при этом не знаешь как оно в мире зовется :)
то что здесь рассказывает человек - ну это же "естественные" вещи, ну или меня так учили в 2000-х годах
Интересно прослушать все затронутые темы
Дякую шановний !
Дуже цікавий приклад Ви розглянули.
Геть по іншому сприймав цей принцип.
Насправді, тут можна багато прикладів різних типів класів.
Тонна корисної інфи, варто це обережно пробувати ручками 🤝
Пиши на человеческом
@@RandomForest-es6yp не розумію болгарської
Определённо нужно больше таких видео!
круто, продолжайте эту серию, и делайте про другие принципы, наконец-то качественный контент, а не жевание одного и того же много раз.
Мне хоть уже и знакомы SOLID принципы, все равно с удовольствием прослушал. Повторение - мать учения.
Сергей сказал в августе про SOLID, значит в августе про SOLID! )) Спасибо!
конечно интересно про code smells.Спасибо за видео
Отличный формат видео!
Очень интересно про SOLID, продолжайте)
Сергей, с Новым Годом! Желаю Вам и всей команде успеха и гармоничного развития. Сберегайте и приумножайте! Вас всегда полезно и интересно слушать.
Побольше таких видео. Здорово получается.
Касательно самого принципа, ну я бы немного придрался :)
Все таки 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
Тема супер, решил посмотреть сразу не смотря на то что опаздываю на работу.
code smell тоже очень интересно
Отличное объяснение! Видео короткое, 15 минут. Но чтобы реально все из него осмыслить, нужно побольше времени))
Интересно было, хорошие примеры.
Ждём продолжения. Молодец Серёга.
Спасибо Вам большое) Очень интересно Вас слушать на эти темы. Примерно год назад слушал это видео, но был, как я сейчас понял, даже еще не новичком, а пересматривая сейчас, понимаю, что эти принципы очень даже логичны и даже не осознанно сам так делаю) еще раз спасибо Вам за такие видео, однозначно лайк )
Всё интересно. И про запахи и про всё остальное! Ждём-с )
Спасибо за такое подробное объяснение принципов SOLID!
Хорошо, что перешли к техническим видео, не помешает.
Ждем про code smells! Спасибо за видео
Сергей, огромное спасибо за видео! Очень подробно и понятно! Вы отлично умеете объяснять
13:10 - не, ну чё сразу котики, я вот Немчинского смотрю)
а вдруг он тоже котик?
@@Mr43046721 он лиса
Denis ору)
Спасибо. Очень познавательно и, главное, понятно.
Ну наконец-то. Хоть кто-то использует адекватные примеры. А то везде натыкаюсь на примеры, от которых возникает только один вопрос: "как про такую чушь бесполезную столько книг понаписали?"
Теперь хоть понятно, что и так всегда его использовал)
Спасибо
Круто! Спасибо. Самое главное что в подаче материала нет заумных терминов/слов.
Браво 👍❤ жду продолжения
Спасибо за видио! Интересное тема, жду продолжения
Круто, жду продолжения. И про запахи кода тоже жду.
зеленый маркер, на белом фоне, и освещением. почему сразу желтый или белый не взять?
🤣
Это фишка Немчинского, так сказатб.
Постоянно жалуются, что текст не видно.
К чему изменять традициям)
@@furrai Не фишка, а принцип ))
Отличное видео, продолжайте. И да, не стесняйтесь длинных видео.
Сергей, предлагаю новую рубрику: рефакторинг с Сергеем Немчинским. Чтобы на практике увидеть "code smells" и как с ними бороться. У вас охрененный опыт, мне кажется он максимально раскроется в таком формате.
Супер! Как же дождаться последнего принципа теперь...
Всё интересно! Всё делайте!
Очень интересно. Про анти-паттерны прям надо!!!
Спасибо за детальное видео. Видимо придётса смотреть раз 10 что бы запомнить а затем через пол года забыть.
Идеальный формат, быстро и доходчиво!
Большое спасибо за выпуск!!!
Хороший принцип. Я часто встречал разработчиков, которые считали, что применение этого принципа усложняет код: грубо говоря, вместо одного класса получаем два. Приходилось долго убеждать.
тема определенно интересна, хотелось бы побольше таких видео - коротенько, суть, так сказать. Ведь самое сложное - дойти до простого. Когда большой тутор новичок теряется. Важно сначала понять суть, а потом уже можно вникать в детали. А у Сергея очень хорошая подача, что тоже очень важно
Ждал это видео от вас, еще не смотрел но уже знаю что все будет на уровне)))
Спасибо за видео. Нужно продолжение!))
Спасибо, ждём продолжения
Про котиків і соцмережі- це ваще крутяк. Сміюся)))
Спасибо, Сергей. Замечательное дополнение к книге дяди Боба.
Кайф, только сколько не смотрю семенары с вашим участием всегда не видно что вы пишете на доске) а так все очень доходчиво и понятно, спасибо)
Пеннивайз реально годноту делает. Лайк подписка!)
Зашёл чтобы лайкнуть серьёзную тему на канале
Так спокойно и размеренно все объясняешь. Хоть для медитации включай)
Спасибо Сергей, еще не смотрел,но я думаю это будет отличное объяснение👍🏻👍🏻👍🏻👍🏻👍🏻
ооо, вот это действительно классная тема ))))) спасибо, за Ваши видео ))))))
Очень круто! Спасибо за видео.
Спасибо за видео!
Как говорил мой преподаватель в универе - Код должен сначала заработать у вас в голове, а уже потом в калькуляторе))
ИМХО, лучше всего думается на теплом песочке, рисуя палочкой))
Ураааааааа))))Спасибо, дождались наконец-то)
Спасибо) это интересно и про code smells тоже было бы интересно послушать)
Запах кода очень интересно)
Очень интересно. Жду продолжение
Очень интересное видео. Да, хотелось бы ещё цикл видео про рефакторинг.
Это любимая тематика видео
Супер! Продолжайте
Спасибо! Я тоже программист с большим опытом (вероятно, не меньшим, чем у автора), и не то, чтобы меня настигло откровение в этом видео, но ещё разок вспомнить основы, рассказанные с чуть нового угла - всегда полезно и приятно.
Огонь тема! Продолжайте!
Да всё интересно, всё записывайте!
Очень информативно, интересно смотреть про паттерны с такой визуализацией, одно пожелание, поменять цвет маркера на черный
Супер. Ждем все принципы)..
Интересно, спасибо Сергей!
Поддерживаю идею запилить видео про Code smells
Дичайше интересно, спасибо!
На самом деле SRP говорить о том, что класс должен использоваться только для одного actor (пользователя/группы пользователей). В этом видео описание больше похоже на ISP, но если быть точнее, то это принцип согласованной абстракции (Совершенный код Стив Макконелл) (не SOLID)
О! Класс! Большое спасибо!!!:)
Супер. Спасибо. Ждемс еще
Спасибо огромное за видео по SOLID, сейчас прохожу обучение и надо во всем этом разобраться.
Спасибо вам за ваше видео!
Спасибо. Данная тематика интересна)
Тема очень важна и подача хороша.Ждем скорее продолжения)Спасибо) Еще ,если будет время,интересно послушать о ЛЯМБДА-ВЫРАЖЕНИЯХ и ФУНКЦИОНАЛЬНЫХ ИНТЕРФЕЙСАХ. Еще интересно послушать о классах String Builder и String Buffer. Про многомерные массивы и еще куча всего)))
Сергей, благодарю!
Видео хорошее, я хотел бы увидеть больше подобных видео
Супер-пупер интересно, спасибо)))