ХУДШИЕ ПРАКТИКИ РАЗРАБОТКИ И АРХИТЕКТУРЫ за 12 минут

Забирайте 4000 бонусов на все облачные сервисы и удваивайте свои пополнения на сайте провайдера Cloud․ru: sc.link/FbkNt
Где ещё почитать про антипаттерны разработки:
www.amazon.com/AntiPatterns-William-J-Brown/dp/0471197130
antipatterns.com (и antipatterns.com/more.htm)
sourcemaking.com/antipatterns
00:00 Тема видео, источник
00:15 Скидочка на IT-инфраструктуру
01:25 О чём пойдёт речь в видео
02:02 Поток лавы
04:26 Blob
05:52 Непрерывное устаревание
06:25 Функциональная декомпозиция
07:40 Лодочный якорь
08:08 Золотой молоток
09:07 Спагетти-код
09:55 Копипаста
10:42 Mushroom management
11:14 Заключение и где ещё найти информацию
Поддержать канал разово - yoomoney.ru/to/410012243709514
Поддержать канал подпиской - boosty.to/listenit
Телеграм-канал - t.me/listenit_channel
Я.Дзен - zen.yandex.ru/listenit
По вопросам сотрудничества - t.me/ed_akimov
Ссылка на статью - habr.com/ru/companies/gazprom...
События и статьи про анализ и проектирование ИТ-систем - t.me/itsysdes_events
Объектно-ориентированное программирование за 10 минут - • Объектно-ориентированн...
Что такое DDD за 10 минут с примерами - • Что такое DDD за 10 ми...
Что такое SSO за 13 минут - • Что такое SSO за 13 минут
Что такое OAuth 2.0 и OpenID Connect за 15 минут - • Что такое OAuth 2.0 и ...
Что такое JWT и как его создать - • Что такое JWT и как ег...
Компиляция и интерпретация за 10 минут - • Компиляция и интерпрет...
Что такое TypeScript за 9 минут - • Что такое TypeScript з...
Что такое SQL и реляционные базы данных - • Что такое SQL и реляци...
Синтаксис SQL запросов: Часть 1 - • Синтаксис SQL запросов...
Что такое SQL ИНДЕКСЫ за 10 минут - • Что такое SQL ИНДЕКСЫ ...
Что такое NoSQL за 6 минут - • Что такое NoSQL за 6 м...
Что такое ACID за 9 минут - • Что такое ACID за 9 минут
Что такое UML за 7 минут - • Что такое UML за 7 мин...
Что такое Scrum за 8 минут - • Что такое Scrum за 8 м...
Обзор Agile - • Обзор Agile. Это метод...
Приоритизация бэклога за 4 минуты - • Приоритизация бэклога ...
Что такое Kanban - • Что такое Канбан-метод...
Что такое Канбан-доска - • Канбан-доска - это не ...
Что такое HTTP и HTTPS за 9 минут - • Что такое HTTP и HTTPS...
Машинное обучение для чайников - • Машинное обучение для ...
Что такое Big Data за 6 минут - • Что такое Big Data за ...
Что такое CRUD за 6 минут - • Что такое CRUD за 6 минут
Введение в REST API за 7 минут - • Введение в REST API за...
Различия REST и SOAP за 4 минуты - • Различия REST и SOAP з...
Что такое middleware за 7 минут - • Что такое middleware з...
Что такое UML за 7 минут - • Что такое UML за 7 мин...

[@fish9370]

Делайте хорошо, а плохо не делайте. Обожаю такие советы. Чем моложе программист, тем больше он верит в идеальный код

[@user-qn7kg6yk8c]

Я бы еще добавил что ЛЮБОЙ уволившийся программист оставляет после себя быдлокод, как и на чем он бы небыл написан, по мнению нового сотрудника. Поэтому на совет "специалиста" делай вот так а не так, всегда найдется другой "специалист" которой посоветует все наоборот.

[@fpedotovvalentin]

Мало кто понимает, что значит "идеальный код" и как его писать. А главное - зачем он вообще нужен, если любой код работает, когда он только написан.

[@eagold]

