Это бомба, особенно про то, как задроты на собесах свое чсв почесывают вместо того, чтобы узнать, что действительно человек сможет полезного принести в компанию
Все эти штуки важны когда вы думаете/заботитесь о том как ваша система будет эволюциони́ровать во времени. Когда ваш горизонт мысли это пол года - годы. И это вопрос вашей роли в команде, если вы не хотите думать об этом, то как бы берете тикет и перетаскиваете его дальше по доске, а об этом будет думать ктото другой. Довольно часто об этом думать и не нужно, если у вас не стоит задача обеспечить способность системы эволюциони́ровать, а просто написать какой то простенький апи сервис, то об этом думать не нужно но изучать стоит, потому что это ваш инструмент.
Ну есть ли смысл писать одноразовый код, который проще выбросить, чем поправить? Очень редко это так и чем дальше, тем долгосрочные системы будут вытеснять системы однодневки
13:32 это называется "зона комфорта", мне кажется некоторые языки и фреймворки до сих пор используются в продекшене исключительно по этой причине. ну, или "эффект утенка", когда люди делают так как им показали когда-то и "если оно работает, то зачем его менять?"
мне кажется это не имеет смысла. потому что паттерн это как раз про "необъятное", потому что конкретная реализация будет отличаться от проекта к проекту и тем более на разных фреймворках или языках. примеры паттернов лучше рассматривать на примере аналогий из жизни или в виде алгоритмов
на счет того что "нужно разбираться и перестраивать под изменения", я как-то слушал доклад про использованте ORM и одним из аргу ентов против было "для того, чтобы уметь корректно работать с ORM, вам нужно знать SQL, то как ORM преобразует данные, и дополнительные функции библиотеки". Так, что если вы думаете, что используя фреймворк или ORM вам не нужно знание паттернов и принципов, то вы очень заблуждаетесь. Просто не нужнр упарываться и ставить исполбзование тех же паттернов выше по приоритетам, иногда Нужно сделать все как можно проще, чем оверинженирить
Смотря в каком проекте, вообще все принципы и паттерны в одном месте помогут, а в другом повредят. Получить опыт их внедрения и уверенное владение адаптацией паттернов к языку и платформе и призван новый курс
Возможно не в тему, но: Собеседовался на джуна (да, я ламер-супер-нуб), мне впрягают за подходы/паттерны/модели etc, но я спрашиваю, а как с этим всем добром Ваше приложение умудряется иметь 5 CRITICAL CVE. и это я использовал простой OpenCVE сканнер? Молчание. И обидно, что в многие даже крупные в рамках отдельных регионов проекты тянут идеи/паттерны/модели/etc абсолютно бездумно!! Без оглдки на практическую целесообразность, логику и подобное....
@@i_pam_pam При этом, js стал языком победившего завтрашнего дня, на котором программируют все, от микроконтроллеров до баз данных и высоконагруженных распределенных систем, а культура осталась той же, что и при покраске кнопочки
@@имяфамилия-э7ы2е ты и так код разделяшь "по разным модулям/классам/функциям" почитай чем класс, модуль и namespace отличаются в твоем языке и тогда поймешь
Single-responsibility principle - в первую очередь про классы и о том, что один класс инкапсулирует в себе поля и методы относящиеся к одной сущности или выполняющие определенный набор задач. например у тебя есть класс Math в JS, он имеет набор статических методов позволяющих выполнять математические операции. Так же у тебя есть класс Array, который позволяет создавать массивы или работать с массивами данных при помощи статических методов. нарушением SRP - было бы если бы ты имел один класс, который включал в себя функционал обоих выше указаных. но то хранятся у тебя они в одном модуле или неймспейсе это неважно. вынесение классов в отдельные модули это уже про архитектуру и клинкод, так же как и декомпозиция методов. тут просто нужно уже пользоваться здравым слымлом, если у тебя функция на 50 + строк, то скорее всего она делает в себе много разного и возможно есть вариант разделить ее на несколько функций поменьше, но это уже не совсем про SRP
Это бомба, особенно про то, как задроты на собесах свое чсв почесывают вместо того, чтобы узнать, что действительно человек сможет полезного принести в компанию
супер❤
Все эти штуки важны когда вы думаете/заботитесь о том как ваша система будет эволюциони́ровать во времени. Когда ваш горизонт мысли это пол года - годы. И это вопрос вашей роли в команде, если вы не хотите думать об этом, то как бы берете тикет и перетаскиваете его дальше по доске, а об этом будет думать ктото другой. Довольно часто об этом думать и не нужно, если у вас не стоит задача обеспечить способность системы эволюциони́ровать, а просто написать какой то простенький апи сервис, то об этом думать не нужно но изучать стоит, потому что это ваш инструмент.
Ну есть ли смысл писать одноразовый код, который проще выбросить, чем поправить? Очень редко это так и чем дальше, тем долгосрочные системы будут вытеснять системы однодневки
Я сегодня открыл для себя понятие «карго-культ» 😂.
а я слово "вЫнедрять" 😂
13:32 это называется "зона комфорта", мне кажется некоторые языки и фреймворки до сих пор используются в продекшене исключительно по этой причине. ну, или "эффект утенка", когда люди делают так как им показали когда-то и "если оно работает, то зачем его менять?"
4:51 я несколько лет работал в e-commerce, сейчас работаю с рекламой и это совершенно разные вещи
Тимур, планируете делать курс по абстракциям/границам/контрактам/коплинг и т.д?
Да, сначала делаю это частью курсов Node.js 2024 и Async 2024, а потом уже как отдельный курс
хотілось би більше коду і прикладів чому тут саме той патер і як буде без нього .
чим про необятное :)
Ну я готую курс, поки семінари проводжу, приклади роблю, опитування, що у головах, щоб знати, як це змінити
мне кажется это не имеет смысла. потому что паттерн это как раз про "необъятное", потому что конкретная реализация будет отличаться от проекта к проекту и тем более на разных фреймворках или языках.
примеры паттернов лучше рассматривать на примере аналогий из жизни или в виде алгоритмов
на счет того что "нужно разбираться и перестраивать под изменения", я как-то слушал доклад про использованте ORM и одним из аргу ентов против было "для того, чтобы уметь корректно работать с ORM, вам нужно знать SQL, то как ORM преобразует данные, и дополнительные функции библиотеки". Так, что если вы думаете, что используя фреймворк или ORM вам не нужно знание паттернов и принципов, то вы очень заблуждаетесь. Просто не нужнр упарываться и ставить исполбзование тех же паттернов выше по приоритетам, иногда Нужно сделать все как можно проще, чем оверинженирить
А про чистую архитектуру нам расскажут, она нужна или все это лишнее? Мы же не кровавые энтерпрайзы
Смотря в каком проекте, вообще все принципы и паттерны в одном месте помогут, а в другом повредят. Получить опыт их внедрения и уверенное владение адаптацией паттернов к языку и платформе и призван новый курс
Возможно не в тему, но: Собеседовался на джуна (да, я ламер-супер-нуб), мне впрягают за подходы/паттерны/модели etc, но я спрашиваю, а как с этим всем добром Ваше приложение умудряется иметь 5 CRITICAL CVE. и это я использовал простой OpenCVE сканнер? Молчание. И обидно, что в многие даже крупные в рамках отдельных регионов проекты тянут идеи/паттерны/модели/etc абсолютно бездумно!! Без оглдки на практическую целесообразность, логику и подобное....
Потому что js всегда использовали те, кто не хочет читать книги по CS, patterns и тд. А хотят добавить кнопочку и сразу же видеть ее
@@i_pam_pam При этом, js стал языком победившего завтрашнего дня, на котором программируют все, от микроконтроллеров до баз данных и высоконагруженных распределенных систем, а культура осталась той же, что и при покраске кнопочки
S принцип в SOLID - это принцип модульности?
нет, это значит, что не нужно смешивать логику не относящуюся друг к другу
отчасти да, это связано с делением на сущности, когда у каждой сущности своя специализация
@@N5O1 то есть разделить по разным модулям/классам/функциям
@@имяфамилия-э7ы2е ты и так код разделяшь "по разным модулям/классам/функциям" почитай чем класс, модуль и namespace отличаются в твоем языке и тогда поймешь
Single-responsibility principle - в первую очередь про классы и о том, что один класс инкапсулирует в себе поля и методы относящиеся к одной сущности или выполняющие определенный набор задач.
например у тебя есть класс Math в JS, он имеет набор статических методов позволяющих выполнять математические операции. Так же у тебя есть класс Array, который позволяет создавать массивы или работать с массивами данных при помощи статических методов.
нарушением SRP - было бы если бы ты имел один класс, который включал в себя функционал обоих выше указаных. но то хранятся у тебя они в одном модуле или неймспейсе это неважно.
вынесение классов в отдельные модули это уже про архитектуру и клинкод, так же как и декомпозиция методов. тут просто нужно уже пользоваться здравым слымлом, если у тебя функция на 50 + строк, то скорее всего она делает в себе много разного и возможно есть вариант разделить ее на несколько функций поменьше, но это уже не совсем про SRP