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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Годная тема

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

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

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

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

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

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

Долой ООП

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

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

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

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

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

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

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

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