10:00 я думал щас скажет что под грибами писать код не самая лучшая идея

[@dieselm3562]

Лично мне Blop напомнил эдакую "универсальную папку" на жёстком диске, в которую сваливаются файлы, которые не удалось больше никуда приткнуть. Со временем такие папки разрастаются до таких размеров, что их пора бы разобрать, однако мало кто решается, ибо это нужно копаться, распределять, раздумывать, да и объём работы отпугивает.

[@KuzmaProDev]

Как-то ни о чём, слишком общо, на анти-паттерны не тянет, потому что это рассказ про неправильные процессы, а не неправильную структуру кода. Чего только стоит копи-паста. Ещё скажите, что автодополнение это антипаттерн.

[@uuuummm9]

Любители каждый пук называть архитектурой, есть такое.

[@HaDaGaRa]

Всё думал, как описать проект, где я работаю. А тут целое видео как раз про него Х)

[@N5O1]

10:30 во всей статье приводятся примеры всем понятных плохих решений, которые все знают и понимают. если человек так делает, то это не проьлема разработчика или архитектора. это проьлема менеджмента и сейлзов. в 98% случаев это происходит из-за очень сильно сжатых сроков/бюджетов или из-за недостатка требований/криво поставленых задач. у нас все жалуются на менеджеров и скрам. но начинают выть когда попадабт на проект без менеджеров

[@user-vu6hn4ul2i]

Не, задача менеджера - получить результат с минимальными затратами. Задача сейлза - продавать. Нужен тот, кто скажет им "тут нужно сделать так, это потребует столько-то денежных ресурсов (часов работы программиста) и столько-то времени". А потом обосновать свое решение. А они уже должны от этого составить свои планы, дедлайны, KPI и прочее.

[@BaggerPRO]

@@user-vu6hn4ul2i Короче, техлид нужен или архитектор )

[@VintHeXer]

5:53 Кроме шуток, мне приходилось переводить проект с питона 2.6 и джанго 1.0.5 на хотя бы питон 2.7 с джангой 1.16, на это ушло куча времени (питон пришлось собирать из-за среды из исходников). В дальнейшем я уволился, а проект так и застыл, т.к. там использовались такие батарейки и доп-компоненты, что устарели ещё лет 9 назад, а перепись функционала на новый лад потребовала бы год как минимум

[@VintHeXer]

@@eprst0 новые требования при интеграции с другими системами. Например, работа с сертификатами платёжных апи

[@lavshyak9640]

Ну в общем: нормально делай - нормально будет

[@guxershmeg]

Я не встречал хорошей реализации SOLID. Обычно там что-то понять можно только в отладчике, что требует воссоздать условия воспроизвести баг у себя. Еще архитектура под юнит тесты говно. На практике они вообще ничего не ловят, ничего, а код усложняют многократно. Т.е. 1 интеграционный тест это как 1000 юнит тестов по полезности.

[@Korrmet]

Интеграционные тесты проверяют несколько успешных сценариев и как раз баги они ловят очень редко. Они больше для доказательства, что заявленные фичи работают, нужны. Боги именно юнитами и вылавливаются, потому их так много.

[@guxershmeg]

@@Korrmet значит у нас люди, которые писали юнит-тесты, не справились. И я в том числе. несколько тысяч этих юнитов с мок-объектами. Абсолютно бесполезны, они и тестируют-то не алгоритмы у нас, а типа что вызов прошел из одного объекта через интерфейсы в другой. Т.е. вводо-вывод юниты не должны проверять, а у нас только такое и проверяют.

[@Korrmet]

@@guxershmeg ну так это вы сами кузнецы счастья своего. Проверка реакции на вход - это по идее самое такое простое, очевидное и универсальное, что можно сделать. А так тебе никто не запрещает юнитами алгоритмы проверять. Более того, у тебя по идее должно быть покрытие кода тестами не менее такого, а если только говно на вход пихалось, то скорее всего покрытие там мизерное, самое начало функции, где проверяются аргументы, и все.

[@KuzmaProDev]

