Писать код нужно так, будто человек который будет поддерживать твой код знает где ты живешь 😂
@alexandrkruglyak5 жыл бұрын
Забыл еще упомянуть, что он маньяк)))
@cristalmen91045 жыл бұрын
вроде смех смехом, но рабочее правило... лучше развивать ярую самокритику, тоже рабочая фишка, честно задавать себе вопрос - пропустил бы ты сам такой код или нет... и как ни странно в 80% всегда что то находишь...
@t0digital5 жыл бұрын
Если не бить код на функции, классы, модули - прощай хорошие автотесты (а значит прощай долгосрочная поддержка), ухудшается переиспользуемость кода, ухудшается читабельность кода (если модули и методы названы правильно, что в общем тоже искусство своего рода, но все же) и тд. Да, мысли к размышлению интересные в книге, но больно много спорных вещей
@dimageorgiev57985 жыл бұрын
Спасибо Дима ! Отлично как всегда ! МОНИТОР ХОРОШ ;)
@loam5 жыл бұрын
надо было добавить в конце "а может подаришь, а..."
@MegaMrTan4 жыл бұрын
Благодарю) Ваша информация спасает меня от лени, добавляет мотивации, освежает мои знания; слушаю вас в перерывах между обучением программирования)
@obiwanus5 жыл бұрын
Думал, мини-гантеля лежит на столе, присмотрелся - наушники :) Даешь больше физических упражнений!
@Лучшеникакогознаниячемникакое5 жыл бұрын
Зачем использовать слишком общие названия переменных x, y - когда можно вместо них задействовать i, j!
@eugenenovikov6714 жыл бұрын
i, j уже задействованы в циклах, поэтому мы используем a, b
@kirillskomarovskiy24904 жыл бұрын
Чтобы было понятнее используйте «_», «__» 😂
@Torbjorn-ph7rt3 жыл бұрын
Ну ладно можно в цикле использовать key и val или просто k и v
@redeagle74585 жыл бұрын
Действительно, некоторые заявления автора довольно смелые и слегка субъективные. Есть конечно и некоторое зерно истины. Но в целом, главная мысль в том, чтобы не просто бездумно писать интерфейсы, потокая всеобщим стандартам говнокода, а продумывать каждое своё действие. Дьявол в деталях. С таким подходом и рождаются топовые спецы. Это программирование головного мозга.)
@GarifullinMichael5 жыл бұрын
Для тех кто не осилил SOLID
@diceline16775 жыл бұрын
Я вообще считаю, что хороший кодер тот, кто связывает мостом жизнь и программирование. Он пишет программы рационально и сам живет также, пришел к пониманию золотой зередины, что нельзя жить белым или черным. Суть кода подкреплена его идеологией. Программирование, это его способ реализовать свои интеллектуальные потребности, а сам он занимается многим, имеет очень обширный кругозор. Каждый поход в магазин выглядит, как очень оптимизированный алгоритм, никаких лишних движений, но в то же время понимает, что эстетика имеет такую же ценность, что и логика с ее минималистичностью, и поэтому он не берет огаленными руками картошку, чтобы упаковать ее и взвесить, а орудует пакетом, как перчаткой. Не пачкает себя, но и не боится запачкаться. Баланс всего...
@АлександрКириллов-з4ч5 жыл бұрын
@@GarifullinMichael holly Bob Martin church
@andrewvsk23685 жыл бұрын
Вся беда современных разработчиков что все разучились думать алгоритмически. Сказывается отсутствие практики на 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 движков и разработчиков игр отличается в десятки раз. От чего становится не по себе, учитывая что разработчики движков (или библиотек) свою работу ДЕЛАЮТ, художники, дизайнеры свою работу ДЕЛАЮТ, а обезьянки, на плечах которых остаётся решение уже самых простых задач ДЕЛАЮТ Х**НЮ и ничего больше.
@Лучшеникакогознаниячемникакое3 жыл бұрын
Проблема бизнеса в том, что он меняется. Сегодня заказчику нужно так, а завтра - иначе. И вообще иначе было нужно уже вчера, просто он забыл вам об этом сказать. Поэтому ООП и скриптовые языки - чтобы было проще ориентироваться и менять на лету. На древнем С же такое писать (и особенно поддерживать) - просто умрешь. То есть производительность не важна - важно время на изменение и обновление.
@nikshadow925 жыл бұрын
Отличное видео. 5 пункт как раз такой противоречивый: в случае если используется 3d-party library бывает довольно неплохо закрыться фасадом. Во внутреннем коде , конечно это оверхед. По большей части копирует "совершенный код", но также есть несколько очень интересных новых идей. А так общая мысль довольно очевидна: пишешь модуль - думай о тех, кто будет им пользоваться.
@loam5 жыл бұрын
3:57 - "использование модуля можно избежать, если просто напрямую будете использовать те конструкции, которые в нем спрятаны" - есть такой момент, что эти конструкции могут использоваться повторно слишком много где и проще сделать один класс (буду выражаться в терминах ООП). Другое дело, конечно, продумать этот класс так, чтобы интерфейс был попроще и вся сложность внутри класса была спрятана, это да. Ну и НАВЕРНОЕ (подчеркну, что в дальнейших своих рассуждениях не совсем уверен) если совсем никак нельзя сделать интерфейс простым, а эта логика, заложенная в этом классе слишком много где используется, то пусть все равно будет этот класс с худо-бедным интерфейсом, чем сто раз писать одно и то же. И вообще, программирование это такое дело, всегда найдется сто различных "но" и частных случаев, и везде можно спорить. Просто книга еще раз напоминает о том, что нельзя ничего с полной уверенностью утверждать, нужно всегда включать мозги и обдумывать все, и нельзя вдаваться в крайности.
@spoonjeee47855 жыл бұрын
лофтскул на лбу еще бы написал, точно бы перешел по ссылке))
@eugenenovikov6714 жыл бұрын
Флагом Pass-through набит самый тяжёлый объект во Вселенной - node_modules. Однажды я решил покопаться там, чтобы выяснить нафига там тысячи папок. Оказалось, что в одной папке находится файл, который импортирует функцию из другой папки и следующей строкой делает её экспорт. ВСЁ!! больше в папке ничего не было. Если не ошибаюсь, это была библиотека из пяти папок что-то типа ansi color. Бессмысленно и бесполезно.
@dimaotovskiy4 жыл бұрын
Спасибо, надо будет заиметь эту книгу себе )
@dmitriygray66165 жыл бұрын
как же это все вовремя и к месту, я пытался партитилить класс по разным темам, но тем оказалось много
@s_bandera5 жыл бұрын
Thank you so much for this very useful information!
@mihailmatkovskij93505 жыл бұрын
Вся реализация кода зависит от поставленной задачи и только от неё! Поэтому, и сложность модуля зависит от поставленной задачи, а не от того глубокая программа или поверхностная. Те участки кода, которые вызываются многократно имеет смысл сделать в виде отдельных подпрограмм. Самое главное, уметь писать грамотный код. Но для этого нужен талант и понимание концепции программирования. Если хотим, чтобы программа занимала не слишком много процессорного времени либо места в ОЗУ или точнее в этом есть необходимость, то существует оптимизация. Но опять же, грамотный код часто является одновременно и оптимизированным. В общем, думайте прежде всего над тем, что вы пишите, а всякую глубину модулей и прочую ахинею пошлите куда подальше.
@МаксимАнциферов-и6с5 жыл бұрын
Мне кажется, что большинство проблем с модулями возникают из-за преждевременной оптимизации или преждевременного разделения
@loam5 жыл бұрын
да, вот столкнешься с одной и той же задачей пару раз, задумаешься и начнешь лепить модуль - это лучше, чем сразу. Я вообще начинаю просто в одном методе сначала тупо расписывать всю логику. Потом рефакторинг.
@МаксимАнциферов-и6с5 жыл бұрын
@@loam на счёт опыта согласен, и на счёт одного большого файла тоже :)
@eugenenovikov6714 жыл бұрын
@@loam Тимур, сначала продумывается архитектура, потом пилится код. Очень хорошо продумывается архитектура, чтобы говнокодеры не рефакторили по сто раз.
@loam4 жыл бұрын
@@eugenenovikov671 Зависит от задачи. Архитектура продумываю сначала, если это достаточно объемная задача.
@eugenenovikov6714 жыл бұрын
@@loam вот я сижу и разгребаю эти объёмные задачи на 1000 строк каждый метод, которые судя по коды были натыками с форумов по кускам за ночь лишь бы работало, и это энтерпрайз гос подрядчика в Москве, что творится в регионах и представить страшно. Архитектура должна быть ВЕЗДЕ И ВСЕГДА.
@владимирсенцов-р1ю3 жыл бұрын
Про комментарии. Они могут быть полезны. Но при имении кода их никто не поддерживает. И они становится басполезными. Как вариант это некоторый контракт на api. Например поведение при null. Или допустимые величины. Например функция парсящая дату. Монно указать допустимый формат входящий строки. Но потом все равно никто эту хрень не поддерживает.
@abdul-malikibragimov9562 Жыл бұрын
Ничего не понял, но очень интересно))
@ivankir97165 жыл бұрын
Покажите мне человека, который в разные модули засовывает чтение и запись хD
@МаксимХвостов-м1й5 жыл бұрын
// Replaces with spaces // the braces in cases // where braces in places // cause stasis. $str = str_replace(array("\{", "\}"), " ", $str);
@princekazakh5 жыл бұрын
not unix way
@wayydev5 жыл бұрын
??
@ВячеславКужилко5 жыл бұрын
Спасибо Дмитрий!)
@sergzach5 жыл бұрын
Дмитрий, ну а Вы-то с первым замечанием про поверхностные модули согласны? С другой стороны ведь программист может до конца не осознавать концепции своего софта, иногда задачи приходят сверху. И такие глубокие модули могут требовать большего времени на изменение. Есть вероятность, что первая их версия будет делать не то, если задача достаточно объемная.
@ivansidorov55 жыл бұрын
Проблемы в коде зависят от бизнеса, в реальном мире все не так как ты говоришь.... В реальном мире бизнес давит временем. Идеальный код только на пет проектах)
@МихаилНестеренко-ю3н5 жыл бұрын
На поддержку хорошего кода тратится в десятки раз меньше времени, чем на поддержку плохого. Поэтому хороший код оправдан, даже если его писать в несколько раз дольше.
@ivansidorov55 жыл бұрын
@@МихаилНестеренко-ю3н Я всегда это слышу на конференциях, митапах, курсах, но когда прихожу работать в крупную компанию, банки, продуктовые итд, везде творится пиздец, потому что "Мы не успеваем, потом сделаем"
@МихаилНестеренко-ю3н5 жыл бұрын
@@ivansidorov5, не знаю, у меня всё спокойно, пишу код как считаю нужным. Даже наоборот начальство просит модульные тесты, и другие подстраховки.
@МихаилНестеренко-ю3н5 жыл бұрын
И со сроками проблем нет.
@ivansidorov55 жыл бұрын
@@МихаилНестеренко-ю3н Значит проект маленький. у меня проекты были все крупные, котоырми уже пользуются много людей и там нужно решить задачу еще вчера. либо в тубя проект который только зарождается, еще про него никто не знает и все пофиш впринципе на сроки)
@alicenNorwood3 жыл бұрын
Мне кажется я где-то это видео уже видел :)
@tolik85 жыл бұрын
Отличное видео, а если бы ещё с примерами то вообще бы цены не было, но все равно лайк
@aliscander925 жыл бұрын
Советы прям совсем субъективные. У меня на работе есть два отличных backend программиста. Профессионалы высокого класса, Мне до них в программировании ещё очень далеко, т.к. мои программы-по сравнению с их это такие инвалиды с костылями. Пишут вместе здоровенную программу с кучей подключаемых библиотек по математической обработке сигналов. Так вот даже они иной раз друг с другом спорят о том как должен выглядеть код. Какую функцию написать, какой класс ввести. Даже они не имеют единого мнения. А тут понимаете советы о том как построить структуру программы.
@Мария-р3с4е5 жыл бұрын
Ну надо же как-то учиться, а собственное мнение и взгляд на все появляются с опытом
@НикитаКальнов-л8ш3 жыл бұрын
Про 11 флаг: можно было бы использовать row и column) Покороче и понятнее вроде
@aysommer5 жыл бұрын
Лайк по константе. Спасибо =)
@alexxx44344 жыл бұрын
Графомания по большому счету, обсасывающая очевидные истины.
@aleksandrmikhailov32555 жыл бұрын
Пересказ очевидных вещей плюс реклама лофтскул
@blue_lobster_5 жыл бұрын
Наконец-то :)
@pavel79305 жыл бұрын
А текстовый редактор научать как сделать ?
@sasichkamega5 жыл бұрын
2:58 зато тестировать проще, а это лучше. Написал тесты и следить не придется.
@sasichkamega5 жыл бұрын
@@MrCortc, я тоже таких людей до усрачки боюсь, поэтому я проповедую написать вначале код, а потом тесты.
@МаксимВеснин-и6э5 жыл бұрын
@@sasichkamega А как же TDD? Судя по тенденциям, такой подход очень заходит
@sasichkamega5 жыл бұрын
@@МаксимВеснин-и6э, я не понимаю что ты мне пытаешься сказать. Что tdd? Ну tdd, знаю такое слово. Я тебя не понимаю.
@nickvirus94635 жыл бұрын
с 13 можно поспорить, ведь можна аналитически определить
@loam5 жыл бұрын
Over exposure - я бы перевел, как "чрезмерное выставление напоказ", "чрезмерное обнажение", в контексте о внутренностях класса.
@SeniorSoftwareVlogger5 жыл бұрын
Я думал назвать "интерфейсный эксгибиционизм", но потом передумал :)
@loam5 жыл бұрын
@@SeniorSoftwareVlogger тоже не плохо. P. S. Подписался ;) Заметил, что это не впервые, когда смотрю ваши видео и при этом почему-т овсе еще не подписан :)
@demin-e5 жыл бұрын
Будут ещё видео про хобби?
@mqxim6305 жыл бұрын
Расскажи про паттерны проектирования
@ИванИванов-ь2й5х5 жыл бұрын
Очевидные вещи. Я не понимаю, какую вы пытаетесь использовать терминологию. Что значит интерфейс класса? Есть интерфейс и класс который наследует этот интерфейс. Функции. Может быть методы? Если мы о ООП говорим. Куча воды течёт из вашего рта, попробуйте сами вычленить полезную инфу.
@SeniorSoftwareVlogger5 жыл бұрын
В том то и дело, что не только про ООП, я об этом в начале видео сказал. Интерфейс класса - публичные методы.
@eugzubv43365 жыл бұрын
Дмитрий, а что за книжечка у Вас в руках? Вы конспектируете прочитанное?
@SeniorSoftwareVlogger5 жыл бұрын
Готовил конспект для видео
@vyvaida5 жыл бұрын
Спасибо
@funteek33804 жыл бұрын
Пересказ книжек от старшого или Место красит человека
@АлександрКириллов-з4ч5 жыл бұрын
Дмитрий, спасибо. Очень интересно. Правда вот тут - kzbin.info/www/bejne/iYuvlaCbZd-pjJY вы говорите о "протекании информации", а это случайно не о Leaky abstraction - www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/, просто очень похож посыл
@alexeymezenin5 жыл бұрын
Книга в некоторых вещах противоречит Clean Code. Автор Clean Code - ну очень известный человек, автор многих сильных книг, реальный разработчик, описанные им практики проверены временем. Автор этой книги - профессор (т.е. тотальный теоретик), написавший всего одну книгу, причем совсем недавно. У меня все.
@SeniorSoftwareVlogger5 жыл бұрын
Когда то был момент когда дядя боб тоже написал свою первую книгу и был автором одной книги. Книга противоречивая, как я и сказал, но при этом хороший материал для мыслей.
@alexanderschneider35075 жыл бұрын
Тоже читал Clean Code и практически все моменты в книге казались логичными. По пересказу Дмитрия показалось что есть моменты вступающие в противоречие с Clean Code, который насколько я понимаю является чуть ли не стандартом в разработке.
@djcvhw5 жыл бұрын
На сколько удобно использовать трекпад вместо мыши?
@SeniorSoftwareVlogger5 жыл бұрын
Настолько, что у меня нет ни одной мыши в доме
@djcvhw5 жыл бұрын
@@SeniorSoftwareVlogger Почти 2 года использую макбук и никак не могу перейти на трекпад. Основная сложность - это выделение больших участков текста. Одной рукой это возможно делать?
@SeniorSoftwareVlogger5 жыл бұрын
У меня 3-х пальцевое движение для этого. Просто веду не одним, а 3 пальцами и нет проблем.
@AlienGodDog5 жыл бұрын
вЕб разработчик....
@darkfrei25 жыл бұрын
Вьеб!
@АлександрИванов-п9ы8ж5 жыл бұрын
Есть ещё одна причина не способности правильно написать комментарий или документацию к модулю, а так же подобрать правильно имя - это низкий уровень английского языка)
@sergey53689 Жыл бұрын
С точки зрения программирования, если рассматривать все более глубоко все это полная чушь и дрочетта, только голову себе забивать этими книжками
@bad_russian5 жыл бұрын
Такое чувство, что спонсоры дают настойчивые советы по тому как делать видосы. В частности они стали какими-то больно весёлыми, мне нравится угрюмость старых роликов. Надеюсь что это не так, а то чувствуется скатится канал, а мы его так любим...
@SeniorSoftwareVlogger5 жыл бұрын
Максим, я переехал из темного подвала в дождливом Гамбурге в светлый дом в солнечном Мюнхене. Я понимаю, что некоторым нравился угрюмый канал, но это лишь отражение меня, а не спонсоров.
@stanislavchernichkin19545 жыл бұрын
Автор забыл про самый главный признак плохого кода: код написан на императивном ЯП.
@AlexeyZlobin5 жыл бұрын
Как думаешь в публикации твоего камента хоть строка декларативного кода была задействована?
@stanislavchernichkin19545 жыл бұрын
@@AlexeyZlobin Представь себе колхозника, едущего на чадящем как Адмирал Кузнецов тракторе. Лицо колхозника перепачкано сажей, руки в машинном масле, колхозник переодически останавливает трактор, чтобы слить скисшую воду из радиатора или долить масла в картер. К трактору прицеплена телега с картошкой, колхозник едет на рынок. И вот уже на рынке колхозник замечает выходящего из новенькой Теслы бизнесмена. Щербатая физиономия колхозника расплывается в улыбке, и он так добродушно спрашивает: "как думаешь, хоть одна картофелина, из тех что ты собираешься купить, была доставлена сюда посредством электромобиля?" Ответ на твой вопрос прост - я понятия не имею, на чем KZbin возит картошку, какое у них качество кода, и главное, сколько времени и усилий они потратили на его создание и сопровождение. Ты тоже это вряд ли знаешь. Поэтому обсуждать тут что-то бессмысленно.
@AlexeyZlobin5 жыл бұрын
@@stanislavchernichkin1954 Наверно из моего вопроса это не достаточно очевидно, но я спрашивал про оценку а не точную статистику. Небольшая подсказка, KZbin - ничтожная часть участвующей кодовой базы :)
@stanislavchernichkin19545 жыл бұрын
@@AlexeyZlobin И в чем смысл подобных оценок? То, что большая часть кодобазы - беспросветное говно, знает любой колхозник. Иначе не существовало бы такого количества книг про плохой и хороший код, а слово "Legacy" нe переводилось бы как "любой код написанный не мной не ранее прошлой недели".
@AlexeyZlobin5 жыл бұрын
@@stanislavchernichkin1954 В том чтобы соотнести ваши фанбой-кричалки с пользой и работоспсобностью практических решений.
@dalvincumter94735 жыл бұрын
Мне нравится
@Ver-L5 жыл бұрын
Что за надпись на руке?
@SeniorSoftwareVlogger5 жыл бұрын
My choice
@НикитаПавлов-э8г2 жыл бұрын
Кто с 2022
@skeep7475 жыл бұрын
Кто это на маленьких портретах под монитором?
@SeniorSoftwareVlogger5 жыл бұрын
Последняя ссылка в описании
@SerhiiYenin5 жыл бұрын
Пиконка это, что-то вроде иконки для атеистов с изображением выдающихся научных деятелей :)
@konstantinkudelko75455 жыл бұрын
@@SerhiiYenin Интересно, что некоторые из них были креоционистами)
@SerhiiYenin5 жыл бұрын
@@konstantinkudelko7545 можно простить им их невежество, все таки давно это было...;)
@Sorrymelame5 жыл бұрын
Да без кода перед глазами, ты хоть 100 раз говори, большинство не поймет, особенно если ты рассчитываешь на свою аудиторию, где таких как я сеньоров не каждый второй. Мне все понятно что ты говоришь, но на словах понимают только Стронг Мидл +. Тем более у тебя мак, там экран записать одинклик из коробки. P.s. еще одна реклама гавнокурсов, вы серьезно?
@Ver-L5 жыл бұрын
Как можно кодить на такой клавиатурке? Я со своей килограммовой тихо курю в сторонке
@ДмиЕрем5 жыл бұрын
Дяденька написал очевидности и заработал денюжку. Спасибо за обзор сего труда. Сразу предупрежу - не программист. Но для начинающих я всё же посоветовал бы начинать с множества простых модулей, или классов, а затем уже переходить к усложнению абстракции, строго обязательно на стадии создания алгоритма решения задачи. Даже я могу писать такие книжки. Просьба матом не ругаться.