Чистый код - не значит правильный | Clean code, паттерны, лучшие практики | Podlodka Podcast

[@ДмитрийРубанов-и2ц]

Когда я вырасту, то хочу быть таким же крутым как Кирилл, только мне уже 35 :(

[@yet300]

Мне 21 и тоже так думаю😅

[@garikdjan6266]

надо было начинать учить SOLID в 11 лет

[@phyllobolus]

Когда вырастет борода.

[@alexjegor]

Никогда не поздно

[@vladimirlos5432]

@@alexjegor Не бывает "поздно". Бывает "уже не надо".

[@ArcadeMdns]

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

[@mokevnin]

А выпуск про SOLID я обязательно бахну! :)

[@oeaoo]

На определенном этапе осознаешь что чистота кода - плохая самоцель. Достаточно чистый код - вот это да. А понимать ту самую "достаточность" - вот где сила.

[@vladimirlos5432]

Вы - не правы. Это - НЕ перфекционизм. Просто - нормальные природные требования: код должен быть чистым и красивым.

[@omgwtf0]

@@vladimirlos5432 пришлите ссылку на Ваш код, мы посмотрим что такое чистый и красивый ))

[@FigisBadralov]

Я ни на одном проекте не видел документ Стандарты Разработки. В нем приводится глоссарий, как мы бустрапим новые проекты, как мы именуем proto, как бранчуемся, какие среды, как апрувим комиты. И все в том же духе. Документ без воды, страниц на 20-30. Много коммуникационных проблем будет решено!!!

[@thechase-race]

До середины дослушал. Под каждым словом подпишусь :)) Про нейминг - в точку! Прикольно работать там, где такие люди, как Кирилл имеют вес. Про fsm - согласен на 1000%, подходит от геймдева до разруливания волокиты с документами :)

[@andrewskripko2311]

Моё уважение этому господину. Слушая как он объясняет сложные вещи простыми словами - понимаешь что он все понимает

[@garikdjan6266]

юзал FSM в бизнес логике до того, как это стало мейнстримом :) я выходец из embedded programming и любую систему/процесс воспринимаю как бесконечный цикл с переключением состояний ) в совеременных реалиях это можно назвать domain events

[@ChannelCheesecake]

В ФП Continuations и Continuation-Passing Style - обобщение автоматного программирования - существует где-то с середины прошлого века

[@3ggr]

Выпуск огонь 🔥

[@vladimirlos5432]

Охренеть! 2024 год. А человек вынужден объяснять, что, по сути, в программинге НИЧЕГО, кроме конечных автоматов, не существует! Я - в шоке.

[@sau9703]

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

[@TheRedbeardster]

Кирюха изобретает монады, пайплайны, тройки Хоара и спеки на функции :) Кирюха молодец! :)

[@spacerecluse]

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

[@v1aadev]

Так. Прекрасные Катя и Женя, легендарный Кирилл, горячая тема, но лайк отгружен до просмотра, даже если в нём будет нещадно подбито моё личное объективно верное ощущение чистого кода!

[@kselnaag2482]

Чистый и никому не нужный - идеальное текущее описание меня =D

[@Andruxxxaify]

отличный подкаст. один из вопросов на одном из собесов - "какой из паттернов реализует одну из букв SOLID - например O". ну и в целом главные требования - знание абсолютное с применением в коде и код ревью SOLID DRY KISS YAGNI и всех паттернов. я в целом понял, что что-то там не то...

[@34shadows]

А что не так? Не нужно знать и уметь использовать принципы SOLID? Нужно, при том что обычно мы их используем, не зная об этом

[@СенчуринНиколай]

Мокевнин это всегда топ, спасибэйро!!!

[@jhartum8505]

Про конечные автоматы интересный разговор. Кажется что похоже на Workflow в Domain Driven Design

[@Ru.Ubububu]

Код Мартина можно посмотреть на гитхабе, он об этом пишет в своих же книгах. Например, Fitnesse, написанный на Java

[@GintsPolis]

Мнго раз было сказaно, без реального кода трудно. Так надо с реальным кодом тогда :)

[@nikitarusin2489]

Чтобы разблокировать персонажа Кирилл Макевнин нужно дослушать до 25й минуты

[@user-lc4vb9dj8v]

> Подкаст про чистый код Позвали чела который не работал ни в одной серьёзной технической компании.

[@enable4]

А каковы критерии серьёзности компании?

[@АлексейФроловский-ь8н]