Тесты лечатся BDD. Вы правы, что юнит тесты часто ничего не тестируют, вот BDD и рекомендует тестировать поведение, а не куски(юниты) кода. А это ближе к интеграционному тестированию, хотя и не обязательно так.

[@jarogor]

Разновидность потока лавы это когда один начал внедрять какой-то системный механизм на полпути забыл/бросил, другой на этой базе начал внедрять другой механизм и тоже недоделал, третий тоже и так далее, в итоге код это сплошная куча недоделак, в котором прослеживаются признаки каких-то намерений, но ни одно не доведено до логического завершения

[@nadkoch]

Это не поток лавы это "чужой код говно я сделаю лучше".

[@user-np4tn3rg4l]

Это письмо родителям из Простоквашино

[@disketa25]

5:52 не назвал бы это плохим паттерном, если проект статичен и не зависит от внешнего окружения (напр-р, выполняется в командной строке или опирается на «основы основ», которые не поменяют никогда). Все костыли уже известны, новых багов (по вине платформы) нет и не будет, а случайное обновление не угробит всё (и уж тем более не заставит переписывать половину кода), потому что оно, собственно, и не потребуется. План по разработке и добавлению фич можно хоть на пятилетку вперед прописать. Эталонный пример - немалая доля того же библиотечного ПО нашей необъятной. Да, это в большинстве случаев монстр на Delphi, написанный примерно в начале нулевых, но он умеет все, что от него нужно, быстро работает на устаревшем железе и толерантен к новым ОС, так как работает со стандартными компонентами Windows (слава обратной совместимости) вместо костылей на костылях, не совместимых ни с чем, кроме самих себя. Или те самые консольные утилиты класса «ересь на ввод, ересь на вывод», от которых нужна только стабильность и предсказуемость. Или веб-сайты на допотопных, самописных PHP-движках - но зато, опять же, ломаться там нечему, все оттестировано, а весь нужный функционал давно прикручен - дальше только неспешная поддержка и доработка.

[@rchaser]

Я б даж добавил гонка за новыми технологиями это современная повсеместная БЕДА джун-мидлов иногда и сеньоров, "выкинуть все это ваше легаси и переписать на новых технологиях" голубая мечта многих и многих разработчиков, а вот бизнесу это нафиг не уперлось тратить месяцами деньги на то чтобы получить в итоге тот же самый функционал есть смысл прыгать на новую технологию если поддержка старой сильно дорого, и код серьезно сыпется

[@fpedotovvalentin]

вот в том то и дело, пока не приходится в нем копаться, разбираться, править и вынуждено добавлять функциональность (например учет изменений законодательства в каких-нибудь банковских системах) то смысла переписывать нет никакого, но и это не является проблемой, т.к. разработка в таких системах ведется крайне редко. Но если с кодом приходится постоянно работать, пытаться понять как это чудовище работает а если задокументировать то разобраться бывает сложнее, чем разобраться в коде или переписать, тут уже можно и подумать о рефакторинге.

[@stonepilot56]

Да, и все было бы хорошо и радостно, если бы не кибербез, да?

[@Alex_Lutor]

Спасибо за материал , хотел подписаться , но уже подписан оказывается ))

[@user-eh1jm4nv2b]

7:29 в верху Calculate Load, а внизу Calculate Loan

[@aysu9533]

Расскажите про API Driven Design

[@chikenmacnugget]

Водица однако

[@dondragon6949]

сто пудов.... со всех утюгов одно и тоже вода)

[@anonymousperson2640]

Про Job Security расскажите лучше и о том в чем же глубокий смысл писать код, который может прочитать кто-то кроме тебя, если ты наёмный работник... Это как будто самому себе в колено стрелять...

[@Epenckorn]

