14 признаков плохого кода
Vložit
- čas přidán 24. 02. 2019
- Профессия Веб-разработчик от Loftschool loftschool.com/professions/we...
Книга: / 2627056840
Поддержать канал: / seniorsoftwarevlogger
Сайт: seniorsoftwarevlogger.com
Моя техника и другие штуки kit.co/seniorsoftwarevlogger/...
Спасибо Дима ! Отлично как всегда ! МОНИТОР ХОРОШ ;)
надо было добавить в конце "а может подаришь, а..."
Писать код нужно так, будто человек который будет поддерживать твой код знает где ты живешь 😂
Забыл еще упомянуть, что он маньяк)))
вроде смех смехом, но рабочее правило... лучше развивать ярую самокритику, тоже рабочая фишка, честно задавать себе вопрос - пропустил бы ты сам такой код или нет... и как ни странно в 80% всегда что то находишь...
Благодарю) Ваша информация спасает меня от лени, добавляет мотивации, освежает мои знания; слушаю вас в перерывах между обучением программирования)
Thank you so much for this very useful information!
Если не бить код на функции, классы, модули - прощай хорошие автотесты (а значит прощай долгосрочная поддержка), ухудшается переиспользуемость кода, ухудшается читабельность кода (если модули и методы названы правильно, что в общем тоже искусство своего рода, но все же) и тд. Да, мысли к размышлению интересные в книге, но больно много спорных вещей
Спасибо Дмитрий!)
Думал, мини-гантеля лежит на столе, присмотрелся - наушники :) Даешь больше физических упражнений!
Спасибо, надо будет заиметь эту книгу себе )
как же это все вовремя и к месту, я пытался партитилить класс по разным темам, но тем оказалось много
Лайк по константе. Спасибо =)
Отличное видео.
5 пункт как раз такой противоречивый: в случае если используется 3d-party library бывает довольно неплохо закрыться фасадом. Во внутреннем коде , конечно это оверхед.
По большей части копирует "совершенный код", но также есть несколько очень интересных новых идей. А так общая мысль довольно очевидна: пишешь модуль - думай о тех, кто будет им пользоваться.
лофтскул на лбу еще бы написал, точно бы перешел по ссылке))
Действительно, некоторые заявления автора довольно смелые и слегка субъективные. Есть конечно и некоторое зерно истины. Но в целом, главная мысль в том, чтобы не просто бездумно писать интерфейсы, потокая всеобщим стандартам говнокода, а продумывать каждое своё действие. Дьявол в деталях. С таким подходом и рождаются топовые спецы. Это программирование головного мозга.)
Для тех кто не осилил SOLID
Я вообще считаю, что хороший кодер тот, кто связывает мостом жизнь и программирование. Он пишет программы рационально и сам живет также, пришел к пониманию золотой зередины, что нельзя жить белым или черным. Суть кода подкреплена его идеологией. Программирование, это его способ реализовать свои интеллектуальные потребности, а сам он занимается многим, имеет очень обширный кругозор. Каждый поход в магазин выглядит, как очень оптимизированный алгоритм, никаких лишних движений, но в то же время понимает, что эстетика имеет такую же ценность, что и логика с ее минималистичностью, и поэтому он не берет огаленными руками картошку, чтобы упаковать ее и взвесить, а орудует пакетом, как перчаткой. Не пачкает себя, но и не боится запачкаться. Баланс всего...
@@GarifullinMichael holly Bob Martin church
Наконец-то :)
Отличное видео, а если бы ещё с примерами то вообще бы цены не было, но все равно лайк
Будут ещё видео про хобби?
Расскажи про паттерны проектирования
Зачем использовать слишком общие названия переменных x, y - когда можно вместо них задействовать i, j!
i, j уже задействованы в циклах, поэтому мы используем a, b
Чтобы было понятнее используйте «_», «__» 😂
Ну ладно можно в цикле использовать key и val или просто k и v
А текстовый редактор научать как сделать ?
Ничего не понял, но очень интересно))
Дмитрий, а что за книжечка у Вас в руках? Вы конспектируете прочитанное?
Готовил конспект для видео
Спасибо
Мне кажется я где-то это видео уже видел :)
3:57 - "использование модуля можно избежать, если просто напрямую будете использовать те конструкции, которые в нем спрятаны" - есть такой момент, что эти конструкции могут использоваться повторно слишком много где и проще сделать один класс (буду выражаться в терминах ООП). Другое дело, конечно, продумать этот класс так, чтобы интерфейс был попроще и вся сложность внутри класса была спрятана, это да. Ну и НАВЕРНОЕ (подчеркну, что в дальнейших своих рассуждениях не совсем уверен) если совсем никак нельзя сделать интерфейс простым, а эта логика, заложенная в этом классе слишком много где используется, то пусть все равно будет этот класс с худо-бедным интерфейсом, чем сто раз писать одно и то же. И вообще, программирование это такое дело, всегда найдется сто различных "но" и частных случаев, и везде можно спорить. Просто книга еще раз напоминает о том, что нельзя ничего с полной уверенностью утверждать, нужно всегда включать мозги и обдумывать все, и нельзя вдаваться в крайности.
Флагом Pass-through набит самый тяжёлый объект во Вселенной - node_modules. Однажды я решил покопаться там, чтобы выяснить нафига там тысячи папок. Оказалось, что в одной папке находится файл, который импортирует функцию из другой папки и следующей строкой делает её экспорт. ВСЁ!! больше в папке ничего не было. Если не ошибаюсь, это была библиотека из пяти папок что-то типа ansi color. Бессмысленно и бесполезно.
Про 11 флаг: можно было бы использовать row и column) Покороче и понятнее вроде
Дмитрий, ну а Вы-то с первым замечанием про поверхностные модули согласны? С другой стороны ведь программист может до конца не осознавать концепции своего софта, иногда задачи приходят сверху. И такие глубокие модули могут требовать большего времени на изменение. Есть вероятность, что первая их версия будет делать не то, если задача достаточно объемная.
На сколько удобно использовать трекпад вместо мыши?
Настолько, что у меня нет ни одной мыши в доме
@@SeniorSoftwareVlogger Почти 2 года использую макбук и никак не могу перейти на трекпад. Основная сложность - это выделение больших участков текста. Одной рукой это возможно делать?
У меня 3-х пальцевое движение для этого. Просто веду не одним, а 3 пальцами и нет проблем.
Мне нравится
Мне кажется, что большинство проблем с модулями возникают из-за преждевременной оптимизации или преждевременного разделения
да, вот столкнешься с одной и той же задачей пару раз, задумаешься и начнешь лепить модуль - это лучше, чем сразу. Я вообще начинаю просто в одном методе сначала тупо расписывать всю логику. Потом рефакторинг.
@@loam на счёт опыта согласен, и на счёт одного большого файла тоже :)
@@loam Тимур, сначала продумывается архитектура, потом пилится код. Очень хорошо продумывается архитектура, чтобы говнокодеры не рефакторили по сто раз.
@@eugenenovikov671 Зависит от задачи. Архитектура продумываю сначала, если это достаточно объемная задача.
@@loam вот я сижу и разгребаю эти объёмные задачи на 1000 строк каждый метод, которые судя по коды были натыками с форумов по кускам за ночь лишь бы работало, и это энтерпрайз гос подрядчика в Москве, что творится в регионах и представить страшно. Архитектура должна быть ВЕЗДЕ И ВСЕГДА.
с 13 можно поспорить, ведь можна аналитически определить
Про комментарии. Они могут быть полезны. Но при имении кода их никто не поддерживает. И они становится басполезными. Как вариант это некоторый контракт на api. Например поведение при null. Или допустимые величины. Например функция парсящая дату. Монно указать допустимый формат входящий строки. Но потом все равно никто эту хрень не поддерживает.
Покажите мне человека, который в разные модули засовывает чтение и запись хD
Проблемы в коде зависят от бизнеса, в реальном мире все не так как ты говоришь.... В реальном мире бизнес давит временем. Идеальный код только на пет проектах)
На поддержку хорошего кода тратится в десятки раз меньше времени, чем на поддержку плохого. Поэтому хороший код оправдан, даже если его писать в несколько раз дольше.
@@user-gz3wv1yr2f Я всегда это слышу на конференциях, митапах, курсах, но когда прихожу работать в крупную компанию, банки, продуктовые итд, везде творится пиздец, потому что "Мы не успеваем, потом сделаем"
@@ivansidorov5, не знаю, у меня всё спокойно, пишу код как считаю нужным. Даже наоборот начальство просит модульные тесты, и другие подстраховки.
И со сроками проблем нет.
@@user-gz3wv1yr2f Значит проект маленький. у меня проекты были все крупные, котоырми уже пользуются много людей и там нужно решить задачу еще вчера. либо в тубя проект который только зарождается, еще про него никто не знает и все пофиш впринципе на сроки)
Вся реализация кода зависит от поставленной задачи и только от неё! Поэтому, и сложность модуля зависит от поставленной задачи, а не от того глубокая программа или поверхностная. Те участки кода, которые вызываются многократно имеет смысл сделать в виде отдельных подпрограмм. Самое главное, уметь писать грамотный код. Но для этого нужен талант и понимание концепции программирования. Если хотим, чтобы программа занимала не слишком много процессорного времени либо места в ОЗУ или точнее в этом есть необходимость, то существует оптимизация. Но опять же, грамотный код часто является одновременно и оптимизированным. В общем, думайте прежде всего над тем, что вы пишите, а всякую глубину модулей и прочую ахинею пошлите куда подальше.
Советы прям совсем субъективные. У меня на работе есть два отличных backend программиста. Профессионалы высокого класса, Мне до них в программировании ещё очень далеко, т.к. мои программы-по сравнению с их это такие инвалиды с костылями. Пишут вместе здоровенную программу с кучей подключаемых библиотек по математической обработке сигналов. Так вот даже они иной раз друг с другом спорят о том как должен выглядеть код. Какую функцию написать, какой класс ввести. Даже они не имеют единого мнения. А тут понимаете советы о том как построить структуру программы.
Ну надо же как-то учиться, а собственное мнение и взгляд на все появляются с опытом
2:58 зато тестировать проще, а это лучше. Написал тесты и следить не придется.
@@MrCortc, я тоже таких людей до усрачки боюсь, поэтому я проповедую написать вначале код, а потом тесты.
@@sasichkamega А как же TDD? Судя по тенденциям, такой подход очень заходит
@@user-ul7pm1tb5x, я не понимаю что ты мне пытаешься сказать. Что tdd? Ну tdd, знаю такое слово. Я тебя не понимаю.
not unix way
??
Что за надпись на руке?
My choice
Over exposure - я бы перевел, как "чрезмерное выставление напоказ", "чрезмерное обнажение", в контексте о внутренностях класса.
Я думал назвать "интерфейсный эксгибиционизм", но потом передумал :)
@@SeniorSoftwareVlogger тоже не плохо.
P. S. Подписался ;) Заметил, что это не впервые, когда смотрю ваши видео и при этом почему-т овсе еще не подписан :)
Пересказ книжек от старшого или Место красит человека
// Replaces with spaces
// the braces in cases
// where braces in places
// cause stasis.
$str = str_replace(array("\{", "\}"), " ", $str);
Графомания по большому счету, обсасывающая очевидные истины.
Дмитрий, спасибо. Очень интересно. Правда вот тут - czcams.com/video/SZLdme0zvV4/video.html вы говорите о "протекании информации", а это случайно не о Leaky abstraction - www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/, просто очень похож посыл
Пересказ очевидных вещей плюс реклама лофтскул
Кто с 2022
Книга в некоторых вещах противоречит Clean Code.
Автор Clean Code - ну очень известный человек, автор многих сильных книг, реальный разработчик, описанные им практики проверены временем.
Автор этой книги - профессор (т.е. тотальный теоретик), написавший всего одну книгу, причем совсем недавно.
У меня все.
Когда то был момент когда дядя боб тоже написал свою первую книгу и был автором одной книги. Книга противоречивая, как я и сказал, но при этом хороший материал для мыслей.
Тоже читал Clean Code и практически все моменты в книге казались логичными. По пересказу Дмитрия показалось что есть моменты вступающие в противоречие с Clean Code, который насколько я понимаю является чуть ли не стандартом в разработке.
вЕб разработчик....
Вьеб!
Кто это на маленьких портретах под монитором?
Последняя ссылка в описании
Пиконка это, что-то вроде иконки для атеистов с изображением выдающихся научных деятелей :)
@@SerhiiYenin Интересно, что некоторые из них были креоционистами)
@@konstantinkudelko7545 можно простить им их невежество, все таки давно это было...;)
Есть ещё одна причина не способности правильно написать комментарий или документацию к модулю, а так же подобрать правильно имя - это низкий уровень английского языка)
С точки зрения программирования, если рассматривать все более глубоко все это полная чушь и дрочетта, только голову себе забивать этими книжками
Вся беда современных разработчиков что все разучились думать алгоритмически. Сказывается отсутствие практики на ANSI C у 99% разработчиков. C - это пожалуй самый важный язык, даже если в будущем на нём вы писать не будете. Большинство задач люди решают создав совершенно сумасшедшую архитектуру чёрт знает зачем, в то время как опытный разработчик на C или ML напишет решение в одном двух файлах-модулях на 500 строк кода правильно подключив мозг к решению. И это решение будет ещё и в десятки раз производительнее. Довелось видеть решения олимпиадных задач (многие из них вполне классические и типовые в обычной практике), помогите мне это развидеть. То что люди решают на C/C++ в 500 строках кода разработчики на Java решают создав дохрена классов и все равно в итоге работает через жопу, а чаще не работает вообще проваливая тесты "неудобных" случаев. Какой вообще смысл в "долгосрочной" поддержке, если фундамент из говна в 90% случаев? Этим объясняется НУ ОЧЕНЬ тормознутые решения. Производительность заменили "отзывчивостью", то есть если UI не тормозят, то норм, пофиг нам на расход памяти и полезную производительность. Вообще как ни странно самыми меньшими ублюдками в индустрии помимо Big Data и AI, куда на значимые должности обезьянкам дорога заказана являются разработчики движков для видеоигр, т.к. если в играх будут потери производительности по вине движка - любую студию или издателя сообщество уничтожит и это пожалуй один из немногих разделов индустрии, где люди ещё задумываются о высокой производительности решений, а если нет - получайте 15 FPS с графикой прошлого поколения и полный разгром в перспективах. В прочем бизнесе решения доходят до хохмы, когда для какой-нибудь галереи или обработке персональных данных придурки создают запутанные цепи взаимных обратных вызовов. То есть маразм доходит до того, что тупо написать с нуля получается более простой задачей, чем поддерживать старый код "по всем канонам ООП" API которого уже сложнее собственного инструмента. Да и не забывайте, что ядро Linux написано на чистом C, OpenGL написан на чистом C и эти проекты в сотни раз сложнее большинства типовых решений офисного планктона и также очень требовательны к совместимости и производительности не говоря о том, что C - это не ООП язык вообще. То есть получается веселье, где задроты C создают более эффективный и производительный код, чем ООП-люди с тонной готовых решений на все случаи жизни. В итоге лучшим советом может быть только один: как можно больше практиковаться! Применять простые и производительные решения, если это возможно. Со временем, ВОЗМОЖНО, НЕКОТОРЫЕ типовые решения окажутся очень полезными для задач, и вы будете использовать их там где этим решениям есть место, а не х** пойми где. Более того с опытом большинство успешных паттернов сами воспроизведутся в том или ином виде вашим собственным интеллектом, если конечно есть интеллект. В любом случае при решении сложных задач новички будут страдать, а при решении простых будут страдать ПОЛЬЗОВАТЕЛИ. Никогда не казалось странным почему в видеоиграх часто столько багов? Причём проблема именно не в движке (скажем Unreal engine) а именно в игре (другие игры на том же движке работают нормально!). А потому что квалификация разработчиков 3D движков и разработчиков игр отличается в десятки раз. От чего становится не по себе, учитывая что разработчики движков (или библиотек) свою работу ДЕЛАЮТ, художники, дизайнеры свою работу ДЕЛАЮТ, а обезьянки, на плечах которых остаётся решение уже самых простых задач ДЕЛАЮТ Х**НЮ и ничего больше.
Проблема бизнеса в том, что он меняется. Сегодня заказчику нужно так, а завтра - иначе. И вообще иначе было нужно уже вчера, просто он забыл вам об этом сказать. Поэтому ООП и скриптовые языки - чтобы было проще ориентироваться и менять на лету. На древнем С же такое писать (и особенно поддерживать) - просто умрешь. То есть производительность не важна - важно время на изменение и обновление.
Автор забыл про самый главный признак плохого кода: код написан на императивном ЯП.
Как думаешь в публикации твоего камента хоть строка декларативного кода была задействована?
@@AlexeyZlobin Представь себе колхозника, едущего на чадящем как Адмирал Кузнецов тракторе. Лицо колхозника перепачкано сажей, руки в машинном масле, колхозник переодически останавливает трактор, чтобы слить скисшую воду из радиатора или долить масла в картер. К трактору прицеплена телега с картошкой, колхозник едет на рынок.
И вот уже на рынке колхозник замечает выходящего из новенькой Теслы бизнесмена. Щербатая физиономия колхозника расплывается в улыбке, и он так добродушно спрашивает: "как думаешь, хоть одна картофелина, из тех что ты собираешься купить, была доставлена сюда посредством электромобиля?"
Ответ на твой вопрос прост - я понятия не имею, на чем CZcams возит картошку, какое у них качество кода, и главное, сколько времени и усилий они потратили на его создание и сопровождение. Ты тоже это вряд ли знаешь. Поэтому обсуждать тут что-то бессмысленно.
@@stanislavchernichkin1954 Наверно из моего вопроса это не достаточно очевидно, но я спрашивал про оценку а не точную статистику. Небольшая подсказка, CZcams - ничтожная часть участвующей кодовой базы :)
@@AlexeyZlobin И в чем смысл подобных оценок? То, что большая часть кодобазы - беспросветное говно, знает любой колхозник. Иначе не существовало бы такого количества книг про плохой и хороший код, а слово "Legacy" нe переводилось бы как "любой код написанный не мной не ранее прошлой недели".
@@stanislavchernichkin1954 В том чтобы соотнести ваши фанбой-кричалки с пользой и работоспсобностью практических решений.
Очевидные вещи. Я не понимаю, какую вы пытаетесь использовать терминологию. Что значит интерфейс класса? Есть интерфейс и класс который наследует этот интерфейс. Функции. Может быть методы? Если мы о ООП говорим. Куча воды течёт из вашего рта, попробуйте сами вычленить полезную инфу.
В том то и дело, что не только про ООП, я об этом в начале видео сказал. Интерфейс класса - публичные методы.
Такое чувство, что спонсоры дают настойчивые советы по тому как делать видосы. В частности они стали какими-то больно весёлыми, мне нравится угрюмость старых роликов. Надеюсь что это не так, а то чувствуется скатится канал, а мы его так любим...
Максим, я переехал из темного подвала в дождливом Гамбурге в светлый дом в солнечном Мюнхене. Я понимаю, что некоторым нравился угрюмый канал, но это лишь отражение меня, а не спонсоров.
Страйк!!!😂
Как можно кодить на такой клавиатурке? Я со своей килограммовой тихо курю в сторонке
Да без кода перед глазами, ты хоть 100 раз говори, большинство не поймет, особенно если ты рассчитываешь на свою аудиторию, где таких как я сеньоров не каждый второй. Мне все понятно что ты говоришь, но на словах понимают только Стронг Мидл +. Тем более у тебя мак, там экран записать одинклик из коробки.
P.s. еще одна реклама гавнокурсов, вы серьезно?
Дяденька написал очевидности и заработал денюжку. Спасибо за обзор сего труда. Сразу предупрежу - не программист. Но для начинающих я всё же посоветовал бы начинать с множества простых модулей, или классов, а затем уже переходить к усложнению абстракции, строго обязательно на стадии создания алгоритма решения задачи. Даже я могу писать такие книжки. Просьба матом не ругаться.
Спасибо