Не увидел в ссылках про доклад, о котором Кирилл говорил в конце. Так вот, доклад: «Снесите это немедленно» - Аксенов

[@ponypower9144]

для того что бы понять конечный автомат и их пользу достаточно просто написать хотя бы одну игру. По сути все и всегда имеет состояния. Вместо того что бы проверять что то мы можем просто не делать то что объект не может делать в том или ином состоянии. Но у нас появляется проблема в виде больших матриц состояний когда у нас большое количество объектов зависят от состояний других объектов. А когда вы поймете что по сути можно стоить целые деревья с под деревьями которые крутятся и сами регулируются вы поймете что вот у вас и модульность подъехала и вообще код стал выглядеть очень просто. Правда почему то забывают о инфраструктурных издержках потому что для этого подхода нужно много всего сделать.

[@vladimirlos5432]

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

[@Dmitrijserg]

Шикарный видос, спасибо большое, Кирилл - мощь, конечно

[@grulex411]

Забыл Эванса посоветовать, хотя в процессе ссылался) (Не является инвестиционной рекомендацией)

[@johnsandwich6726]

ощущение поле выпуска, что все писали и пишут неправильно, но только Кирилл знает как надо ))) Паттерны можно не учить, аббревиатуры неправильные, вообще все лучшие практики прошлых лет не то - Кирилл наш кандидат, приходите к нему, он научит 🙂🙂🙂 P.S. на телегу Кирилла подписался 🙂

[@spacerecluse]

а я отписался 😀

[@johnsandwich6726]

@@spacerecluseвозможно и так поступлю ) пока наблюдаю

[@ЭльдарМ-в2у]

ифы vs конечные автотматы - "было бы все немножко по-другому". И какие преимущества были бы у автоматов?

[@АнтонТрофимов]

Кирилл как всегда крут!) Послушал с кайфом!

[@ivankartashev7998]

Отличный получился выпуск, спасибо🙏

[@furryablack29]

Мда, сейчас пилю фичу в грязном коде. Да, весь код грязный, согласен. Есть грязный как асфальт после ветра и дождя. Есть грязный как выгребная яма. Грязь грязи рознь. Я преисполнился.

[@hurricane-rus]

Использование статусов для управления состоянием объектов - отличный подход. Но это у меня точно не связывается с конечным автоматом, который для меня какая-то абстрактная научная штука)

[@Egorka]

Кирилл потихоньку делает из себя кумира)

[@vladimirlos5432]

Хммм... А, по-моему, ведь ведущий (который слева), судя по его фразам о "натягивании" кода на КА, на самом деле не понимает "про конечные автоматы"... Он несколько раз повторил о состоянии всей системы. А это - уже первейший показатель непонимания данной темы. Поправьте, если я не прав.

[@Никита-ь6с9д]

спасибо большое за выпуск, было интересно!

[@TheLevius]

Хороший выпуск, классный гость

[@СэрШпинат]

primeagen с bob martin хорошее интервью да.

[@baron270]

Это же Иван Ургант от разработки )

[@grok_iOS]

Ссылка на тг канал Кирилла будет?

[@watcher750]

Организованное программирование

[@PodlodkaShow]

Добавили в описание к видео!

[@antonikucherov]

Single Responsibility- хрень собачья. Но конечные автоматы - наше всё. Ничего не смущает? Нет ли между этими двумя концепциями связи?… 🤔 🙃

[@zhandosissayev9798]

Да нет этот принцип механикой языка не реализуется и побуждает писать в искажающем стиле.

[@nikolaypopov5830]

Clean codeR - тоже книга Мартина

[@egormerkushev]

Максимально спорный выпуск от «просветленных» программистов

[@dmitriy4415]

Хороший гость. Зовите ещё.

[@LelikPtz]

Очень странное впечатление. Правила из чистого кода вредные, солид устарел, паттерны не нужны, юнит тесты переоценены. Яркие заявления, а потом примеры которые доказывают что все таки и правила «чистого кода» соблюдать надо, и примеры реализаций паттернов и где они применяются, и как большой класс удобно разбивать по солиду, и важная бизнес логика в юнит тестах. Вот так закопали. А новички наслушаются лозунгов и разгребаем потом год обджекты в 3к строк с переменными в одну букву без тестов.

[@AlexP-fg3ci]