Ну, начнём с того, что идеальный код существует. Да, он есть. И не в стране радужных единорогов, а в нашем реальном мире. Проблема в том, КАК программист закладывает время на решение той или иной задачи. Да, именно решение задачи, так как "написание кода" - это только часть рабочего процесса, причём не самая важная. Например как задачу решает стажёр? Прочитал текст задачи, нагуглил решение, скопипастил, сдал. Хорошо, если при этом он его хотя бы протестил в какой-нибудь песочнице. Стажёр вообще не способен оценить требуемое время для выполнения задачи. А как задачу решает джун? Прочитал текст задачи, нагуглил решение, разобрался, как оно работает, написал свой говнокод, протестил, если работает, то сдал и забыл. Логика простая: работает - значит готово. При этом джун уже что-то представляет о том, сколько времени у него может занять поиск решения и написание и тестирование своего кода. Если за ту же задачу возьмётся мидл, то вот тут начинаются радикальные отличия. Мидл прекрасно знает, что написать рабочий код - требует немного времени. Он знает, что 3/4 решений, предлагаемых в интернете, либо узко заточены, либо представляют из себя говнокод. Понимает, что правильнее - не тратить время на гуглёж и написать самому. Только вот мидл понимает, что если он напишет "лишь бы работало", как джун, то, рано или поздно, он сам же вляпается в собственный же код, только на тот момент уже не будет его помнить. Кроме того, он прекрасно понимает, что в потоке работы он точно не вернётся к этому куску кода "в следующий четверг, пораньше зайду, удалю эти временные флаги, причешу именования, сейчас некогда". Я часто сталкивался с таким, что прогеру некогда или лень даже задокументировать свою лепёху, он это откладывает до вечера, потом до завтра, а завтра новый поток задач, забыл, забил, замотался. Я это называю 3З (тризэ). Как же этого избежать? Если мидл не задумывается об этом, то у меня новость - это не мидл. Мидл изначально закладывает в срок выполнение задачи: декомпозиция задачи, ресёрч решения, написание кода, тестирование, причёсывание кода, повторное тестирование, документирование. И только пройдя ВЕСЬ этот путь, пушит изменения. А дальше уже гитмастер или сен проверяет конфликты и по документации понимает, что с этими конфликтами делать. Сен же локальными задачами не занимается. Только не надо путать сена и тимлидом. Тимлид - это административная руководящая должность, он отвечает за показатели эффективности, за финансирование отдела/команды, за взаимодействие с другими отделами и распределение нагрузки на команду и ещё тонна других вопросов, половина из которые - это отчёты, а вторая половина - поддержание порядка и атмосферы в коллективе. Сен же - это не должность, а, как и предыдущие, уровень взаимодействия с проектом. Как правило, именно сен почти не пишет код и только собирает глобальные модули системы, следит за консистентностью и выстраивает архитектуру всего проекта. Максимум кода, который должен писать сен - это взаимодействие между модулями системы или обеспечение интерфейсов. Если сен пишет код для функциональных частей, то у меня плохие новости - ваша галера - дырявое корыто, причём настолько, что рулевой вынужден махать веслом наряду с гребцами, а кто в это время рулит и следит за фарватером - вопрос открытый. У каждого своя роль и не надо превращать архитектора в маляра. Как думаете, если сену придётся спуститься на уровень мидлов и писать функциональный код, помимо его собственных задач, он станет тратить время на причёсывание и документирование? Нет. Это не значит, что он этого не умеет или не хочет делать. Это значит, что у него нет времени на это. Если сен просрёт полимеры на своём уровне, то полетит к чертям весь проект. Приоритеты явно не на стороне рефакторинга функционального кода. Вот и получается, что идеальный код существует, НО он требует дополнительных человекочасов, которыми не всегда готовы делиться в разработчиками ПМы. Ни один программист, сколь бы опытен и крут он ни был, не пишет идеальный код с первого раза. Идеальный код рождается только в процессе рефакторинга уже написанного и уже функционирующего кода. А все мы знаем, КАК в наших компаниях строится работа. "Дедлайн будет вчера" и "Главное - продать, а там как-нибудь слепим", думаю, знакомо многим. Поэтому идеальный код и превратился в миф для новичков. Всех нас на курсах и в институтах учили, что код должен быть читаемым, поддерживаемым, оптимизированным и тдитп. Да хрена лысого, не всех. Меня вот в универе учили, что давать значимые имена переменным небезопасно. Тогда это считалось идеальным кодом. Теперь за такую практику могут вообще уволить. Бизнес не переваривает академических подходов. Поэтому "идеальный код" ассоциируется с новичками (зелёными, невинными, неосквернёнными практикой), хотя никакой прямой связи нет. Честно, пока писал, уже забыл, к чему я всё это. Наверное, к комментариям некоторых зрителей. В общем, пусть будет.

