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

Где ещё почитать про антипаттерны разработки:

00:00 Тема видео, источник
00:15 О чём пойдёт речь в видео
00:50 Поток лавы
03:15 Blob
04:41 Непрерывное устаревание
05:14 Функциональная декомпозиция
06:29 Лодочный якорь
06:57 Золотой молоток
07:56 Спагетти-код
08:43 Копипаста
09:30 Mushroom management
10:01 Заключение и где ещё найти информацию

[fish]

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

[eagold]

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

[dieselm]

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

[KuzmaProDev]

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

[Epenckorn]

Ну, начнём с того, что идеальный код существует. Да, он есть. И не в стране радужных единорогов, а в нашем реальном мире.
Проблема в том, КАК программист закладывает время на решение той или иной задачи. Да, именно решение задачи, так как "написание кода" - это только часть рабочего процесса, причём не самая важная.

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

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

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

Сен же локальными задачами не занимается. Только не надо путать сена и тимлидом. Тимлид - это административная руководящая должность, он отвечает за показатели эффективности, за финансирование отдела/команды, за взаимодействие с другими отделами и распределение нагрузки на команду и ещё тонна других вопросов, половина из которые - это отчёты, а вторая половина - поддержание порядка и атмосферы в коллективе. Сен же - это не должность, а, как и предыдущие, уровень взаимодействия с проектом. Как правило, именно сен почти не пишет код и только собирает глобальные модули системы, следит за консистентностью и выстраивает архитектуру всего проекта. Максимум кода, который должен писать сен - это взаимодействие между модулями системы или обеспечение интерфейсов. Если сен пишет код для функциональных частей, то у меня плохие новости - ваша галера - дырявое корыто, причём настолько, что рулевой вынужден махать веслом наряду с гребцами, а кто в это время рулит и следит за фарватером - вопрос открытый. У каждого своя роль и не надо превращать архитектора в маляра. Как думаете, если сену придётся спуститься на уровень мидлов и писать функциональный код, помимо его собственных задач, он станет тратить время на причёсывание и документирование? Нет. Это не значит, что он этого не умеет или не хочет делать. Это значит, что у него нет времени на это. Если сен просрёт полимеры на своём уровне, то полетит к чертям весь проект. Приоритеты явно не на стороне рефакторинга функционального кода.

Вот и получается, что идеальный код существует, НО он требует дополнительных человекочасов, которыми не всегда готовы делиться в разработчиками ПМы. Ни один программист, сколь бы опытен и крут он ни был, не пишет идеальный код с первого раза. Идеальный код рождается только в процессе рефакторинга уже написанного и уже функционирующего кода. А все мы знаем, КАК в наших компаниях строится работа. "Дедлайн будет вчера" и "Главное - продать, а там как-нибудь слепим", думаю, знакомо многим. Поэтому идеальный код и превратился в миф для новичков. Всех нас на курсах и в институтах учили, что код должен быть читаемым, поддерживаемым, оптимизированным и тдитп. Да хрена лысого, не всех. Меня вот в универе учили, что давать значимые имена переменным небезопасно. Тогда это считалось идеальным кодом. Теперь за такую практику могут вообще уволить. Бизнес не переваривает академических подходов. Поэтому "идеальный код" ассоциируется с новичками (зелёными, невинными, неосквернёнными практикой), хотя никакой прямой связи нет.

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

[HaDaGaRa]

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

[NO]

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

[Adam_Aushev]

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

[jarogor]

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

[VintHeXer]

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

[guxershmeg]

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

[sixaxisization]

"идеальный код" - код который работает. Все остальное - чьи то хотелки.

[disketa]

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

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

[lavshyak]

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

[WounderVaflel]

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

[anonymousperson]

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

[ChilikovAleksandr]

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

[vasilykamenev]

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

[gramazavr]

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

[Игорь-гтщ]

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