Я чаще вижу что вместо душнилова на старте/собесе про солид и клин-код лучше работает сложно формулируемый "коммон-сенс", "чувство прекрасного" и обучение в формате подмастерья. Т.е. приходит ждун в команду и его потихоньку за полгода подтягивают в самостоятельного разраба с помощью хардкорного ревью и синков, иногда вставляя базворды типа "паттерн Х", "читаемость", "поддерживаемость", etc для придания своей речи вида объективности Хоть может показаться что это про передачу субъективного видения, но почему то переходя с одного места на другое вижу что все серьезные разрабы приходят к похожим подходам. Видимо хорошие идеи распространяются в индустрии крос-опылением)

[@untraff]

"Это кринж, меня это фреймит. Хотя вопросы валидные. Парень с бородой рефлексировал. Но у него не мапится." Ставь лайк если не понял что я сейчас сказал, и что говорят эти прекрасные люди. Ребятки что с вашим русским языком? Вас слушать ужасно. Кириллу уважение за информацию.

[@untraff]

Про "шиперить фичи" прям отдельно добавить решил

[@OpenSR88]

Да назовите это состоянием и все, у меня код игровой на ecs подразумевает набор состояний, как для игрока в целом так и для элементов общего состояния, и никто такого не боиться, типа норм.

[@aelaau]

Состояние - другой термин, гораздо более широкий

[@OpenSR88]

@@aelaau холивар он :) сколько не работал в разных компаниях, ни разу не видел единого голосария, куча довольно обоснованных мнений.

[@DmitryRandom]

Вся наша жизнь .... игра, тьфу конечный автомат конечно же

[@metasta3a]

Читаю книгу гроккаем алгоритмы, написана индусом, противоречит себе через каждые 2 страницы, думаю, это его фишка, не советую😂

[@celestian-verse]

22:30

[@denisf3100]

Вы просто не сталкивались с настоящим говнокодом

[@ruslanm.1120]

Где код? Развели тут болтанку, понимаешь.

[@РоманОдышев-ш8ю]

Блин, ребят, ну капец слабо, даже грустно как то... Вы позовите меня поговорить за чистый код и SOLID, и я объясню что и как И по каким причинам люди это не понимают или не умеют пользоваться, ну правда грустно что не транслируется реальная суть вещей....

[@СэрШпинат]

еще один сектант

[@artishoo]

Мутный гость какой-то

[@unitydude]

Это вначале. Затем его нормально видно :D

[@artishoo]

@@unitydude казалось что его лицо скрывают, как в репортажей про жертв преступников))

[@unitydude]

@@artishoo интересный эффект получился с рассветом :)

[@sdev9881]

"Чистый код" - не нужен. Но у гостя так сложно формулируются мысли вначале, что очень сложно понять о чем он хочет сказать. Возможно, "чистый код" хорошо помогает понимать чей-то код. Также как и "чистая и структурированная речь"

[@neyroniusYT]

Человек в 5 утра встал и бодро говорит про чистый код - уже подвиг

[@ancevtd2d247]

Кайф

[@iGotton]

+

[@TheTmntmike]

Чистый код - чисто инфоциганаская тема. Эта книга скорее мотивационная какая-то, нежели что-то применимое в реальной жизни.

[@Paul-kr8dq]

"выведенные типы в пуллреквесте не видны" - поздравляю! Твои разрабы тупо профанируют кодревью, делая его в броузере. В подавляющем большинстве случаев это означает, что они либо недостаточно квалифицированы для этого, если не могут побилдить и, как минимум, прогнать тесты локально, либо тупо забили и делают это просто для галочки. Потратьте день, раздайте слонов, настройте тулчейн, и реальная эффективность кодревью возрастёт на порядок 🤷🏻‍♂️

[@vifvrTtb0vmFtbyrM_Q]

а зачем в таких языках как java в пулл реквесте смотреть на тип переменной ? и что плохого в var ? код тупо не скомпилируется. Я к тому что вряд-ли код пишут сидя в блокноте.

[@Paul-kr8dq]