[@ChilikovAleksandr]

Спасибо автору за грамотно изложенный материал)

[@andreyivanov2912]

Где палатка первой помощи?

[@sergeykhairulin]

или ход тряпок 😄

[@WounderVaflel]

3:50 записывайте всех, Господь узнает своих©

[@dydai]

Хороший канал, жаль мало подписчиков. Желаю дальнейшего развития!

[@mercury_2379]

го еще про API Driven Design, интересно

[@redkostia]

Почему мне тут мой код показывают?😂😂

[@user-gc3bt1sq8d]

Не могу понять зачем использовать эти вырвиглазные цвета в оформлении. А так спасибо за ролик.

[@vasilykamenev844]

на хабре лайкнуть не могу - нужна регистрация - лайкнул тут. в банках всё именно вот так через %опу!

[@N5O1]

Короче говоря все что нарушает принципы ООП и SOLID, это плохо. Но это и так понятно Я толькл не понял про "золотой молоток" это хорошо или плохо? или "сидром утенка" это хорошо?

[@soppuistoppu1600]

Когда как. Имхо, главная проблема таких видосов с хорошими и плохими практиками - объявление "хорошего" хорошим и "плохого" плохим практически без объяснения случаев, когда эти две роли могут диаметрально противоположно поменяться местами (благо, тут в некоторых местах попытались объяснить, когда хорошая, казалось бы, идея становится плохой и наоборот). Про молоток и синдром утёнка - явно хорошо, если затраты на введение чего-то нового несоизмеримы с прибылью, полученной от внедрения новых практик. Как по мне, это довольно часто встречающаяся вещь в веб разработке - желание ввести новый фреймворк в работу потому что он новый, а не потому что он реально решает какие-то проблемы, которые не мог решить старый. А, ну и развитие нейросетей внесло свою лепту - каждый хочет добавит их в свой проект, даже если они нафиг не нужны и можно обойтись алгоритмами Про функциональную декомпозицию тоже могу пару слов сказать - это наоборот хорошо, когда НЕ ТРЕБУЕТСЯ ООП интерфейс. Например, я не буду реализовать класс Math с кучей интерфейсов для реализации математических операций - я реализую несколько функций, поскольку реализация класса будет в данном случае избыточной Про поток лавы, в целом, сказано правильно - не вижу ничего плохого в том, чтобы использовать его в краткосрочной перспективе, но надо быть абсолютно точно уверенным, что этот код пишется, чтобы в дальнейшем быть удаленным полностью или он вообще никогда не будет меняться (это, кстати, крайне маловероятно) - если такой уверенности нет, то лучше не использовать вообще (настрадался на собственном опыте) Про блоб (так же известный как God Object) - в целом да, однозначно плохо, поскольку потом крайне сложно поддерживать код с его участием (а если учесть, что в нем однозначно есть спагетти код, то вообще красота), но все же его тоже можно сделать хорошим 🙃 Питоновские модули часто этим "страдают" - предоставляют какой-нибудь один глобальный кор объект с кучей интерфейсов (а в питоне модуль - тоже объект), через который осуществляется практически все взаимодействие, но внутри он, тем не менее, хорошо или относительно хорошо структурирован - logger, dataclass, abc как примеры, поскольку позволяют импортировать ОДИН объект, который позволяет сделать практически все (да, они предоставляют и другие интерфейсы, но зачастую они используются не особо нужны) С остальным, в целом, согласен

[@FuriousBoreas]

Золотой молоток тут в негативном свете, потому что вместо того чтобы выбрать правильный и более подходящий подход, часто натягивают саму задачу на существующий подход. Но тут нужно понимать что случаи разные и иногда это нормально и экономит деньги, а иногда может создать большой технический долг.

[@Kirill.Bogdanovich]

