Посмотрел 2 часа, что скажу. Подача материала раскрывается последовательно, всё поделено на таймкоды. Каждый принцип SOLID раскрывается последовательно и что самое отличительное - это универсальность материала под различные языки программирования. То есть это, своего рода, технический альманах, к которму можно переодически возвращаться для того, чтобы освежить память по различным стратегиям проектирования. Кароче полезность материала прямо пропорциональна крутости шрифта помноженного на бесконечность в квадрате. Благодарю автора за усилия, и за таймкоды отдельно thankful.
Не передать того восторга, который испытал я совместно со своим одногруппником при просмотре данного видео, хотя я скорее назвал бы это полноценным лекционным материалом. Автор четко ответил на все вопросы к теории архитектуры, которые могли быть у студента 4 курса. Такого концентрированного материала не хватало мне на протяжении последнего года и неоднократных попыток самому разобраться в чистой архитектуре. Хочется отметить теорию интерфейсов, которую тщательно объяснял автор. Буквально открытие истинного взгляда на интерфейсы, как на контракты между функциональными модулями, позволило легко воспринять все последующие виды архитектур. Также это позволило лучше определить связь между разработкой архитектуры ПО в контексте программирования и моделированием информационной системы в контексте бизнес анализа. Ни могу не отметить, верно поданную концепцию функционального программирования и то, какое отношение она имеет к разработке и проектированию ПО любой сложности. Это, прямо говоря, заставило переосмыслить прошедший курс функционального программирования на Лиспе, где упор делался на синтаксис языка, нежели ценностях и возможностях данного подхода. Еще раз скажу большое спасибо за этот головокружительный материал. Хотелось бы увидеть меньше повторов ( хотя для формата лекций, это только плюс ) и больше Практического материала или ссылок на хорошие примеры в открытом доступе для самостоятельного изучения.
Все таки я очень рад, что есть люди, которые в полной мере поняли меня, а не смотрели на речь или сравнивали с конкретными определениями. Спасибо большое
@@koduryem Вам спасибо конечно же. Сейчас посмотрел комментарии, не вижу причин как-то придираться к конкретным сравнениями или речи, когда важная сама суть и то как она усваивается. Вы на протяжении всего ролика повторяете некоторые вещи многократно и с разных ракурсов, и это хорошо. С таким подходом можно понять суть вещи и идею, которую хочет преподнести автор. В процессе обучения в вузе я много раз видел, преподавателей, которые пытаются мимолетно схватится за определения не раскрывая суть вопроса или раскрывая его так, что потом из 100 студентов дай бог поймет 3-4, но при этом уже пытаться перейти на менее существенный вопрос из-за чего в голове у студентов каша, а знаний нет.
Чтобы посмотреть это видео у меня ушло две недели) Это хорошо структурированные практические знания по архитектуре. Именно то, что было нужно. Моё почтение автору за то, что всё подано в одном видео, с самурайским терпением. Возможно, кого-то испугает 12 часов архитектуры. Интересно, а сколько времени у вас ушло бы чтобы изучить это на собственном опыте а затем записать видеоурок? Тысячи часов совершения ошибок и нахождения решений ужаты в 12. Это подарок всему миру разработчиков.
В процессе просмотра некоторые фрагменты воспринимались как фильм ужаса с флешбеками из прошлого Бывало и так, что реализуешь интерфейс «на будущее», а при следующем рефакторинге его полностью выпиливаешь... Огромный труд, спасибо за видео, под него очень хорошо думается о своей кодовой базе.
Сразу лайк не глядя это видео. Но посмотрев монументальный гад - "Как решать задачи на Leetcode(+полный гайд, работа..." могу с уверенностью сказать, что и здесь будет полных 11 часов годноты!!! Артем, ты лучший! )
@@mobilitymoon5232Этим ты помогаешь комьюнити, ведь наймут другого с +30% зарплатой и у него будет работы много переписать все с году сказав что технический долг не подъемный) и так по кругу)
Как давно я ждал что-то подобное . Спасбо за труд) Буду наверно дополнять свой комментарий с просмотром. Половину уже посмотрел и хочу сказать что видос полезен на 1000% , такой материал даже на eng языке не найдёшь. Честно я очень довно искал материал по поводу чистого кода. И книжка Стива Макконнелла - Совершенный код не дала мне той базы которая есть тут. Хочу ещё раз сказать автору спасибо за информацию которая поможет стать професионалом в IT
И так я досмотрел видео курс честно до конца, без пропусков. Во-первых скажу большое спасибо автору за проделанную отличную работу! Лично для меня видео крайне полезное, конечно многое из паттернов и принципов я знал, но благодаря этому видео я как бы закрыл какие-то пробелы что-ли или посмотрел на что-то с другой стороны. Так же полезны советы в области инкапсуляций с выводами апи, чистых функций, абстракций/дженериков и конечно low coupling & high cohesion. Для тех кто не смотрел крайне рекомендую, будет полезно.
Не знаю написал ли кто, в целом можно сказать что это описание Clean Code здорового человека) За почти 15 лет в IT в 95% сталкивался именно с black/white подходом)
Инфа просто на вес золота! Это прям то что надо! Пушка-бомба, всё просто, понятно и по сути. Огромная работа проделала. Чел, мега-респект тебе. Лайк и подписка однозначно!
Я как включил, услышал:"В этом видео мы поговорим про чистую архитектуру и чистый код", сразу подумал, что-то тут не чисто... очень испугался 12часового видоса ) ну будем смотреть 😅
Спасибо! Очень полезно было. Я бы еще посоветовал сделать пример проекта с применением ports/adapters архитектуры. Ты абсолютно правильно сказал - что многие слышали (не слышали) про это и что это такое вообще - лучше писать как знаю). Это теория, и если внимательно (вдумчиво) посмотреть, то можно сказать - да ок понятно. Вот на 100% уверен, что если кто решит - а давай я сяду и попробую это сделать на простом проекте - не получится. И чел забьет, и будет опять - лучше писать как знаю. Такой материал ты выдал классный, надо еще пример дать чтоб зря не было) Еще бы и на двух разных языках ООП (Java например) и не ООП (JS на пример) - это две разные песни будут. Это просто мой feedback, мысли. Очень часто с этим сталкиваюсь, когда люди с опытом не могут написать используя эти подходы (SOLID, Clean Architecture), пытаешься что-то обьяснить - говорят что сложно, лучше как всегда, потому что придут новые люди и не поймут) Вообщем спасибо за видос, за передачу опыта!
Я досмотрел 🎉 Спасибо за труд! Но я заметил что много тем имеют разные название, но суть очень похожа. Наверное это можно тоже как то оптимизировать и декомпозировать.
крутое видео, долго искал что-то по архитектуре и вот нашлось! Типо я чувак с 1 г комм. опыта на js и мне прям вкатило. Про солид 90% понятно, типо я уже 3 часа просмотрел, прям кайф, ещё и с картинками прям шик. За видос спасибо. Двигаем дальше - ещё 8 ч осталось (уже 6)
Ого, очень мощное видео. Посмотрел уже 3 часа, очень хорошо и увлекательно рассказываете. Презентация так вообще стильная и приятная глазу. Огромное спасибо за труды
Дальше уже менее психологически и абстрактно и больше примерчиков и картинок, универсальных. Все остальное везде разное может быть гайдлайны и тд, поэтому такое не включал
Сначала: не давайте больших имён функциям/классам, их сложно читать Потом: называем функцию PrintValidTicketsWithMultipliedAmount :D А вообще, огромное спасибо, невероятный труд. Даже те кто смог посмотреть от начала до конца заслуживают лайк, что уж тут говорить об авторе
Привет, спасибо за доклад буду дополнять по мере просмотра остановился на 1:55:15 Неточности на мой взгляд: 0. Про моделировании неплохобы было обозначить что есть акторы, сущности которые взаимодействуют с обьектами и на этапе дизайна их нужно найти например бухгалтер, учитель, ученик. 1. SRP - это про акторов, как по мартнину его же аббревиату́ра, тоесть лицо или группа лиц которая будет взаимодействовать с обьектами и заинтересованны в их изменении, а не про одну ответственность и чистые функции без сайд эффектов. 2. OCP - ну тут борщ вообще с функциями и фильтрами))), по тому же мартину, написал класс его методы нельзя модифицировать потому что они много где используются в коде и будут проблемы это закрытость, нужно добавлять новые методы что и есть открытость.
Привет. Ты тут не прав и упустил весь посыл с первых слайдов, потому что мы не фокусируемся ровно на каких-то определениях Мартина. Это тупиковый путь и black-and-white thinking, fixed mindset. В этом случае, мы не можем нормально накладывать, видоизменять и подстраивать под конкретную ситуацию. Я об этом как раз и говорил в начале и ты бам и попал в эту "ловушку точных определений". Ну и чистые функции без side effects не обязательно привязывать именно к SRP. Постарайся быть более гибким и внимательным. "Борщ с фильтрами" - та же самая ловушка и мышление в частных случаях и четких определениях. Плюс, некоторая насмешка не к месту. Это почти всегда ведет к проблемам в итоге. Что я свидетель, что множество других людей. Нужно мыслить более универсально, абстрактно, гибко и накладывать паттерны и принципы под конкретную ситуацию. А не пытаться заучить правило и впихивать везде. Это тупик мышления. Если хочешь критиковать, постарайся, пожалуйста, учитывать эти факторы, раз мы их обсудили уже в начальных слайдах. Иначе, получается, что мы будем говорить на разных языках и мне придется парировать те когнитивных заблуждения, про которые я предупреждал изначально и которые не имеют смысла. И я вижу, что весь мой изначальный посыл прошел мимо. Принципы - это не жесткие определения "делай так" и "Мартин сказал так". К слову, Мартин со мной согласен и много писал об этом. Просто люди идут по легкому пути lazy thinking и пытаются найти жесткие правила и определения, которые "бери и применяй вот так и спина болеть не будет". Сложные и изменяющиеся системы и окружающий мир так не работают. Я буду рад, если ты немного переосмыслишь взгляды на более абстрактные и гибкие. Это была одна из целей видео и я немного расстроен, что не удалось ее передать с таким огромным количеством примеров :(
@@koduryem вот в этом и проблема через чур обильная гибкость и изменчивость и получается что трактовать одно и тоже можно несколькими способами и отсюда понимание совершенно разное Для этого же вводили например паттерны чтобы все знали что есть синглтон и это один экземпляр сущности Другого описания тут нет и можно всем говорить сделай мне синглтон и он сделает именно его, а не два вложенных списка из алфавита Возьмем другой пример с собеседованием на котором тебе задают вопрос что такое молоток? - Ну это инструмент которым я буду писать код - Вообщето это инструмент которым можно забивать гвозди - Ну это у меня широкий майндсет, я не мыслю рамками Я думаю что в глазах собеседующего это будет не совсем адекватно, правда? Не брать такого человека на работу Другой пример на заправке можно сказать заправьте мне топливо А какое: бензин 92, 95, 100, этиловый спирт, дизель и тут гибкость вообще не к месту Четкое определение это всегда ответственность, а размытое определение это перекладывание понимания на слушателя Ты определенно на другом уровне и возможно я пойму твою мысль через время P.S. О терминах не спорят, о терминах договариваются
@@Oleg_Zhigulin ты как-будто на правильном пути; оно гибко да, но его можно представить в виде generic format, который легко свести к частным случаям в любой конкретной проблеме. Что я и сделал - показал generic мышление и потом много разных примеров и для функций, и для классов и для более high level арх-ры. Я делал акцент на этом на протяжении всего видео. Не нужно запоминать наизусть определения и частные случаи. Это не работает.
@@Oleg_Zhigulin Можно менять не только задачи, но уровень абстракции и принципы still валидны там и можно применить, с небольшой вариацией и подстройкой (что неизбежно и бороться с этим бесполезно и применять одно частное правило на все случаи без модификаций, что делать пытаются большинство)
Спасибо автор! Интересно а сколько времени ушло на создание тайм кодов? Нужно ли было пересматривать свое видео в 11 часов, или все было продумано на стадии планирования?
А можно сказать что open-closed еще и про то, что мы не должны менять базовый класс, а вместо этого должны сделать чайлда и ему добавить методы. Например, как на 2:04:22 - базовый person с методом eat, его наследует warrior, который сохраняет eat, но также добавляет figth - это является примером open-closed?
Спасибо за видео, уже в который раз убедился, что лучшая система это та где есть слой который абстрагирует доступ к какому то модулю. Абстракция занимация вызовом методов. Типа забор.
Спасибо за это видео. Попробуй низкие частоты срезать эквалайзером и использовать какие-то плагины по типу izotope rx de click или wawes x click, потому что когда ты тянешь "ааааааааа", у в записи явно выраженный треск твоего горла, не знаю как лучше это объяснить
Соглашусь с подходом One line one statement. Проблемы в приведенном примере на 3:53:30 принципиально не отличаются от цепочки вызовов через Pipeline. Получается цепочки вызовов тоже лучше не использовать? Типа такого: $this->doSomething()->doAnotherThing()->doYetAnotherThing();
Можно по ситуации. Это же не жёсткие правила. Просто так удобнее отлаживать и поддерживать и в кратковременной памяти держать. Я против жёстких правил. За гибкость.
1:50:52 "Функции сходятся". Очень важно понимать, что не всегда. И иногда это даже вредно. Пример. Вы пишите функцию для CAD - исчезновения объекта со сцены. Юмор в том, что это можно сделать как минимум двумя способами. Либо исправить геометрию на следующем кадре - убрать из списка прорисовки данный объект, либо поставить флаг, чтобы временно не рисовать объект шейдером - изменить параметры шейдера. Если объект удалён на долго то используем первый метод, если это моргание - второй. Но проблема в том, что события прорисовки, шейдер и геометрия это по любому разные сущности. Притом даже физически, а не только в коде - цпу/гпу. И как следствие, попытка написать универсальный метод исчезновения, не учитывая домейн может привести вас к тому, что будут созданы либо лишние сущности, либо вообще появится сцепление. Разумеется это решается просто разными "видами" исчезновения/удаления. Но дело в том, что для этого вам придётся понимать реализацию, которая тут домейн. То есть ваш домейн на более низком уровне абстракции. Очень часто именно домейн делает не применимым солид принципы. Мне кажется это хорошим примером того, где может проходить зона применимости принципа.
Нет противоречий. Солид Это не физическое разбиение всегда, когда только можно, всего, что можно, а использование таких моделей и уровне ней абстракции, которые применимы в каждом конкретном случае по параметрам, которые я расписывал ранее. Запомни, солид - не жёсткие правила "вот так делай", а принципы и рекомендации, которые записями от места применения и подстраиваются под них с помощью абстрактного и гибкого мышления. То, что ты описал и есть солид. А почему это так мы обсудили а начале видео. Это не про только функции и классы и интерфейсы
@@koduryem запомнил. 6 лет учился у универе - помнил. 7 лет писал кад систему с qt, python и низкоуровневым рендором - помнил. Вот щас забыл. Но автор напомнил. Теперь не забуду.
Если я тебя как-то задел, сорри. Просто увидел противоречие с тем, что я говорил и указал на это. Твоё мнение и опыт безусловно важны и ценны. И про них я ничего не говорил. Твоё мнение также было важно и я уделил время и разобрал его. Если не согласен - имеешь право. Я вижу ты отличный специалист с большим опытом, к которому я прислушиваюсь
@@koduryem дело не в обиде, а в том, что у вас язык "не обычный". Так и хочется подколоть. Вызвать реакцию. Обычно язык людей которые преподают этого лишён - он более сухой. Вы самоучка?
Автор молодец, большой был труд проделан по рассказу по чистой архитектуре. Только к видео применил антипаттерн "монолит", сделав одно видео на 12 часов. А как же выделение модулей, плейлиста и прочих принципов про которые ты говорил?
Грандиозная работа. По сути изложение идей из книг Фаулера, Мартина, а также хорошие практики из опыта, но в формате видеолекции. Не знаю, правда, насколько это будет доступно к пониманию новичкам, скорее, для более менее опытных разработчиков, т.к. все излагается на уровне абстракций (что хорошо). Недавно тут была статья на хабре (ссылки нету, можно поискать), где описывалось, как один парень зарубился с Мартином, мол, чистый код - такое себе. Оригинал не читал, объектьивно оценить доводы тяжело, но из самой статьи сложилось мнение , что тот парень или из "черно-белой секты", или просто решил хайпануть, но приведенные доводы вообще были ни о чем (на мой взгляд). К чему это я? К тому, что изложенные в видео мысли на практике действительно очень полезны на больших энтерпрайз-проектах, и не как свод правил, а именно концептуально. P.S. "Перевод каретки" ... аж нафталином запахло )) P.P.S. Ага, в телеге предпоследнее сообщение, похоже, именно про "того парня".
Каждый раз убеждаюсь что SOLID это про то сделать код в 10 раз более сложным и в 100 раз более медленным. Вы объясняете как сделать тривиальные вещи невероятно сложным способом, похоже на Rube Goldberg machine.
В точности наоборот объясняю. И не говорю, как "правильно делать и только так", а когда где и почему и в какой ситуации. И почему именно там именно оно надо и другое хуже будет. Будь внимательней, а то как-будто не смотрел, а мнение составил :)
@@koduryem вы объясняете очень хорошо, просто xyzwio не имеет достаточного опыта и предварительных базовых знаний для того, чтобы вникать в эту тему. С моим опытом (а это посмотрел и переписал пару приложений на чистой архитектуре, еще нет опыта работы), всё хорошо заходит и структурируется в голове. Кстати, Вы не ответили на мой вопрос, к сожалению, про то, как можно получить слайды из видео. Спасибо.
@@koduryem Спасибо что ответили! Мой комментарий был через чур эмоциональный. Не думаю что формат YT комментариев подойдет для таких дискуссий. Позиция которая мне ближе всего в этой теме хорошо изложена в видео "Clean Code Horrible Performance".
Видео довольно манипулятивное и рассматривает искусственный пример, оторванный от реальности. 1) "they tell you never ever do that" - кто "they"? Анкл боб сам же пишет - используй свитч, если удобно и размер проекта позволяет. Об этом и я говорил тоже. Почему "они" так говорят - первые темы, про которые мы говорили об ограниченности мышления и желания взять 1 инструмент и везде его использовать. Мы не рассматриваем серьезно такие вещи. "они говорят" - не конструктивно и biased, направлено на создание того восприятия, которое он хочет 2) Что такое "clean code" - он дал свое манипулятивное определение без каких-либо оснований и аргументов ("вот так полиморфизм заюзаешь вместо свитча - это и есть clean code"). Это уже нивелирует все, что он говорит. Я дополнительно делал акцент на том, что clean code - не инструмент "делай вот так", а принципы, применяемые в нужном месте и время, по ситуации, при эволюции кода. Этот же его код в маленьком проекте будет "clean", а на сотни тысяч строк оно становится big ball of mud, который можно просто выкинуть. Но, кто бы знал что за деревьями есть лес. 3.1) Он на серьезных щах сравнивает разницу между 35 vs 25 cpu cycles. Буквально, 1 cpu cycle on 4Ghz processor == 0.25ns => 35 * 0.25 vs 25 * 0.25 => 8.75ns vs 6.25ns. Это уже просто смешно. В добавок, это сравнение идет при прогоне бесполезной программы 1000 раз карл! Если мы, например пишем любой бекенд, шанс, что твой workflow прогонит разного рода объекты 1000 раз очень мал. И даже если вдруг, то.... 9 НАНОСЕКУНД . Такое можно еще считать , если мы ракетостроением занимаемся или жесткими embedded (и то современные ембеддед типа телефонов и планшетов даже не заметят этого). Значит, прогнать подобное 1 000 000 раз будет 90 нс, 1 000 000 000 раз - 1мс. Часто, если у нас бд, к примеру, наш запрос может отработать и за 100-300мс, что вообще 10^8 больше, чем он прогоняет 1000 раз свои объекты для вызова 1 метода => это просто капля в море. Могу миллиарды раз так гонять, и пользователь не заметит даже. 3.2) Код стал хуже читаться, поддерживаться, на мастшабах это может убить проект (десятки тысяч строк мб еще ничего или если это инкапуслировано в одном модуле). Теперь каждое место по всей программе должно знать ВСЕ типы объектов, чтобы написать логику. И все поля структуры, чтобы писать логику. Мы не можем просто принять интерфейс и вызвать метод. Нет. Теперь пиши функции и там перебирай все типы объектов. А если что поменяется - меняй их ПО ВСЕЙ программе (представьте в сотне тысяч строк поменять). В своем и даже абсолютно чужом коде, где ты без понятия, что люди делают и как и что изменить надо правильно. Nice. 4) Подумайте, почему комменты закрыты полностью? Хоть бы позитивные оставил, мы бы advantages от туда взяли. 5) Оптимизации со switch -> hash table не всегда возможны и нужны. Только в узких моментах. Эта оптимизация абсолютно бесполезная, если у нас бизнес логика, а не программирование микроконтроллеров. Хотя, я так иногда тоже делаю, где возможно. Но не для мега оптимизаций, а читаемости кода или удобства. 6) Подобный подход "в лоб" можно использовать, при разработки в agile style (и мы так делали в видосах). Без лишних абстракций и тд. Когда маленький проект и оч мало людей на нем (1-2-3). Все работает, быстро. ок. Скрыто в небольшом модуле. Ок. Легко понять, читать много не нужно. НО! Даже там мы не будем оптимизировать до талого код, который мы 100% удалим и поменяем на другой, когда проект начнет становиться больше. Или когда эти оптимизации не рациональны в нашей задаче (90% случаев). Значит, мы потратим очень много ресурсов на оптимизации, которые не нужны ни в проекте, ни бизнесу (пара наносек - это не о чем). Такими вещами типа байтодрочева занимаются в чрезвычайно узких местах. Человек не понимает, что код пишется не просто так и что его надо поддерживать множеству людей и команд. Что requirements у бизнеса в большинстве случаев не оптимизация до наносек. Не "скорость" ради скорости. А имплементация бизнес логики и решения задач ОПТИМАЛЬНО. Чтобы в этот код можно было легко вносить новые изменения и фичи, оптимальная скорость, минимум кода и cognitive complexity, чтобы команды не конфликтовали при разработке и тд. Если я на интервью скажу "я оптимизирую код по максимуму и если потом кто-то захочет что-то в нем изменить, ему надо будет перелопатить сотни тыщ строк и везде принять решение, что и как изменить, чтобы ничего не поломать; clean code говно; зато очень быстро будет!", скорее всего даже у hr'а, кто не в теме, случится когнитивный диссонанс. Если бы он просто сказал "ребят, вот такое мнение вот для такой конкретно задачи" - то ок. Ну, я тоже бывает ляпну что-то и как-бы не парюсь, не хочешь не делай. Когнитивное же искажение в виде генерализации с примесью манипуляций "вы видите, я взял пример на 200 строк и разбил эти ваши мифы про клин коды" - ну как-бы такое :)
если сейчас в 11 ночи начну смотреть то завтра к дейлику буду 10x разработчиком. спасибо!
5 дней уже прошло, получилось?
@@MentorOfMentorsвидимо нет, уволили
вмер
Я только начал, а ты то закончил?
Что в итоге?
Посмотрел 2 часа, что скажу. Подача материала раскрывается последовательно, всё поделено на таймкоды. Каждый принцип SOLID раскрывается последовательно и что самое отличительное - это универсальность материала под различные языки программирования. То есть это, своего рода, технический альманах, к которму можно переодически возвращаться для того, чтобы освежить память по различным стратегиям проектирования. Кароче полезность материала прямо пропорциональна крутости шрифта помноженного на бесконечность в квадрате. Благодарю автора за усилия, и за таймкоды отдельно thankful.
Забавно слышать в первые 30 секунд 12 часового видео "упрощать и декомпозировать большие системы"
Ух ты ж! Я было подумал, что час двадцать %) Надеялся за пару раз посмотреть 😊 Что ж, придётся поднапрячься и за недельку осилить.
@@DmitriNesterov Смотрю уже 3 часа. Я middle разработчик. Это переворот в сознании: обрывки знаний укладывает в голове. Напрягитесь, оно того стоит.
В том то и парадокс))
Человек, который объясняет какое-либо направление программирования с визуализацией в excaildraw по дефолту делает все верно! Труд монументальный)
люди не чувствую гармонию в информационных системах и это видео просто подарок тем кто пытается разобраться. спасибо большое
Не передать того восторга, который испытал я совместно со своим одногруппником при просмотре данного видео, хотя я скорее назвал бы это полноценным лекционным материалом. Автор четко ответил на все вопросы к теории архитектуры, которые могли быть у студента 4 курса. Такого концентрированного материала не хватало мне на протяжении последнего года и неоднократных попыток самому разобраться в чистой архитектуре.
Хочется отметить теорию интерфейсов, которую тщательно объяснял автор. Буквально открытие истинного взгляда на интерфейсы, как на контракты между функциональными модулями, позволило легко воспринять все последующие виды архитектур. Также это позволило лучше определить связь между разработкой архитектуры ПО в контексте программирования и моделированием информационной системы в контексте бизнес анализа.
Ни могу не отметить, верно поданную концепцию функционального программирования и то, какое отношение она имеет к разработке и проектированию ПО любой сложности. Это, прямо говоря, заставило переосмыслить прошедший курс функционального программирования на Лиспе, где упор делался на синтаксис языка, нежели ценностях и возможностях данного подхода.
Еще раз скажу большое спасибо за этот головокружительный материал. Хотелось бы увидеть меньше повторов ( хотя для формата лекций, это только плюс ) и больше Практического материала или ссылок на хорошие примеры в открытом доступе для самостоятельного изучения.
Все таки я очень рад, что есть люди, которые в полной мере поняли меня, а не смотрели на речь или сравнивали с конкретными определениями. Спасибо большое
@@koduryem Вам спасибо конечно же. Сейчас посмотрел комментарии, не вижу причин как-то придираться к конкретным сравнениями или речи, когда важная сама суть и то как она усваивается. Вы на протяжении всего ролика повторяете некоторые вещи многократно и с разных ракурсов, и это хорошо. С таким подходом можно понять суть вещи и идею, которую хочет преподнести автор.
В процессе обучения в вузе я много раз видел, преподавателей, которые пытаются мимолетно схватится за определения не раскрывая суть вопроса или раскрывая его так, что потом из 100 студентов дай бог поймет 3-4, но при этом уже пытаться перейти на менее существенный вопрос из-за чего в голове у студентов каша, а знаний нет.
Под этим видео нужно написать два комментария. Один до того как начал смотреть, а другое когда закончишь.
Включил, начал смотреть, поел, поспал, снова поел, вернулся к ноуту, а там всё ещё вступление... (
Чтобы посмотреть это видео у меня ушло две недели) Это хорошо структурированные практические знания по архитектуре. Именно то, что было нужно. Моё почтение автору за то, что всё подано в одном видео, с самурайским терпением.
Возможно, кого-то испугает 12 часов архитектуры. Интересно, а сколько времени у вас ушло бы чтобы изучить это на собственном опыте а затем записать видеоурок? Тысячи часов совершения ошибок и нахождения решений ужаты в 12. Это подарок всему миру разработчиков.
Большое спасибо :)
В процессе просмотра некоторые фрагменты воспринимались как фильм ужаса с флешбеками из прошлого
Бывало и так, что реализуешь интерфейс «на будущее», а при следующем рефакторинге его полностью выпиливаешь...
Огромный труд, спасибо за видео, под него очень хорошо думается о своей кодовой базе.
Это просто праздник какой-то🎉. Повезло, что кто-то или что-то сподвигло автора на труд его.
Пожалуйста, не забрасывай канал. Чувак, ты крутой! Круче только титановые яйца, да и то не факт )
Сразу лайк не глядя это видео. Но посмотрев монументальный гад - "Как решать задачи на Leetcode(+полный гайд, работа..." могу с уверенностью сказать, что и здесь будет полных 11 часов годноты!!! Артем, ты лучший! )
Господа, пишите красивый, читаемый и понятный другим людям код! Чтобы руководителю было проще вас заменить))
Да лучше писать лапшой и потом самому уволиться.
@@mobilitymoon5232Этим ты помогаешь комьюнити, ведь наймут другого с +30% зарплатой и у него будет работы много переписать все с году сказав что технический долг не подъемный) и так по кругу)
думаю если вы будете писать красивый и читаемый код, то руководитель сделает всё чтобы вы не ушли. Потому что другие будут писать нечитаемый код.
Быть или не быть)
Как давно я ждал что-то подобное . Спасбо за труд)
Буду наверно дополнять свой комментарий с просмотром.
Половину уже посмотрел и хочу сказать что видос полезен на 1000% , такой материал даже на eng языке не найдёшь. Честно я очень довно искал материал по поводу чистого кода. И книжка Стива Макконнелла - Совершенный код не дала мне той базы которая есть тут. Хочу ещё раз сказать автору спасибо за информацию которая поможет стать професионалом в IT
Очень хороший ру яз материал, приятно удивлён, спасибо.
Несколько недель и я осилил! Спасибо, очень полезно с точки зрения именно паттернов мышления
ура! я наконец всё посмотрел, аж 20 дней ушло))
Лучшее что я видел про архитектуру, спасибо!
И так я досмотрел видео курс честно до конца, без пропусков. Во-первых скажу большое спасибо автору за проделанную отличную работу! Лично для меня видео крайне полезное, конечно многое из паттернов и принципов я знал, но благодаря этому видео я как бы закрыл какие-то пробелы что-ли или посмотрел на что-то с другой стороны. Так же полезны советы в области инкапсуляций с выводами апи, чистых функций, абстракций/дженериков и конечно low coupling & high cohesion.
Для тех кто не смотрел крайне рекомендую, будет полезно.
Спасибо большое 🙏
спасибо большое за такой огромный труд, даже сложно представить сколько усилий и усердий нужно приложить, чтобы сделать такое полезное видео!
Вот это подарок, теперь знаю, чем буду заниматься ближайшие выходные, спасибо Вам огромное!
Не знаю написал ли кто, в целом можно сказать что это описание Clean Code здорового человека)
За почти 15 лет в IT в 95% сталкивался именно с black/white подходом)
Спасибо большое)
Спасибо за работу! Прикольное видео, улучшил структуру и дополнил свой склерозник. Это первое видео на данном канале и сразу такой вызов)
Спасибо) для меня оно тоже что-то вроде альманаха, чтобы быстро можно было вспомнить основные практические принципы и не утонуть в тонне теоретики :)
Инфа просто на вес золота! Это прям то что надо! Пушка-бомба, всё просто, понятно и по сути. Огромная работа проделала. Чел, мега-респект тебе. Лайк и подписка однозначно!
Спасибо большое :)
Спасибо вам за ваш труд❤
11 часов годноты, это я смотрю и на тебя я подписываюсь!
Я как включил, услышал:"В этом видео мы поговорим про чистую архитектуру и чистый код", сразу подумал, что-то тут не чисто... очень испугался 12часового видоса ) ну будем смотреть 😅
Огромное спасибо за проделанную работу, рили очень круто, скачал себе на комп, буду показывать внукам)
Очень фундаментально. Очень интересно. Всё по делу и без лишней воды. Зашло. Лайк, подписка на канал и комментарий для продвижения.👍👍👍
Человек снял видео за 4 футболки!
То чуство когда хотел посмотреть все видео в течении недели, но все ещё на находишься на 1 футболке спустя 3 недели...
@@arturogatti914 Для такого видео - это нормально, если вдумчиво смотреть
Огромный труда, великолепное видео, спасибо большое автору за проделанную работу!
Спасибо! Очень полезно было.
Я бы еще посоветовал сделать пример проекта с применением ports/adapters архитектуры. Ты абсолютно правильно сказал - что многие слышали (не слышали) про это и что это такое вообще - лучше писать как знаю).
Это теория, и если внимательно (вдумчиво) посмотреть, то можно сказать - да ок понятно.
Вот на 100% уверен, что если кто решит - а давай я сяду и попробую это сделать на простом проекте - не получится. И чел забьет, и будет опять - лучше писать как знаю.
Такой материал ты выдал классный, надо еще пример дать чтоб зря не было)
Еще бы и на двух разных языках ООП (Java например) и не ООП (JS на пример) - это две разные песни будут.
Это просто мой feedback, мысли. Очень часто с этим сталкиваюсь, когда люди с опытом не могут написать используя эти подходы (SOLID, Clean Architecture), пытаешься что-то обьяснить - говорят что сложно, лучше как всегда, потому что придут новые люди и не поймут)
Вообщем спасибо за видос, за передачу опыта!
Шикарный контент, продолжай в том же духе👍
Лучше 1000 книг!
Спасибо тебе за это! Просто спасибо!
Взял отпуск чтобы посмотреть до конца 😂
Я досмотрел 🎉
Спасибо за труд! Но я заметил что много тем имеют разные название, но суть очень похожа.
Наверное это можно тоже как то оптимизировать и декомпозировать.
11 часов. афигеть. насколько же чиста эта архитектура? напишу коммент и скажу что со мной стало по оканчанию просмотра видоса
крутое видео, долго искал что-то по архитектуре и вот нашлось! Типо я чувак с 1 г комм. опыта на js и мне прям вкатило. Про солид 90% понятно, типо я уже 3 часа просмотрел, прям кайф, ещё и с картинками прям шик. За видос спасибо. Двигаем дальше - ещё 8 ч осталось (уже 6)
Спасибо)
Офигеть, 11 сурено-минут. Большое спасибо
Ого, очень мощное видео. Посмотрел уже 3 часа, очень хорошо и увлекательно рассказываете. Презентация так вообще стильная и приятная глазу.
Огромное спасибо за труды
спасибо. Я пока ничего не понимаю поэтому оценю оформление - оно топовое )
Начал смотреть - 25.09.2024
@@abilvap5611 ping
Дошёл до буквы О, буду держать в курсе
Where can i read it from? Could i get a link or something please.
Смотрел примерно 2 недели по чуть чуть. Досмотрел, приисполнился
Начал смотреть час назад, пока все супер и понятно🙌🏻 надеюсь дальше будет так же)
Дальше уже менее психологически и абстрактно и больше примерчиков и картинок, универсальных. Все остальное везде разное может быть гайдлайны и тд, поэтому такое не включал
@@koduryem спасибо большое за такой труд💪🏻
Сначала: не давайте больших имён функциям/классам, их сложно читать
Потом: называем функцию PrintValidTicketsWithMultipliedAmount :D
А вообще, огромное спасибо, невероятный труд. Даже те кто смог посмотреть от начала до конца заслуживают лайк, что уж тут говорить об авторе
Та знаю. Хотелось именно смысл передать как можно назвать вообще. Если идей короче нет, то ок :)
лайк за такой крутой бесплатный но на самом деле бесценный образовательный контент
Начинаю смотреть!
Не, ну за недельку я думаю смогу посмотреть) лайк не глядя
Лайк не глядя. Буду смотреть дробно и с пометками, спасибо!
Привет. А как можно получить эти слайды?
Привет, спасибо за доклад
буду дополнять по мере просмотра остановился на 1:55:15
Неточности на мой взгляд:
0. Про моделировании неплохобы было обозначить что есть акторы, сущности которые взаимодействуют с обьектами и на этапе дизайна их нужно найти например бухгалтер, учитель, ученик.
1. SRP - это про акторов, как по мартнину его же аббревиату́ра, тоесть лицо или группа лиц которая будет взаимодействовать с обьектами и заинтересованны в их изменении,
а не про одну ответственность и чистые функции без сайд эффектов.
2. OCP - ну тут борщ вообще с функциями и фильтрами))), по тому же мартину, написал класс его методы нельзя модифицировать потому что они много где используются в коде и будут проблемы это закрытость, нужно добавлять новые методы что и есть открытость.
Привет. Ты тут не прав и упустил весь посыл с первых слайдов, потому что мы не фокусируемся ровно на каких-то определениях Мартина. Это тупиковый путь и black-and-white thinking, fixed mindset. В этом случае, мы не можем нормально накладывать, видоизменять и подстраивать под конкретную ситуацию. Я об этом как раз и говорил в начале и ты бам и попал в эту "ловушку точных определений".
Ну и чистые функции без side effects не обязательно привязывать именно к SRP. Постарайся быть более гибким и внимательным.
"Борщ с фильтрами" - та же самая ловушка и мышление в частных случаях и четких определениях. Плюс, некоторая насмешка не к месту. Это почти всегда ведет к проблемам в итоге. Что я свидетель, что множество других людей. Нужно мыслить более универсально, абстрактно, гибко и накладывать паттерны и принципы под конкретную ситуацию. А не пытаться заучить правило и впихивать везде. Это тупик мышления.
Если хочешь критиковать, постарайся, пожалуйста, учитывать эти факторы, раз мы их обсудили уже в начальных слайдах. Иначе, получается, что мы будем говорить на разных языках и мне придется парировать те когнитивных заблуждения, про которые я предупреждал изначально и которые не имеют смысла. И я вижу, что весь мой изначальный посыл прошел мимо.
Принципы - это не жесткие определения "делай так" и "Мартин сказал так". К слову, Мартин со мной согласен и много писал об этом. Просто люди идут по легкому пути lazy thinking и пытаются найти жесткие правила и определения, которые "бери и применяй вот так и спина болеть не будет". Сложные и изменяющиеся системы и окружающий мир так не работают.
Я буду рад, если ты немного переосмыслишь взгляды на более абстрактные и гибкие. Это была одна из целей видео и я немного расстроен, что не удалось ее передать с таким огромным количеством примеров :(
Да, если же ты не согласен полностью енивей, то это тоже окей. У каждого есть право на свое мнение. Это нормально!
@@koduryem вот в этом и проблема через чур обильная гибкость и изменчивость и получается что трактовать одно и тоже можно несколькими способами и отсюда понимание совершенно разное
Для этого же вводили например паттерны чтобы все знали что есть синглтон и это один экземпляр сущности
Другого описания тут нет и можно всем говорить сделай мне синглтон и он сделает именно его, а не два вложенных списка из алфавита
Возьмем другой пример с собеседованием на котором тебе задают вопрос что такое молоток?
- Ну это инструмент которым я буду писать код
- Вообщето это инструмент которым можно забивать гвозди
- Ну это у меня широкий майндсет, я не мыслю рамками
Я думаю что в глазах собеседующего это будет не совсем адекватно, правда? Не брать такого человека на работу
Другой пример на заправке можно сказать
заправьте мне топливо
А какое: бензин 92, 95, 100, этиловый спирт, дизель и тут гибкость вообще не к месту
Четкое определение это всегда ответственность, а размытое определение это перекладывание понимания на слушателя
Ты определенно на другом уровне и возможно я пойму твою мысль через время
P.S.
О терминах не спорят, о терминах договариваются
@@Oleg_Zhigulin ты как-будто на правильном пути; оно гибко да, но его можно представить в виде generic format, который легко свести к частным случаям в любой конкретной проблеме. Что я и сделал - показал generic мышление и потом много разных примеров и для функций, и для классов и для более high level арх-ры. Я делал акцент на этом на протяжении всего видео.
Не нужно запоминать наизусть определения и частные случаи. Это не работает.
@@Oleg_Zhigulin Можно менять не только задачи, но уровень абстракции и принципы still валидны там и можно применить, с небольшой вариацией и подстройкой (что неизбежно и бороться с этим бесполезно и применять одно частное правило на все случаи без модификаций, что делать пытаются большинство)
Такой контент и бесплатно, ещё бы ссылку на эту презентацию и вообще идеал.
Воин, кто ты ? :) Спасибо, брат
Ждем тайм-коды ко всему видео 😁
Сделал)
@@koduryemБольшое спасибо за старания♥️
Пока только полтора часа просмотрел . Полет пока отличный
11 часов? Сильно. Лайк только за это 🙂
смотрел на скорости 2 и ништяк
Классный материал конечно, спасибо!!!
Пожалуй начну смотреть и планирую досмотреть за N подходов
Лайк за старание , 11 часов это жестко. 😂😂😂
Очень классное видео. Спасибо!
Было бы круто иметь доступ к рисункам Excalidraw.
всегда актуально , спасибо
Очень круто, респект! Завтра начну смотреть
сильно мужик, спасибо большое!
я рада, что нашла твой канал! лайк
Заходите, будьте как дома 🏘️ :)
Я начал смотреть
Это видео выглядит, как вызов "попробуй досмотри меня".
Ну что вызов принят, штурмую.
Нереально круто
Спасибо автор! Интересно а сколько времени ушло на создание тайм кодов? Нужно ли было пересматривать свое видео в 11 часов, или все было продумано на стадии планирования?
Не очень много, но пришлось машинально проставить. Я примерное помнил, где что, плюс есть план
невероятно полезны материал! Cпасибо автору
А где можно взять идеи для пет проекта, чтобы поприменять все техники и паттерны?
ооо, архитектуровое
спасибо за вкуснятину
что бы посмотреть сразу такой курс нужно совершить 12й подвиг Геракла ))
Представь, сколько сил ушло, чтобы его сделать :)
@@koduryem Это вообще ужас )) много сил и энергии ушло ))
Спасибо за труд, мегаполезно
Пасиб)
А можно сказать что open-closed еще и про то, что мы не должны менять базовый класс, а вместо этого должны сделать чайлда и ему добавить методы.
Например, как на 2:04:22 - базовый person с методом eat, его наследует warrior, который сохраняет eat, но также добавляет figth - это является примером open-closed?
Но, ведь ты буквально имеешь доступ к базовому классу, полям, методам в производном и связываешься с ними. Сильная связность
Спасибо за видео, уже в который раз убедился, что лучшая система это та где есть слой который абстрагирует доступ к какому то модулю. Абстракция занимация вызовом методов.
Типа забор.
хммм посмотрел вступление, звучит всё это заманчиво
Спасибо за это видео. Попробуй низкие частоты срезать эквалайзером и использовать какие-то плагины по типу izotope rx de click или wawes x click, потому что когда ты тянешь "ааааааааа", у в записи явно выраженный треск твоего горла, не знаю как лучше это объяснить
хапахп треск горла ска
Вау!
Что называется "психанул", 12 часов базы.
ты чево какие 12 часов
ахуенные
в 1080p есть возможность загрузить, чтобы совсем красиво было?
к сожалению нет(
Кажется ютуб нулем ошибся
Для гемдева подойдёт?
Огромное спасибо! Можно, пожалуйста, ссылку на текстовую версию?
Соглашусь с подходом One line one statement. Проблемы в приведенном примере на 3:53:30 принципиально не отличаются от цепочки вызовов через Pipeline. Получается цепочки вызовов тоже лучше не использовать? Типа такого: $this->doSomething()->doAnotherThing()->doYetAnotherThing();
Можно по ситуации. Это же не жёсткие правила. Просто так удобнее отлаживать и поддерживать и в кратковременной памяти держать. Я против жёстких правил. За гибкость.
Сразу подписался, спасибо огромное 👍долгих лет вам жизни коллега 👍
Спасибо ! К чему это прихлобучить ?
Привет вот тебя интересно слушать! Работаю и слушаю параллельно. Что то залетает в голову что то нет
титанический труд, смотрю потихоньку, повторенье мать ученья
мужик в верхнем левом углу рот открывает не синхронно только :)
Только в начале. Потом норм. Я два раза его снимал и у меня уже сил не было этот кусок переснимать. :)
Сорян за это. Но, я понадеялся, что все ребята норм и будут больше на контент смотреть, на пользу. И вроде так и есть, что радует 😁
Спасибо за видео!) Дай совет или сними ролик по изучению английского, свой путь конкретно
Опечатка в схеме на 43:45 - "We we to.." вместо "We have to" или "We need to"
начал смотреть)
1:50:52 "Функции сходятся". Очень важно понимать, что не всегда. И иногда это даже вредно.
Пример.
Вы пишите функцию для CAD - исчезновения объекта со сцены. Юмор в том, что это можно сделать как минимум двумя способами. Либо исправить геометрию на следующем кадре - убрать из списка прорисовки данный объект, либо поставить флаг, чтобы временно не рисовать объект шейдером - изменить параметры шейдера. Если объект удалён на долго то используем первый метод, если это моргание - второй.
Но проблема в том, что события прорисовки, шейдер и геометрия это по любому разные сущности. Притом даже физически, а не только в коде - цпу/гпу. И как следствие, попытка написать универсальный метод исчезновения, не учитывая домейн может привести вас к тому, что будут созданы либо лишние сущности, либо вообще появится сцепление.
Разумеется это решается просто разными "видами" исчезновения/удаления. Но дело в том, что для этого вам придётся понимать реализацию, которая тут домейн. То есть ваш домейн на более низком уровне абстракции. Очень часто именно домейн делает не применимым солид принципы. Мне кажется это хорошим примером того, где может проходить зона применимости принципа.
Нет противоречий. Солид Это не физическое разбиение всегда, когда только можно, всего, что можно, а использование таких моделей и уровне ней абстракции, которые применимы в каждом конкретном случае по параметрам, которые я расписывал ранее. Запомни, солид - не жёсткие правила "вот так делай", а принципы и рекомендации, которые записями от места применения и подстраиваются под них с помощью абстрактного и гибкого мышления. То, что ты описал и есть солид. А почему это так мы обсудили а начале видео. Это не про только функции и классы и интерфейсы
Твой случай когда "для нас солид" не сработал, я как раз в начале описал.
@@koduryem запомнил. 6 лет учился у универе - помнил. 7 лет писал кад систему с qt, python и низкоуровневым рендором - помнил. Вот щас забыл. Но автор напомнил. Теперь не забуду.
Если я тебя как-то задел, сорри. Просто увидел противоречие с тем, что я говорил и указал на это. Твоё мнение и опыт безусловно важны и ценны. И про них я ничего не говорил. Твоё мнение также было важно и я уделил время и разобрал его. Если не согласен - имеешь право. Я вижу ты отличный специалист с большим опытом, к которому я прислушиваюсь
@@koduryem дело не в обиде, а в том, что у вас язык "не обычный". Так и хочется подколоть. Вызвать реакцию. Обычно язык людей которые преподают этого лишён - он более сухой. Вы самоучка?
Автор молодец, большой был труд проделан по рассказу по чистой архитектуре. Только к видео применил антипаттерн "монолит", сделав одно видео на 12 часов. А как же выделение модулей, плейлиста и прочих принципов про которые ты говорил?
Таймкоды
Грандиозная работа. По сути изложение идей из книг Фаулера, Мартина, а также хорошие практики из опыта, но в формате видеолекции. Не знаю, правда, насколько это будет доступно к пониманию новичкам, скорее, для более менее опытных разработчиков, т.к. все излагается на уровне абстракций (что хорошо).
Недавно тут была статья на хабре (ссылки нету, можно поискать), где описывалось, как один парень зарубился с Мартином, мол, чистый код - такое себе. Оригинал не читал, объектьивно оценить доводы тяжело, но из самой статьи сложилось мнение , что тот парень или из "черно-белой секты", или просто решил хайпануть, но приведенные доводы вообще были ни о чем (на мой взгляд). К чему это я? К тому, что изложенные в видео мысли на практике действительно очень полезны на больших энтерпрайз-проектах, и не как свод правил, а именно концептуально.
P.S. "Перевод каретки" ... аж нафталином запахло ))
P.P.S. Ага, в телеге предпоследнее сообщение, похоже, именно про "того парня".
Спасибо)
Да, там наглядный пример)
Здравствуйте. недавно наткнулся на ваш канал. Подскажите, в ваших видео вы программируете на python. А будут видео где вы программируете на с++?
Я его выбрал, так как больше людей понимает и больше на псевдокод похоже. Я думал кое что на плюсах поделать в будущем
Во. теперь знаю подо что засыпать ближ.дни😊
Каждый раз убеждаюсь что SOLID это про то сделать код в 10 раз более сложным и в 100 раз более медленным. Вы объясняете как сделать тривиальные вещи невероятно сложным способом, похоже на Rube Goldberg machine.
В точности наоборот объясняю. И не говорю, как "правильно делать и только так", а когда где и почему и в какой ситуации. И почему именно там именно оно надо и другое хуже будет. Будь внимательней, а то как-будто не смотрел, а мнение составил :)
Если хочешь, можешь более детально привести пример, расписать, как бы ты сделал с учетом твоего контекста. Чтобы не было абстрактно "все херня"
@@koduryem вы объясняете очень хорошо, просто xyzwio не имеет достаточного опыта и предварительных базовых знаний для того, чтобы вникать в эту тему.
С моим опытом (а это посмотрел и переписал пару приложений на чистой архитектуре, еще нет опыта работы), всё хорошо заходит и структурируется в голове.
Кстати, Вы не ответили на мой вопрос, к сожалению, про то, как можно получить слайды из видео. Спасибо.
@@koduryem Спасибо что ответили! Мой комментарий был через чур эмоциональный. Не думаю что формат YT комментариев подойдет для таких дискуссий. Позиция которая мне ближе всего в этой теме хорошо изложена в видео "Clean Code Horrible Performance".
Видео довольно манипулятивное и рассматривает искусственный пример, оторванный от реальности.
1) "they tell you never ever do that" - кто "they"? Анкл боб сам же пишет - используй свитч, если удобно и размер проекта позволяет. Об этом и я говорил тоже. Почему "они" так говорят - первые темы, про которые мы говорили об ограниченности мышления и желания взять 1 инструмент и везде его использовать. Мы не рассматриваем серьезно такие вещи. "они говорят" - не конструктивно и biased, направлено на создание того восприятия, которое он хочет
2) Что такое "clean code" - он дал свое манипулятивное определение без каких-либо оснований и аргументов ("вот так полиморфизм заюзаешь вместо свитча - это и есть clean code"). Это уже нивелирует все, что он говорит. Я дополнительно делал акцент на том, что clean code - не инструмент "делай вот так", а принципы, применяемые в нужном месте и время, по ситуации, при эволюции кода. Этот же его код в маленьком проекте будет "clean", а на сотни тысяч строк оно становится big ball of mud, который можно просто выкинуть. Но, кто бы знал что за деревьями есть лес.
3.1) Он на серьезных щах сравнивает разницу между 35 vs 25 cpu cycles. Буквально, 1 cpu cycle on 4Ghz processor == 0.25ns => 35 * 0.25 vs 25 * 0.25 => 8.75ns vs 6.25ns. Это уже просто смешно. В добавок, это сравнение идет при прогоне бесполезной программы 1000 раз карл! Если мы, например пишем любой бекенд, шанс, что твой workflow прогонит разного рода объекты 1000 раз очень мал. И даже если вдруг, то.... 9 НАНОСЕКУНД . Такое можно еще считать , если мы ракетостроением занимаемся или жесткими embedded (и то современные ембеддед типа телефонов и планшетов даже не заметят этого). Значит, прогнать подобное 1 000 000 раз будет 90 нс, 1 000 000 000 раз - 1мс. Часто, если у нас бд, к примеру, наш запрос может отработать и за 100-300мс, что вообще 10^8 больше, чем он прогоняет 1000 раз свои объекты для вызова 1 метода => это просто капля в море. Могу миллиарды раз так гонять, и пользователь не заметит даже.
3.2) Код стал хуже читаться, поддерживаться, на мастшабах это может убить проект (десятки тысяч строк мб еще ничего или если это инкапуслировано в одном модуле). Теперь каждое место по всей программе должно знать ВСЕ типы объектов, чтобы написать логику. И все поля структуры, чтобы писать логику. Мы не можем просто принять интерфейс и вызвать метод. Нет. Теперь пиши функции и там перебирай все типы объектов. А если что поменяется - меняй их ПО ВСЕЙ программе (представьте в сотне тысяч строк поменять). В своем и даже абсолютно чужом коде, где ты без понятия, что люди делают и как и что изменить надо правильно. Nice.
4) Подумайте, почему комменты закрыты полностью? Хоть бы позитивные оставил, мы бы advantages от туда взяли.
5) Оптимизации со switch -> hash table не всегда возможны и нужны. Только в узких моментах. Эта оптимизация абсолютно бесполезная, если у нас бизнес логика, а не программирование микроконтроллеров. Хотя, я так иногда тоже делаю, где возможно. Но не для мега оптимизаций, а читаемости кода или удобства.
6) Подобный подход "в лоб" можно использовать, при разработки в agile style (и мы так делали в видосах). Без лишних абстракций и тд. Когда маленький проект и оч мало людей на нем (1-2-3). Все работает, быстро. ок. Скрыто в небольшом модуле. Ок. Легко понять, читать много не нужно. НО! Даже там мы не будем оптимизировать до талого код, который мы 100% удалим и поменяем на другой, когда проект начнет становиться больше. Или когда эти оптимизации не рациональны в нашей задаче (90% случаев). Значит, мы потратим очень много ресурсов на оптимизации, которые не нужны ни в проекте, ни бизнесу (пара наносек - это не о чем). Такими вещами типа байтодрочева занимаются в чрезвычайно узких местах.
Человек не понимает, что код пишется не просто так и что его надо поддерживать множеству людей и команд. Что requirements у бизнеса в большинстве случаев не оптимизация до наносек. Не "скорость" ради скорости. А имплементация бизнес логики и решения задач ОПТИМАЛЬНО. Чтобы в этот код можно было легко вносить новые изменения и фичи, оптимальная скорость, минимум кода и cognitive complexity, чтобы команды не конфликтовали при разработке и тд.
Если я на интервью скажу "я оптимизирую код по максимуму и если потом кто-то захочет что-то в нем изменить, ему надо будет перелопатить сотни тыщ строк и везде принять решение, что и как изменить, чтобы ничего не поломать; clean code говно; зато очень быстро будет!", скорее всего даже у hr'а, кто не в теме, случится когнитивный диссонанс.
Если бы он просто сказал "ребят, вот такое мнение вот для такой конкретно задачи" - то ок. Ну, я тоже бывает ляпну что-то и как-бы не парюсь, не хочешь не делай. Когнитивное же искажение в виде генерализации с примесью манипуляций "вы видите, я взял пример на 200 строк и разбил эти ваши мифы про клин коды" - ну как-бы такое :)
Очень рекомендую поработать над речью и избавиться от слов паразитов: "Ну типааа", "Типа даааа" и вот это вот всё.
контент очень годный
Прости что заставил тебя страдать :)
@@koduryem ну типа ок