@@vifvrTtb0vmFtbyrM_Q Во-первых, насколько я понял из контекста, они пишут не только на Java, но и на всяких TS, буквально приглашающих джуна накосячить, и замести это непотребство под коврик. Во-вторых, тут дело не столько в выведенных типах, сколько в том, что ревью в броузере, это лютейшее зло, превращающее прекрасную идею в свою полную противоположность. Если у ревьювера нет возможности побилдить код, полазить по иерархиям с помощью ctrl-click, запустить локально и т.д., то всё, что он реально способен отревьювить, это, по большому счёту, соответствие "неписаным" стайлгайдам и наиболее детские косяки, с чем намного эффективнее справилась бы и обезьяна, в смысле, статический анализатор с копилотом. А вот весь ворох менее тривиальных моментов, отличающих реально качественный код от унылого г-на, при таком "ревью", по определению, пролетает мимо кассы... всякие "странные" ворнинги в логах, косяки в зависимостях, тесты, которые ничего не тестируют, грязные хаки в конфигах, поломанные деплои и прочая дичь. Ревью в броузере, это идеальный метод профанировать основную цель затеи - чтоб ревьювер становился "совладельцем" кода, а не просто челом, поставившим галочку. Ну, или же он должен быть буквально каким-то сверхчеловеком и тратиь на каждое ревью по несколько дней (непонятно, зачем)... чего в реальности, разумеется, никогда не происходит. В результате - сплошь и рядом возникают ситуации, когда код много раз ревьювила хренова туча синьёров, но стоит в нём чему-то сломаться, а автору заболеть, и команда тупо боится его трогать, чтоб не сделать ещё хуже. И когда кому-то таки приходится заглянуть в этот код по-настоящему, перед ним на ровном месте может разверзнуться аЦкая бездна технического долга... а в броузере ведь всё было так красиво и правильно ))

[@vifvrTtb0vmFtbyrM_Q]

@@Paul-kr8dq мне кажется не надо превращать код ревью в параллельное программирование. Все синтаксические и т.п. ошибки отлавливаются на этапе компиляции. Все проблемы с невалидными данными отваливаются на этапе тестирования. По коду коллеги могут подсказать что куда надо вызывать, какие либы использовать (например если есть платформенные, вместо самописных велосипедов). также по стайлгайду и т.п. вещам из domain driven и то что решили когда-то на ретро. Например решили отказаться от CQRS и в новых сервисах пишем по нормальному или наоборот. Я про код ревью на уровне мидл/сеньор. А не на уровне джуна.

[@Paul-kr8dq]

@@vifvrTtb0vmFtbyrM_Q Так если всё так хорошо отлавливается кем-то или чем-то другим, у вменяемого техлида (или, кто там ещё конкретно отвечает за процессы) должен возникнуть резонный вопрос: а в чём тогда роль самого ревьювера? Нахрена ему тратить драгоценное рабочее время на этот ритуал, который не приносит никакой реальной пользы сверх того, что и так (возможно) найдут тулзы или QA? Есть такая нехитрая истина: стоимость устранения проблемы тем выше (экспоненциально!), чем позже в цепочке эта проблема выявляется. Если её найдут QA, это уже нехилый косяк, а если только на деплое или на продакшене, то вообще есть все шансы, что она тупо превратится в пожизненный камень в желудке, ибо бесконечно подпирать её потом новыми и новыми костылями может оказаться всё ещё дешевле, чем пофиксить. Так вот, ревью, как практика, изначально придумано для того, чтоб обнаруживать проблемы как можно раньше, а вовсе не как ритуал легализации перекладывания их на других. Повторяю, с точки зрения бизнеса, ревью нужно либо делать нормально, либо не делать вообще. Все модно-молодёжные "промежуточные" варианты и обоснования, это в 99% процентах случаев чисто выбрасывание денег на ветер. Ну а если кому всё равно сильно охота поумничать в комментах и порасставлять галочки, не беря на себя при этом никакой реальной ответственности за отревьювеный код, вполне может заниматься этим и в своё личное время и за свой счёт ))

[@CultureofSpeech]

Такие умные ребята кругом публично вещают активно, и Уже должны придумать хотя бы примерную формулу как считать полную стоимость оплаты труда Наёмного работника программиста (и любой полезной профессии) с максимальным учётом всех всех издержек (моральных и физических). И Если наниматели владельцы прибыли не согласны с этой формулой, так пусть они тогда сами сидят на своём предприятии , логично же ⁉️

[@yavbvb123]

Как можно серьезно воспринимать взрослого человека, когда у него на полке стоят книги про Гарри Поттера?

[@asd121asd]

Исключительно позитивно!

[@katellaEvgenii]

Предлагаю вам развернуть мысль, воспользовавшись шаблоном: Книги про Гарри Поттера на полке у взрослого человека, безотносительно того как и откуда они там взялись, это плохо, потому что… (продолжите мысль)

[@yavbvb123]

@@katellaEvgenii , до того как задавать этот вопрос, мне нужно было подумать кому я его задаю

[@omgwtf0]

@@yavbvb123 или пересмотреть свои критерии оценки, попрактиковать критическое мышление, быть может, они ошибочные)

[@KuradoKunio]

мусорное видео