Очень информационные ролики, благодарю за вашу работу ✊ Скажите пожалуйста, каким образом делаются подобные анимированные ролики как у вас? Или какой инструментарий используется для подобной анимации(визуального ряда)?

[@Adam_Aushev]

Блин, чувак, где то пол года назад я подумал - вот бы было прикольно озвучивать статьи из хабра, стопроцентно никто ещё это не сделал, и вот я натыкаюсь на твой канал) Это классная идея, буду ещё искать подкасты если они у тебя есть, идея крутая, ты крут!

[@ListenIT_channel]

Ровно так я и начал свой канал) Спасибо! Подкаста полноценного пока нет, то в Телеграм выкладываю аудио-версии выпусков, чтобы можно было с выключенным экраном слушать.

[@user-ni9tf5yr6m]

Годная тема

[@funfunfun536]

9:25 SCSI читается как "скАзи" (да, в википедии написано и про вариант из видео, но неужели в русскоязычном IT так кто-то говорит?!)

[@bumblebee_1]

Спасибо, было интересно :)

[@vitaliy0192]

Работаю на проекте в банке из топ-10. Действительно всё так, как описано.

[@user-vu6hn4ul2i]

Тест на олдов: кто узнал звук вначале видео?

[@muggzzzzz]

Оживление юнитов в героях 3-х, не?

[@user-vu6hn4ul2i]

@@muggzzzzz близко, но нет.

[@botsynth]

как ты придумал совместить в своих роликах визуализацию окна с адресом из мира майкрософт и кнопки окна из чего-то другого?)

[@fedordostoevskiy4209]

Все фигня, давай сначала) Если головы нет.. 😂

[@uipo1122]

пятикратно переваренный калл, потраченного времени, конечно же, жаль

[@user-vu6hn4ul2i]

Шестикратно, получается 😂

[@Rogov_Oleg]

Корень бед - текучка кадров. И копипаст.

[@eienni9168]

Долой ООП

[@nadkoch]

Это всё обычное словоблудие про практики разработки и шаблоны, програмист сходу понимает только свой код, часто не понимает чем вызваны решения чужого кода, хочет улучшить, а улучшить не получается. Поток же лавы - это не взять старый код, поток лавы это когда нет никакого кода и примеров, и пишут код на бум, это проблема новичка.

[@xaartofering7494]

я вще не прогромисть я дохрена дизигнер и по этому весь ролик смотрел на просветы между пикселями

[@user-in3gg1xp4w]

как достали рекламой о полезного на 3 копейки

[@opossum1312]

Ах еный ролик. Реклама сразу в лицо, тупо зачитка чужой статьи из хабра, а визуал это только текст.

[@rw_panic0_0]

ужасное видео, автор мало понимает о чем говорит

[@Shmykario]

Классный коммент. Многое объясняет... А можно я под вашим комментариям оставлю такой же?

[@Korrmet]

Если честно, у меня такое ощущение, что в СНГ под архитектурой в принципе понимают не взвешенное расписывание функциональное продукта в общих чертах, не работу над механизмами для конкретного проекта, ни работу над обеспечением характеристик, а нечто совершенно другое, и у каждого это другое - что-то только одному ему понятное.

[@rw_panic0_0]

​@@Shmykarioпересмотри например пункт под 6:12, просто пиздец полный мягко говоря, писал просто чел который две недели в программировании

[@bivashy]

Стоит учитывать что это зачитвает диктор, не более. Поэтому крайне не разумно говорить что видео ужасное

[@rumisbadforyou9670]

Особенно нравится когда люди винят не первопричину, а симптомы. Вроде программированию 40 с хуем лет, а тейки такие, будто чел только с первого курса выпустился. Учитывая как люто автор статьи топит за ООП в 2024 веке, гарантирую что он ещё "чистый код" будет рекомендовать к прочтению.

[@iamtruth9631]

"Системный аналитик"...🤣 Детский сад, да и только.

[@ListenIT_channel]

Почему? :)

[@lavshyak9640]

Голос как у школьника, лайк не ставлю

[@logsjomia965]

Гений