Архитектура ПО для маленьких и тупых
HTML-код
- Опубликовано: 12 сен 2024
- erid: LjN8K8mKw | Разверни кластер облачных баз данных или Managed Kubernetes со 100% кешбэком в Selectel: slc.tl/dyl5v
---
Подпишись на наш Telegram Канал 🖤 t.me/extremecode
Лицензия Creative Commons Attribution 4.0 на использование трека Hyperfun (исполнитель: Kevin MacLeod): creativecommon...
Источник: incompetech.com...
Исполнитель: incompetech.com/
Тележка 💙 t.me/extremecode
Бусти ❤ boosty.to/extremecode
Канал про стартап 💚 t.me/startup_reports
Всегда становится страшно, когда видео вышло 21 минуту назад, а комментарий был написан 49 минут назад...
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё?
да что за хуйня здесь происходит?)
Экстримтсоде, спасибо, что ты есть. Благодаря тебе я раз за разом напоминаю себе, что во мне кроется бесконечный потенциал, способный изменить мир, но вместо этого я стал писать код на JavaScript.
Два месяца назад перешёл с сишарпа на жаваскрипт, приступив к расширению опенсорсного проекта, начатого и заброшенного индусами. Теперь хочу уйти из индустрии.
@@zevsmd онли в онлифанс
@@zevsmdтут главное в окно не выйти )
Ясно, у рекламодателей экстрим кода снова появились деньги
накопили
и ролик пришлось пилить оч. быстро абы как
@@MrPokimon4ik кэшбек с макдональдса упал
Посмотрел, удаляй
Удалел, посматряй
Посдаляй, умотрел
Уго
Умоляй, постарел
повзрослел, выдворяй
"делаем как все" и "не боимся нарушать говнопринципы, даже если их используют все" как-будто противоречат друг другу
На первый взгляд да, но если подумать, то эти принципы оттого и говно, что их по сути невозможно соблюдать всегда и везде. И да, там не так звучало, там было "особенно если это делают (нарушают их) все".
"делаем как все" и "не боимся нарушать принципы, если их нарушают все"*
думаю, такой посыл вернее)
между этими принципами временной промежуток длительностью в 1 свитер с оленями в зеркале... будто ты видео не смотрел
Все как раз и не следуют принципам, поэтому нарушать нечего
Этим принципам следуют все только на форумах, митапах, конфлюэнсвх и т.д.
Если нарушишь ождин из них твой ревьюер с пеной из смущи у рта будет писать комменты что так делать нельзя, паттерны и прочее кокок, хотя сам он пишет по функции в месяц(один деньь пишет, 29 день разгребает баги от своей функции)
Братан, хорош, давай, давай, вперед! Контент в кайф, можно еще? Вообще красавчик! Можно вот этого-вот почаще? Давайте пока.
У нас были 3 праграммиста, которым поручили написать фронт для приложения. Они создали идеальную архитектуру, составили список ВСЕХ компонентов, полностью проработали логику взаимодействий этих компонентов, полностью расписали где какие методы, что получают что отдают и тп. Потратили месяц. И это все без единой строчки кода. На каждый компонент создали задачку в битриксе, получилось 175 задач) Но они не учли, что приложение может расширяться и изменяться, и когда у нас поменялся главный экран и авторизация, они еще на две недели зависли, что бы это тоже правильно расписать. В итоге ПМ на них наорал и выгнал. Остались 175 задачек в битриксе, и 500 бессмысленных чатов с обсуждением архитектуры. В итоге фронт писал я, архитекуту придумывал на ходу. Многое делал интуитивно, справился за месяц, работает все уже 3 года, у нас полностью поменялось api, дизайн и очень много логики, прекрасно расширял и удалял функцонал, и проблем практически не возникало.
Я в одной конторе как-то запилил инструмент для внутреннего пользования, всё что я сделал по архитектуре до разработки, так это схему БД. Делал всё сам, считай fullstack. На бэке был python/flask и весь фронт на jinja шаблонах, плюс расширение для браузера в tampermonkey. Потратил на разработку первой версии около недели. Отдел сразу начал с ней работать. Но нужно было добавлять функционал, плюс в UI нужна была реактивность, а новые данные приходили из трёх источников: с ответом от сервера, из UI, из браузерного расширения. Поэтому решил не изобретать велосипед и просто добавил VUE прям в jinja шаблоны, без всякой сборки фронта, либы загружал из CDN 😁 С этим инструментом уже два отдела работали, коммуницируя между собой через него. Из другого отдела нужно было добавить пару фич, я просто скинул ссылку на репозиторий и один сотрудник, без лишних вопросов реализовал эти фичи, без создания всяких чатов и оно работало. Плюс я расширил функционал для внешних заказчиков. И вот в таком виде этим инструментом, в той конторе, пользуются до сих пор, хотя я там уже не работаю.
PS Это был мой первый проект. Сейчас я уже так не делаю 😁
ну это типикал jira программисты че сказать
Походу, это были вкатуны, умеющие проходить собесы...) За месяц ни строчки кода... Это надо уметь.
А знаешь в чем фича? В том, что написал ты, поддерживал и расширял тоже ты. Попробуй взять нового джуна или даже миддла и дай ему выполнить задачку в соло и ощутишь боль в попе. Либо в своей, когда будешь пытаться понять и расширить поверх задачи коллеги, либо в своей, когда будешь объяснять новоиспеченному принципы на которых архитектуру проекта строил
@@kadr6424 ну я пытался документацию писать, а потом решил, ну это все е х*ям, все равно я один. А если уволят, ну вот пусть сами тогда и разбираются
Ай прям хорошо зашло. Накидай ещё на вентилятор 👍
"Преждевременная оптимизация" - этот грех архитектора ввел в оборот еще Мартин Фаулер в своей книге "Архитектура корпоративных приложений".
Когда наебнется, тогда подумаем, всё правильно. Сэкономит много сил и времени. А оптимизировать всегда можно успеть)
Преждевременная эякyляция только знаю
@@PilotInspektor Да просто ожидания часто не совпадают с реальностью. Архитектор ожидал что на производительность приложения повлияет одно, а в жизни оказывается что оптимизировать надо совсем другое, то о чем архитектор даже и не знал. И оптимизировать надо быстро и жестко. А эта преждевременная оптимизация мешается под ногами и об нее спотыкаются делая оптимизацию реальную.
@@cludiee138 Да, преждевременная оптимизация это как лечить преждевременную эякуляцию покупкой специального презерватива. "Почти бесполезно для него и совершенно бесполезно для неё" (c)
Там речь шла про ассемблеродрочерство, а не про говнокод.
С Соером пивка попил - опа, архитектуру на канальчик подвезли))) ❤
Скоро за ассемблер говорить будет)))
Да, так и соевым куколдом таким же станет.
Хотя….
DRY это не про дублирование кода. Он связан с SRP. Т.е. нельзя дублировать то, что имеет одну причину для изменения. Если код слабо связан, т.е. изменяется по разным причинам, то копипастить не запрещается.
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
По поводу "поправить код в одном месте не поломав все остальное" вместе с "поправить логику везде".
В первом случае можно создать базовый класс, вынести туда всю оставшуюся общей логику, запилить 2 реализации интерфейса и резолвить нужную по месту.
Во втором просто меняешь и радуешься жизни.
Экстрим цоде просто ещё не прочитал книжку про наследование
@@user-ry5oh3qt2u потом про композицию, агрегацию и ассоциацию узнает -- вообще мозг рванёт
Наследование - причина 99% проблем в мире ООП.
Нужна какая-то логика - делай функцию. Дальше - наворачивай функциональные композиции.
Тестируется проще. Ты не сломаешь половину проекта когда полезешь в базовый класс. Работать с простыми функциями - проще, чем с иерархией.
Я понимаю, что всем кто знакомится с ООП - кажется, что наследование - прям отличная вещь. Только вот чтобы нормально построить иерархию объектов - надо СНАЧАЛА написать 100 раз то что ты пишешь тут, чтобы знать все подводные камни, как их преодолеть, что надо в базовом классе иметь, что не надо. И только потом - браться за проектирование.
В большинстве случаев - такого опыта - нихрена ни у кого нет. И получаем, либо ненужные абстракции, либо грабли, расставленные по всей кодовой базе, либо очень интересные сайдэффекты и трудноуловимые баги.
При чем тут иерархия наследования. Для стратегии, которую я описал, нужен один уровень вложенности. Один базовый класс, один интерфейс, n реализаций.
Обычно бывает наоборот - поделия мамкиных архитекторов немодифицируемые, не поддающиеся дебагу, тяжелые для понимания, хоронящие команду за командой вновь нанятых разработчиков для поддержки этого поделия.
Про DRY - копипастим.
Если надо поменять - просто делаем поиск с заменой.
Ответ на вопрос про DRY:
Нужно завязывать все части системы на один кусок кода. Тогда, если понадобится изменение для одной части, то ты просто копируешь этот кусок, делаешь в нём изменение и перекидываешь часть на него.
так а смысл? через некоторое время таких копий накопиться много и когда потребуется изменение для всех разом, остаемся с той же проблемой. Нет такого что тут как раз и нужен слой асбтракции сверху - когда нам нужна копия для отдельных строчек кода? Что именно в этот момент мы и создаем абстракцию, а не придумываем их разом когда планируем проект?
@@megaguar Изменение для всех разом производится в общей части кода, а индивидуальные изменения - в специфичной части кода. Нужно уметь разделять код на общие и специфичные части.
@@megaguar для всех разом не может понадобиться. Для всех разом понадобится если во всех копиях есть одинаковый кусок кода. А зачем мы делали копии одного и того же кода. Это ошибка разбиения кода на подпрограммы. Копировать надо уникальные части, одинаковые вынесены в одну подпрограмму.
@@ArthurKhazbs я не спорю, а именно спрашиваю - а разве вся эта история с наследованием не есть именно про это - разбиение кода на "общий" и "специфический"? "общий" это и есть верхний слой абстракции изменения в котором будут актуальны для всех подклассов, нет?
@@Rayvenor ну так это и есть вопрос класса-подкласса, наследование и вопрос доп. абстракции, нет?
Братан, хорош, давай, давай, вперед! Контент в кайф, можно еще? Вообще красавчик!
В общем, всё сводится к старому доброму "пиши нормально - нормально будет". )
По сути получается, что на какой бы ты стул ни сел, оказавшись на развилке принятия решений при проектировании приложения, могут быть как положительные последствия, так и отрицательные. Поэтому в конечном итоге ориентироваться стоит на базовую объектную семантику, возможности, хорошие практики и scope задачи.
Если заказчик просил только банан - подсвети контекст, и если всё же настаивает, что нужен только банан, - делай только банан. Обезьяна, которая его держит, конечно, первична, но ещё первичнее бабулесы уметь считать и экономить.
Если между объектами есть что-то общее и таких объектов достаточно много, да ещё и регулярно появляются, - наверное нужен общий класс. Если объект 1 и в горизонте следующих 150 лет новых похожих не планируется, - есть смысл отложить семантику на тех продвинутых существ, которые изобретут этот второй объект.
Как говорится, "Делай как надо, а как не надо - не делай"
@@debastiancebs Как обычно, сказали за меня)
А заказчик может быть недоступен. А предметная область - очень специфичной и ты ничего пока на прод не раскатаешь - не узнаешь, про то что там надо кому.
Единственное рабочее решение - делаем так, чтобы можно было из банана сделать вертолет, и релизим часто, чтобы фидбек получать как можно скорее.
SOLID, KISS и DRY нужны для того, чтобы в программу было легко добавлять фичи независимо от размера прожекта. Можно не упарываться, но сильно нарушать не стоит, чтобы потом не тратить кучу время на долгие рефакторинги (недолгие все равно придется делать). А паттерны нужны скорее для того, чтобы читать чужой код. Когда использован синглтон или наблюдатель, программа будет одинаково понятна и тебе, и твоему другу. После какого-то момента вы легко и интуитивно найдете среди 50000 файлов прожекта нужный и радостно добавите туда свой говнокод. Это же прекрасно
Любой индус за пару дней разберет ваш дерьмо код. А пара индусов ... ну вы поняли
Если есть некий кусок кода в единственном экземпляре, от которого зависит код в разных частях приложения, и появляется необходимость изменить этот кусок для отдельных частей приложения, не меняя другие - в чём проблема тогда скопировать его и поменять конкретно для этих частей, а оригинальный кусок не трогать? Если уместно, то можно и вовсе прибегнуть к б-гомерзкому ООП и отнаследовать класс.
Я конечно не спец но вижу проблему схода😂
Прожект на 50к файлов. Сидишь думаешь так здесь надо поменять кусок кода, меняешь. Через неделю забыл. Через месяц меняешь кусок кода в другом месте, итерируешь n-раз. Через n+1 времени есть кусок кода от которого в теории всё зависит😅 а на практике как повезет. Через пару лет рефакторинга если повезёт разберёшься 😂😂😂
@@greengrey3003 на такой случай уместно оставлять комменты в коде, а ещё лучше вести нормальную документацию (честно, не представляю, как можно не потеряться в проекте такого объёма без доки)
Обезьяна с джунглями - это было тонко))
До слез смеялся, подписался, так ахуенно. Это не цинизм, это как будто смесь недоумения и заебанности. Спасибо тебе, любимчик :**** братишкааааа
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще? Давайте, пока.
Мне кажется DRY, должен применяться когда помимо самого кода копируется и причина для чего это код необходим. Например есть метод а, который меняет статус заявки на А и метод б, который также меняет статус на А. Однако в первой ситуации это происходит из-за действия альфа, а во второй из-за действия бета. Код одинаковый, но это пока, а когда БП по действию бета вдруг начнут менять, нам не придется один метод делить на два.
Ну, тут всё по делу. Особенно п.2 и последний.
А насчет загадки - всегда в метод можно прокинуть необязательный колбек, который реализует какую-то особую логику. В итоге и метод слабо меняется, и вся эта редкая логика вынесена куда нужно.
1. Делаем как все
2. Знать зачем пишем
3. Забиваем на ненужное
4. Не проектируем наперед
С говнопринципами в точку. Всегда улыбал принцип единственной ответственности. Можно с ним так крышей поехать, что в каждом движении биточка между регистрами будешь видеть самостоятельную ответственность и отдельную сущность в виде гномика в придачу)
с опытом приходит осознание, что это не просто так все придумывалось и понимание где, как, когда и какие принципы надо использовать) ничего все еще впереди понимание приходит с опытом, читай книжки - поймешь)
@@Qnoize спасибо, но я не новичок в этой сфере, и вышесказанное не из воздуха взял
опять овно на вентилятор :)))) все эти архитектурные решения рождаются в страданиях, и являются как раз систематизированным унифицированным решением большинства задач оптимизации процесса разработки любого ПО.. большинство нормальных/хороших разработчиков доходят до этого понимания, пусть и не сразу.. естественно, Васе с курсов скилфэктори не сразу дойдёт "зачем" это вообще нужно, если проще тяп ляп и прод :)))) может поэтому архитектор - это довольно высокая ступенька развития программиста-прямоходящего, там Дзен познать нужно сперва, а только потом свои корявые ручонки пихать в архитектуру (ну если только задача это не элементарный лендинг) :))))
Ну вообще качество работы скорее зависит от самого человека, насколько он вовлечен в работу, а не от того как и где он получал знания, он может и сам до этого дойти или ему на курсах расскажут, бывают люди, которые просто не хотят сильно париться и делают все как попало
Когда я увидел для маленьких и тупых, то у меня аж слеза навернулась 😢
Братан, ты хорош! Давай ещё, контент годный, но, кажется, я пока слишком далеко и весьма оптимистично смотрю %)
Братан хорош, давай давай вперёд. Контент в кайф. Можно ещё? Вообще красавчик!!!
Про DRY: просто расширить интерфейс и меняй что хочешь
Буква О из solid
SOLID и DRY - это не про архитектуру (system design), это про декомпозицию кода. Фронтендеры не занимаются архитектурой в принципе, т.к. весь фронтенд - это только один компонент архитектуры приложения.
братан, давай еще! Контент в кайф!
тащемта, проблема только с первым принципом. как все делают я в душе не ебу, потому что пишу код в одного, под собственные нужды. особенно хорошо мне даётся забивание на ненужное (и нужное) и не думать на вперёд (иногда, вообще не думать).
короче, спасибо, екстримецоде, всю жизнь думал, что я долбоёб, а оказалось, я царь проектирования. главное просто голову отключить и кодить в шаманском трансе.
пойду, что ли курсы запилю, как довести себя до исступления и начать чревовещать на питоне
Пытаюсь не захлебнуться от пролитой воды.
начинал смотреть канал еще зеленым масленком, приятно видеть, что теперь когда я стал Архом и канал решил двигаться со мной)
У каждого архитектора есть шкаф со скелетами сошедших с ума разрабов 😅
ну не у каждого, ладно у каждого опытного)
У неопытных архитектура плохая, потому шкаф для скелетов не продуман и они просто так на проходе валяются.
Я один заметил что extreme code записал новую концовку?
та да... уже не торт, в старой концовке была душа, а с новой концовкой вообще смотреть невозможно!
Братан, харош, давай-давай - вперёд! Контент в кайф, можно ещё? Вообще красавчик, ну и подобного вот этого почаще, давайте пока.
4:57 ФЭЙЧУР БЛЭТТ. очень екстреме соде!
Давайте так - решим что есть нормальные архитекторы и они на это учились много лет и понимают процесс разработки и цели которые перед ними стоят, а есть ребятки которые прыгнули не понимая куда попали и что знают то и вкручивают, главное с умным видом и мощным ощущением что повидали весь мир и знают все.
Архитекторов сейчас столько и знать нужно столько что с ума сойти можно.
Enterprise, platform, solution/software, technical architect, data architect, sec. Architect etc.
Практически всем нужно разбираться и в бизнесе и в технологиях, понимать риск менеджмент, как работать с людьми и убеждать людей.
По моему опыту - сделать архитектуру это одно, а прийти к ее реализации с полным согласием всех сторон и пониманием тех самых trade-offs всеми участниками ну прям очень сложно. Особенно когда люди вокруг не готовы к любым изменениям, а это сорян прям все😅
Заходить в архитектуру обязательно нужно с техническим бекграундом и лучше знать обо всем, именно знать - не уметь, так как от этого зависит принятие решений и возможность предложить эти решения.
Доверяйте свой бизнес профессионалам 😉
Изменить код сразу во многих местах изменением общего для всех источника лучше, а если нужно точечное изменение, то просто переопределить для этого места код локально, оставив ссылку на оригинал.
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
=)
Вот про надумывание наперёд вообще супер актуально для меня. Буду стараться так не делать, уже одного заказчика так потерял. Братан хорош давай давай контент в кайф.
Неплохой выпуск получился, давай ещё
Ну DRY просто в разумных рамках ипользовать надо. Если ты сделаешь функцию сложения двух чисел и будешь использовать во всём проекте, то это как. Если ты используешь функцию в одном классе или семействе, занимающемся конкретной задачей, то это уже норм.
Паттерны одни и проблемы у всех одни. Полностью согласен про архитектуру ПО применяем патерн и смотрим на проблемы коллег по патернам!
Проникся во все 4 еще на первом году. 4ый год пошел, полет нормальный, схема рабочая👍
Итог: делай, как все, но по-своему
Классную архитектуру объяснил,понял. Теперь про отвратительную архитектуру делай
Так она такая же
Ха-ха, фроненд архитектура)) ой сказочники)
ну фронты тоже хотят быть разработчиками и архитекторами)
Я ещё не досмотрел, оставь!
"не уничтожить код во многих частях одним изменением".
Если соблюдать принцип единственной ответсвенности, этой проблемы не возникнет, я думаю.
братан вперед, контент в кайф. можно вот этого еще побольше?
Братан, хорош,! Давай, давай, вперед! Контент в кайф.
Странно что я тебя смотрео больше года назад но в рекомендации все равно попал) хотя ролик все равно топ
6:27 начало, не благодарите 🥲
братан хорош давай давай вперед контент в кайф можно еще вообще красавчик. Можно вот этого вот почаще?
Ну сказать что SOLID, DRY вовсе не нужны это набросать говна на вентилятор. Скорее опытный разраб почти всегда следует паттернам и солиду, просто не понимает этого(если не читал мартина), антипаттерны и нарушение методологии обычно что-то уникальное и требующее особого подхода, как правило в большинстве задач таких мест от силы 2-3 , как исключения, но в остальном , я бы советовал следовать методологии, проще потом править пару мест, скопировать дублирующийся код и переписать, отнаследовать, но не переписывать методом дробовика абсолютно всё
Ты можешь изучить ЯП, и писать на нём программы.
Ты можешь научиться структурировать код, и писать проекты на любом языке.
Это вы еще адептов DDD не видели :D
а что ты против ДДД имеешь?)
@@Qnoize Не видел ни разу нормального DDD проекта, а которые видел - настолько переваренный кал, что разберется в нем только сам автор. А другой адепт когда увидит - скажет что это не тру ДДД.
Братан хорош, контент огонь! Можно ещё и побольше?
У меня некоторые куски моего кода, мигрируют из проекта в проект - без модификаций, на протяжении 5+ лет
Это к вопросу о необходимости проектировать очень далеко наперёд, один из последних моих проектов был адаптирован под новые требования - практически без изменения логики и архитектуры изначального проекта, потому что эта архитектура так же была спроектирована на половину вечности
А видите папочку ФЭЙЧЕР?
А еще пора медийно отменять наследование, особенно многоуровневое. На все воля интерфейсов (без реализации в самом интерфейсе, а то напридумывывали фич)
братан ваще в кайф давай давай вперед!
Если изменение кода в одном месте ломает части приложения - значит надо было D из SOLID применить - разделить код.
Помню была таска сделать одночлены и многочлены, не пользуясь STL. В общем структура была такая:
Polynomial
| List m;
|
List powers;
Где List тоже мой класс. В итоге дебажил 8 долбанных часов, потому что сделал конструктор копирования, но не сделал operator=. В общем перегружать архитектуру это зло
Dry соблюдаем ток когда истинное дублирование
Шик, спасибо!
Я вот сижу и чувствую, что моему пету необходим новый слой. А-то пока ощущение, как от наждачки
Видео начинается с 2:06
Да. Делаем как все.
А все - болт клали на нормальный код, им бы лишь бы тасочку закрыть в срок, и пойти домой жену за мягкие места трогать. Либо собрались люди, у которых основной паттерн проектирования: StackOverflow - ctrl+c - ctrl+v.
В результате - код нетестируемы, код не переиспользуемый, держится только на том, что как раз один седой дед, который после универа устроился работать - помнит досконально это вот чудо, и только он - знает где ж там что вставить, при этом - даже он, чтобы подвинуть кнопку на 2 пикселя - месяц тратит.
Если сложились хреновые практики, и единственный аргумент их использования - это Я ТАК ВСЕГДА ДЕЛАЛ. То считаю верным - класть на то как делают другие - и делать как правильно.
Банально - тесты нужны. Код - должен быть переиспользуем. Чтобы ты же сам, потом через год - случайно не сломал его. Чтобы - если ты делал похожую фичу - тебе не нужно было ее с нуля писать.
В момент когда автор произнёс слово "фичурс" как "фэйчер" я тут-же понял, что я всё понял.
Возможно, автор англичанец ☝️
феатурес
Братан, можно вот этого вот ещё почаще?
в рекламе, в грузовике с пивом битком набито портвейном три топора, лол)
3:09 хитрый авторитет Аристотель постулировал принцип об избегании апелирования к авторитетам???... 😁
Братан хорош давай давай вперед контент в кайф можно еще вообще красавчик можно вот этого вот почаще
А как нам не думать наперед, если все таки придется масштабировать проект позже, но при этом когда приходит будущее времени на рефакторинг вообще нету?? Эта какой то курьез, можете дать совет
оуоуоу, еще такого же на вентилятор пожалуйста!!!!
Воу, а мусье знает толк в извращениях 😏
Мне кажется, или между принципом "Делаем как все" и "задаемся вопросом Зачем" фундаментальное противоречие?
Ну сначала задаешься вопросом "зачем" точнее "а оно мне надо?", когда получен положительный ответ - делаешь это нужное как все)
Думал будет видос про DDD и прочее , а оказалось видос для маслят :(
они еще до ДДД не доросли видимо)
ШЕДЕВР!
когда я спршиваю себя зачем на ум приходит только потому что мне за это плотят
Братан харош давай давай вперед контент в кайф ваще красавчик
я смотрю на вас, вы не готовы! вы все не готовы!😂
(первый видос как раз попал в тему, прямо сейчас ищу как всё спланировать. )
Учишь фронтенд-фреймворк, приходишь на работу, а у тебя проект использует забугорную платформу. И пишешь ui и логику тупо в json/csv файлах... На некоторые пункты в проекте, на которые встал вопрос приходит убийственный ответ - "документации как таковой нет"...
Братан, хорош! Давай-давай! Вперёд! Контент в кайф, можно ещё? Вообще красавчик!
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще? 😄 сказано? Сделано!
короче шуруп всему голова, я еще деду это говорил
Это все конечно очень интересно, но когда уже видос про энвилоуп?
Делать как все, это создавать серверное приложение только для обхода CORS политики? ну уж нет, спасибо.
Братан, контент в кайф. Давай, пили еще
братан хорош, красавчик и вот это вот всё
На последний вопрос могу контраргументировать виртуальным методом
Кайф. Аж покодить захотелось.
Нафиг нужен чистый код. Его раскритиковал какой-то чел, перевод которого есть на хабре.
Во-первых если у тебя 2+2 считается в разных модулях, между которыми ты провел архитектурную границу, то насрать на дублирование, переносимость важнее. Если же почуял жопой, что хорошо бы выделить фичу в отдельный сервис, то все остальные модули зависят от общей абстракции, которую ты можешь точечно подменить через DI, если потребуется.
Жизненно 😂