Нас с вами попросили решить, кто тут прав: Кто и что думает в итоге?

@user-zs3xe3if2s

14 күн бұрын

кейси чисто базы навалил, зачем нам читабельный, но медленный код?

@user-lg4xt8ds8t

14 күн бұрын

Пусть я и не сильный аналитик и не глубоко знаком со структурой вне clean code - но я никогда не задумывался от этом, и теперь я пересмотрю подход к использованию solid и dry, спасибо за ролик.

@ostrovlyan

14 күн бұрын

в итоге как будто все такое позорно медленное из-за денег, внезапно. Опять виноват капитализм :)

@nikolaykozlov4888

14 күн бұрын

Я как адепт чистого Си - за Кейси.

@user-pg5ny2ev7r

14 күн бұрын

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

Как говорится "На ассемблере можно написать всё что угодно. Но жизнь коротка."

@user-xi6xo9cu7b

14 күн бұрын

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

@MamayFreeride

14 күн бұрын

Видимо в следующей жизни =)

@Pillow12442

14 күн бұрын

​@@user-xi6xo9cu7bспорное заявление про читать чужой код. Если ты опытный ты и всю лапшу индусского кода разберёшь. Мне лично помогло книги по рефакторингу

@Redfvvg

14 күн бұрын

​@@user-xi6xo9cu7bПойдет так, когда каждый сможет написать язык программирования чисто для себя. Под свое понимание реальности, скорости разработки, эффективности. Невозможно создать универсальный интерпретатор, без ИИ

@user-hruser

14 күн бұрын

На ассемблере пишут некоторые вставки в c c++ коде, если нужна производительность то будешь писать что даст результат

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

@upzzdlmass5244

11 күн бұрын

Ахахха))) Новая мета на говнокод грядет?)) Я скоро смогу считать себя программистом?))

@doccerplay3939

9 күн бұрын

Наконец-то выход начинающих геймдеверов...

@user-cs1we8kv2o

9 күн бұрын

Эт не так работает)

@r-morozov

8 күн бұрын

Скорее ты пишешь плохо читаемый и по прежнему медленный код 😅

@komillermaster6821

7 күн бұрын

​@@r-morozov жиза

Был в моей жизни период, когда я одновременно работал над разными проектами. Первый - Backend на Java Spring в команде, второй - прошивка для STM32 (микроконтроллер) на С++ в соло. Мои коллеги (Java разработчики) активно призывали использовать принципы Clean Code и старались обсуждать и доносить идеи до остальных. Тогда я и начал в это активно погружаться. Многие идеи я пытался использовать и в своем проекте на C++. Однако тут мне пришлось осознанно нарушать многие правила, поскольку производительность микроконтроллеров слишком ограниченная, и многое приходилось писать "в лоб", избегая сложных абстракций и т.п. Уже тогда я для себя понял, что важно мыслить гораздо шире, и отталкиваться в первую очередь от целей, а не применять правила ради применения правил. Просто думайте и совершенствуйтесь!!!

@Pillow12442

14 күн бұрын

Согласен с тобой на 100%

@kadr6424

13 күн бұрын

Контекст > Метод

@Sergey_Levin

13 күн бұрын

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

@konstantinchernickevich5826

13 күн бұрын

C++ Variadic Templates :)

@leosv0

12 күн бұрын

На МК надо писать на Си и не выпендриваться.

Программисты когда 10 уровней абстракции лагают: 🤯

@che42cc

14 күн бұрын

Лагают ещё ладно, гораздо хуже когда приходится искать баги в этой кунсткамере...

@boost_456

12 күн бұрын

@@che42cc я посмотрю на тебя если ты будешь искать баги в коде без DRY, где будет миллион расходящихся модификаций

@krevetka4933

11 күн бұрын

Да хоть 100 Оно в любом случае транслируется в машинный код

@nezdanchick4933

11 күн бұрын

​@@krevetka4933 В любом случае вызов функции это инструкция процессора, поэтому все абстракции занимают время.

@sir.Geronis

11 күн бұрын

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

Читал на каком-то форуме пост от чувака, у которого горело от размера приложений на телефон. Что, мол, банковские клиенты весят ~500МБ, в то время как гта 3 (или SA, не помню уже) тоже весила что-то около 500. И, говорит, "сбер, где мой открытый мир в твоем приложении?)" И в комментах люди расписали ему, что пофигу компаниям на размеры приложений сейчас, у телефонов есть ресурсы, так что можно забить и важна лишь скорость написания и выкатывания фич Это я к тому, что бизнесу скорее важна производительность программиста, нежели железа

@TheDzzirtuoz

14 күн бұрын

То же самое про ОС. Винда 7 - 500 МБ, современный андроид - 7-10 ГБ, отжирающий больше половины встроенной памяти

@keysi6101

13 күн бұрын

Именно так… Софт ложитек для обновления драйвера мышки - 286 мегабайт "Дальнобойщики 2" - 270 мб 😅

@AirDrug

13 күн бұрын

@@TheDzzirtuoz Nadroid LinageOS вдохнул вторую жизнь старому планшету Samsung Galaxy Tab 3 с 1Gb памяти, откудава 10гб андроиды ? )

@stas4414

12 күн бұрын

Я смотрел видос с разбором кода гта 3, там было много свич кейсов)

@fugi_1564

12 күн бұрын

Вопросы к фронтендерам

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

@payrgames

14 күн бұрын

Баланс для каждого субьективен

@FXGO807_7

14 күн бұрын

Именно поэтому я пишу на c++ со вставочными конструкциями asm

@hyuzw

14 күн бұрын

​@@payrgames поэтому и пишут по-разному

@gtrtr6291

14 күн бұрын

@@FXGO807_7 типо ты лучше компилятора оптимизируешь?

@Stay_Away_from_the_Voodoo

14 күн бұрын

нейронки все разрулят рано или поздно, выдадут каждому желающему х20 производительность (если не всем задачам, то всех уровня мидла), ну а читаемость кода уже не будет важна т.к. проги будут писаться уже не человеком (ну, постепенно вытесняя человека, окей?) из за того что стоимость нейронки будет стоить около 10 центов за написание, а тот же программист мидл будет это же делать за зп в тысячу $. И да, это не я выдумал, так говорит Сэм Олтман, их цель на ближайшие годы это снизить стоимость интеллектуальной работы к 0$

"Да, да, производительность важна", покивали головой мы, и пошли заворачивать свои серверки в докер

@MaxBibs

14 күн бұрын

😂

@borismoiseev8456

14 күн бұрын

Которые еще на docker desktop👍🏼

@Milk-gw1zl

14 күн бұрын

И писать пародию на микросервисную архитектуру где на каждый пук Http запрос😂

@roman7956

14 күн бұрын

@@Milk-gw1zl во во. в вебе где на каждый чих или запрос в базу или вызов апи, все эти "замены полиморфизма на свитч" как экономия на спичках выглядит.

@B-S-A

13 күн бұрын

Docker, на самом деле, не даёт никакого дополнительного пенальти производительности. Ну, может, кроме самого демона докера. Тогда возьмите Podman. Всё, что "завёрнуто" в Docker, по сути точно такие же процессы в ОС, мы тут не будем рассматривать, если докер под мастдай в виртуальной машине. Используются всё те же системные вызовы, что и без использования докер.

У меня есть подозрение, что монструозный и тормозящий софт под капотом совсем не clean.

@mndtr0

14 күн бұрын

Ну тут сурсы надо смотреть, иначе не скажешь...

@roman7956

14 күн бұрын

имя опыт работы на по настоящему дерьмово написанных проектах, могу уверенно заявить, что я ни разу не видел чтобы "следование клин коду" вызывало проблемы с перфомансом, обычно совсем наоборот

@mndtr0

14 күн бұрын

@@roman7956 кто мы, а кто авторы фундаментальных противоборствующих концепций программирования...

@Unknown-pg4ss

12 күн бұрын

@@roman7956 Так и за перфомансом не гнались))

@cenu41

12 күн бұрын

Поддерживаю что проекты с нормальной архитектурой работают лучше. Легче бьются на микросервисы, легче расширяются. А мест где бы нужна хорошая оптимизация очень мало и жертвование читаемостью там допустимо. Но обычно проекты без клин кода это монструозный кусок мусора с имиджем на 30 гигов который писался с идеей «нет времени думать нужно делать». И их улучшение требует такую прорву часов что никто этого не делает.

Я когда смотрел оригинальное видео то не мог понять: он то ли троллит, то ли серьёзно. Дональд Кнут когда-то сказал: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: *premature optimization is the root of all evil*. Yet we should not pass up our opportunities in that critical 3%." Именно эту ошибку Кейси по сути и сделал. Для начала он выдаёт за неоспоримый и ничем не подтверждённый факт, что "все современные приложения написанные по чистому коду вызывают пачками полиморфные функции миллионами в секунду и поэтому тормозят в десятки раз". И нам надо принимать это как истину не требующую каких либо подтверждений. Так он в буквальном смысле создал "чучело врага" и будет его громить. В качестве подтверждения своей теории, он не показывает проблему в реальных приложениях, а он берёт *абстрактный кусок полиморфного кода* и запускает его в цикле на миллион (1048576) итераций как бы подразумевая, что так в реальных приложениях всё и работает. Затем он делает оптимизацию этого кода и показывает, что оптимизированный работает в 10 раз быстрей и делает вывод: ваш clean code - фигня и *все приложения* тормозят в десятки раз. Таким образом делая одно допущение за другим он в итоге решает абстрактную проблему и оптимизирует не реально тормозящий код из реального приложения, а "нечто", что вероятно в реальных приложениях и не вызывается миллионы-миллионы раз в секунду, а потому и не является реальной проблемой. Это то самое зло от преждевременной оптимизации: мы имеем соптимизированную абстрактную проблему, а не реальную. У меня сразу была куча вопросов к его видео вроде: почему при наличии современных мощных профилировщиков никто в индустрии не говорит о тормозящем полиморфизме, а говорят в основном о других проблемах в производительности (память, кэш, i/o)? Код из примера Кейси вычисляющий некоторые графические примитивы конечно же существует, но в реальных приложениях такие вещи вызываются жалкие сотни вызовов в секунду, и они попросту не вылазят в топы статистики профилировщиков. В моём личном опыте по портированию и оптимизациии графического стека Qt и браузерных движков для embedded платформ я никогда не видел, чтобы в них кто-то в здравом уме в циклы с миллионами итераций вставлял вызывы каких-то ф-ии и уж тем более полиморфных. Большинство проблем производительности сегодня это обработка огромных массивов данных (в основном графика), которые не умещаются в кэше процессора, за что мы каждую секунду получаем громаднейшие пенальти. В профилировщике обычно в топ вылезает именно это, а не какие-то вызовы. При обработке громандных массивов данных в огромных циклах как раз и применяются оптимизации упомянутые Кейси, но зачем тащить оптимизации приминимые для больших данных/итераций туда, где они не дадут значимого выигрыша, но усложнят читаемость кода?

@user-mr9tw6rj9i

10 күн бұрын

А станет ли он сильно сложнее без клин кода ?

@Milk-gw1zl

10 күн бұрын

​@@user-mr9tw6rj9iда

@lokpasddq763

10 күн бұрын

Буддист решил помытся и утонул... В желтой воде..

@alexeyromenskiy2664

10 күн бұрын

Это вы, батенька, спорите с соломенным чучелом. Где у Кейси было сказано, что трудозатраты на оптимизацию кода окупаются всегда? Он говорит совсем другое: не всегда clean code важен любой ценой, нужно знать его издержки и понимать, когда необходимо от него отступить. И есть масса случаев, когда это случается на практике. Даже тот код, который не выполняется миллионы раз внутри какого-нибудь цикла, бывает нужно оптимизировать, если он сам вызывается миллионы раз в секунду. Я на своей практике сталкивался с такими ситуациями, когда уже не было смысла в программе оптимизировать узкие места, поскольку каждая строчка программы примерно в равной степени тормозила систему до неприемлемого по техзаданию уровня. И я сталкивался в своей работе с тоже-программистами, которые сначала цитировали Кнута про "преждевременную оптимизацию", а потом спустя некоторое время и вполне предсказуемо бегали кругами и кричали, почему продакшен нестерпимо тормозит и что надо срочно что-то с этим делать, желательно вчера. Полагаю, вы так же не сталкивались с проблемами производительности таких вещей как высокочастотный трейдинг и различных OLTP-подобных приложений, а это весьма обширная область. Так что говорить, где лежит большинство проблем, несколько самонадеянно.

@someoneneverknown1120

9 күн бұрын

> почему при наличии современных мощных профилировщиков никто в индустрии не говорит о тормозящем полиморфизме, а говорят в основном о других проблемах в производительности (память, кэш, i/o)? Потому что новое железо достаточно купить, а новые знания нужно майнить?

Чота я не понел. Чувак доказал, что если убрать vtable и прочие плюшки, написать код, специализированный для данной операции, то он будет быстрее? Ну да, будет, а чего такого-тооооо? Иногда мы именно так и делаем на микроконтроллерах, если нужно прям очень ужаться по производительности или памяти или чтоб выдерживать тайминги до тактов. Но в абсолютном большинстве программ это не требуется. Но есть один нюанс. Очень трудно написать в таком стиле большую программу. Поэтому нужно знать что, когда и в каких случаях применять. Ваш капитан Кэп.

@roman7956

14 күн бұрын

ну вы так в своих рассуждениях вообще можете дойти до идеи что "серебрянной пули нет" и "головой нужно думать что и зачем ты делаешь", а холиварить тогда как????

@drgluck07

14 күн бұрын

@@roman7956 да, что это я в самом-то деле. Ну ок, погнали: иногда, в редких случаях, в C можно использовать goto. У меня был кейс, когда буквально пришлось основной цикл программы (на микроконтроллере, оф коз) построить на goto. Там почти вообще не вызывались функции, ибо это дорого по времени.

@user-ug8cj4fb4s

13 күн бұрын

Кто мы? 2.5 человека и один из них инвалид на голову раз это не понимает.

@say4280

12 күн бұрын

@@drgluck07 Код с goto нужен, если в конце функции есть finalize-секция, в которую надо переходить в случае ошибок. Сам я такой код не писал (потому что прогаю на C++, где есть RAII), но в весьма известных программах на C видел, и это замечательно читалось и не вызывало никаких вопросов.

@sir.Geronis

11 күн бұрын

Не трудно. А реально. Просто изначально надо не заморачиваться в лищние удобства и с опытом придет скорость.

Вообще-то все зависит от конкретной задачи. Если мы видим, что какой-то кусок кода выполняется раз в 2 часа и его выполнение занимает не 100 наносекунд, а 250 (из-за чистого кода), то ускорять нам ничего и не надо. Он прозрачен и в нем нет ошибок. Если же код выполняется каждые 500мс*100000 раз, то тут уже не до красоты. Фигачим отдельный класс FastMaker в котором будут и свитчи и использование всяких AVX инструкций и вычисление на GPU и asm вставки. Байто*бить это тоже плохо, как и медленный красивый код. Для тех кто не согласен: код который мы пишем был изобретен для упрощения создания машинных кодов. При любом раскладе событий в машинном коде можно добиться лучшей производительности. Это ведь не повод отказаться от языков программирования?

@tohoto2183

14 күн бұрын

А на фига тебе вообще класс фигачить,может просто макросами там чисто сишным или плюсовым ?

@roman7956

14 күн бұрын

база

@kniazew_daniil

14 күн бұрын

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

@michaelm5966

11 күн бұрын

Посыл в том, что никто ничего не оптимизирует, все ждут что железо станет лучше.

@sir.Geronis

11 күн бұрын

Правда в словах есть. Иной раз, можно позволить выполняться коду долго.

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

@tohoto2183

14 күн бұрын

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

@user-el2xc2su4s

Күн бұрын

Код сначала должен работать, а потом - работать ПРАВИЛЬНО

@roman7956

Күн бұрын

@@user-el2xc2su4s "должен работать" это и имелось ввиду правильно, он должен делать то, ради чего был написан

Что любопытно - очень многие воспринимают этот спор так, словно сторонники "чистого кода" топят против производительности, а сторонники производительности топят за говнокод(лишь бы он был быстрым). Но это, на мой взгляд, совсем не так. С высоты своего опыта коммерческой разработки(~25 лет) лишь подметить, что подавляющему большинству коммерческого кода даже до "чистого кода" - как до Китая пешком. А код не должен быть "чистым или быстрым", он должен быть "чистым И быстрым". Но, пока платит бизнес, вряд ли так будет на массовом уровне.

@rkurbatov

10 күн бұрын

Ото ж. Люди, которые говорят, что Clean Code - фигня, хотят писать еще более медленный говнокод. Для того, чтобы писать оптимально, надо научиться писать ЧИСТО для начала. Я буквально вчера в ревью заставил джуна вынести одну и ту же функцию, которую он создал в каждом месте, где она была нужна - около 20 повторений. Сомневаюсь, что это ускоряло производительность. Он просто быдлокодит.

@ValkRover

Күн бұрын

Когда сроки проекта горят, уже не до чистоты кода и не до производительности. Заказчик этого все равно не оценит, а дорабатывать уже можно и потом за отдельную плату. А если со сроками проблем нет то, конечно - "чисто И быстро".

@user-el2xc2su4s

Күн бұрын

Все так - код одновременно И должен быть производительным, И не должен быть говнокодом. Но для этого в голове должны быть мозги - а вот с этим сейчас огромнейший дефицит.

@rkurbatov

Күн бұрын

@@ValkRover это отмазка. Если навыки есть, быдлокода не будет.

@ValkRover

21 сағат бұрын

@@rkurbatov Да, знаю я! Не умею плохо, это и беда!

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

@YaShoom

14 күн бұрын

Самое важное, что из этого можно сделать выводы, а не слепо следовать чему-то.

@Paladin_one

14 күн бұрын

Правды ради тот кто хайпит на антихайпе кратко пересказал всё из-за чего был устроен шум

@TheDzzirtuoz

14 күн бұрын

Этот комментарий - большая жирная точка во всём этом споре. Остальное - просто спинофф ради статистики)

@ivanivory6247

13 күн бұрын

Лучший комент) А что еще ожидать: Среди панелек, хрущёвок и деревянных изб По нам палит шрапнелью капитализм 25/17

@user-mobilnik

12 күн бұрын

Да, деньги есть мерило всего в нашем мире, и не важно как их доставать). И всё равно нам на экологию, разрушительные войны...зато столько денег выручают за каждую единицу боевой техники!) одна польза) Живи, пока ты ещё выгоден своему работодателю; диши гразным воздухом за то что экологическое производство устанавливать дорого; лечись в помойке, потому что больница не бесплатная; смотри как миллионы нищих умирают на улицах и живет Африка, пока "крутые" блогеры жируют; вспоминай как расстреливают парламент из танков, как буквально забирают твоих родных на войну прямо в пекло. А если ты не согласен, то ты же "против государства! демократии! украинский иноагент сатанинского гейропейского запада!", тогда берешь красный флаг в руки и вперед за демократию, прямо на баррикады против омона с дубинками, чтобы люди начали жить, а не доживать зарплату

Как по мне тут всё довольно просто: программисты стараются писать чистый код, а там где не хватает производительности, оптимизируют как лучше

@FyUajYpUlM39

14 күн бұрын

Фу, скушный практичный центрист! А как же развести многолетний срач и написать десятки книжек?)

@vsevolodkuleshov8551

14 күн бұрын

Ну как бы разница в 15-20раз это провалл клинкода. У нас процессоры не стали на столько быстрее с 2007 года. Там хорошо если они стали быстрее раза в 3. Чего реально стало больше это ядер и памяти. Но это не сильно решает проблемму быстродействия. Ядра помогают многозадачности а не ускорению конкретного процесса. Да теперь мы можем и браузер запустить и игру и стрим если количество ядер и памяти позволяет. Но если процесс не оптемезирован то тут уже никакие ядра не спасут.

@Sergey_Levin

13 күн бұрын

@@vsevolodkuleshov8551 нет. Это - провал постановки задачи. то есть - руководителя проекта

@_cyp4ik_201

12 күн бұрын

Что не верится в это. Игровая индустрия тому пример

@rexdraconis1703

12 күн бұрын

​@@vsevolodkuleshov8551ну это не разницы в 15-20 раз, а в несколько десятков цикла процессора. Когда с бд загрузка идет секунду, все другое не очень играет роль

Говоря про быстрый код, многие представляют какой-то нечитабельный ужас с указателями на указатели, инлайн ассмебли и кучей симд, хотя зачастую все, что надо для +- производительного кода, это: - грамотное использование фич/языка (зарезервировать место для вектора и скопом добавить объекты, а не резервировать для каждого элемента) - маломальское знание алгоритмов/динамического программирования (сохранить результаты вычислений, чтобы ускорить последующие, не использовать 4 вложенных цикла там, где можно обойтись двумя) И даже так, как по мне, комфорт программистов не стоит того, чтобы у конечного пользователя 30 секунд грузился ГУИ из-за 10 слоев абстракций

@user-pd9du9on6s

14 күн бұрын

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

@fein7068

14 күн бұрын

@@user-pd9du9on6s Далеко ходить не нужно, достаточно прикоснутся к DirectX.

@kittenlord3572

14 күн бұрын

@@user-pd9du9on6s вообще да, но тем, кто крутится в таких сферах где производительность очень сильно важна, скорее всего в кайф реализовывать сложные и нечитабельные алгоритмы и выжимать из железа максимум самым малоизвестным методом)

@uis246

14 күн бұрын

SIMD очень прост и переносим, если ты согласен писать на гнутом диалекте. typedef float vec4 __attribute__((vector_size(4*sizeof(float)))) и пиши

@ulcuber

14 күн бұрын

Хорошо смотреть на Xorg и отвечать на вопрос, почему появился Wayland

Странная дискусия. Мне помнится что даже в книге есть сноска, что упарываться не нужно и можно отступать от правил

@user-el2xc2su4s

Күн бұрын

Иногда - даже нужно.

А потом в телефоне приложение с напоминалкой сжирает 500МБ памяти и батарею сажает :) Утрирую, конечно, но так и есть.

@OlegMasters

5 күн бұрын

А потом у нас и приложений нет в маркетах ещё))) Да у нас везде проблемы!

Читал я чистый код. Принимать без фанатизма. Во главе всегда дожен быть здравый смысл

@manOfPlanetEarth

13 күн бұрын

маэстро, я вас узнал в гриме😉

@ralymbetov

7 күн бұрын

@@manOfPlanetEarth убил просто 🤣

@manOfPlanetEarth

7 күн бұрын

@@ralymbetov 🤣

@user-el2xc2su4s

Күн бұрын

Именно так и есть. Но люди религиозны - именно от отсутствия смысла в голове.

Самое лучшее объяснение SOLID из возможных!!! 90 секунд суперпонятной базы, я в шоке. Респектище ❤

Проблема не в том чего хочет знать или не знать программист. Если отказаться от непроизводительного чистого кода, то бизнесу придется нанимать Senior и Middle там, где хватило бы одного middle и пачки студентов. А бизнес такого не хочет, сервера докупить дешевле...

@AleksandrMaltsev-jm8ph

14 күн бұрын

Один человек, из толпы просто написал как есть, Спасибо

@Firegalensk

9 күн бұрын

нет на рынке столько Senior и Middle, чтобы покрыть задачи бизнеса сейчас их и сейчас-то нет, а если упарываться в производительность, то и подавно не будет

Клинкод дает одну особенность, которую не дает подход кейси: расширяемость На примере фигур он переделал классы в енамы и свитчи. Но если у тебя система плагинов, ты не воткнешься в енам, а свитчи сами не расширятся. Здесь нужен именно полиморфизм. Надо брать лучшее от этого и не застревать на одном месте. Если ты будешь тупить 10 минут над ускорением горячего кода - ок, если день над холодным - не ок.

@EvgeniyFadeev

5 күн бұрын

Удивительно как мало людей понимают этот, в целом довольно тривиальный, факт...

Это конечно все очень круто и интерестно, но когда плюсы за 10 часов?

@dezdoz1837

14 күн бұрын

а че не за час? И после сразу отклик на сеньора плюсов.

@Quel1-chan

14 күн бұрын

Так гайд на сами плюсы, вдобавок, его надо учить, а не посмотрел=понял. Все остальное прилагаемое и можно учить, делая свой проект, к примеру.

@aririi6016

14 күн бұрын

После войны пчёл

@nallsur

12 күн бұрын

​@@aririi6016человек культуры

@forestergogo

11 күн бұрын

@@aririi6016 слишком сырно

На самом деле спор ни о чем. Там где нужна производительность - пишут производительный код, но в современном мире большинство программ работают с I/O нагрузками, и плевать сколько тактов процессора тратит программа, если потом сидит и ждет ответ от сервера/базы данных/чтения файла/действия пользователя и кучи чего еще.

@user-cd4dz9xz3w

14 күн бұрын

Хорошо, что человек из комментариев пришел и развалил двух гениев и их спор, а то сцепились ни о чем

@fein7068

14 күн бұрын

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

@user-jf5bn1jw3b

14 күн бұрын

@@fein7068 да, интересно какая там производительность у Бэка на джаваскрипте или питоне) С графикой согласен, но там и используют производительный код, я ж пишу, где что надо, там то и используют.

@user-zn7uu6xq4h

14 күн бұрын

как хорошо жить в мире, в котором задержки не суммируются, а накладываются :D

@user-jf5bn1jw3b

14 күн бұрын

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

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

@dmitriyivanich1088

12 күн бұрын

ммм, то-то я смотрю игры у нас пиздец какие производительные, не лагают никогда и у всех все идет в +100500 фпс в разрешение 16к, ага. А если серьезно, то у нас два главных движка это Анриал и Юнити и оба используют ООП.

@watzephuck7837

12 күн бұрын

@@dmitriyivanich1088 не играй во всякое говно просто)

@MrrrMrrrMrrr

12 күн бұрын

​@@dmitriyivanich1088не знаю как анрил, но в юнити конечно такое ооп царское, просто залюбуешься. Весь апи это статика в статике под статикой и статикой погоняет. Ах, ну да, там же наследование есть от MonoBehavior и полиморфизм на Update() и некоторые другие ивенты, ну это, конечно, да, всё меняет )

@tnak7947

12 күн бұрын

@@dmitriyivanich1088 И в обоих лютый говокод и никакого CleanCod-а, тонны багов и отсутствие хорошей производительности. И таких проектов большинство, компании даже могут и не знать об этом, спасибо техлидам и менеджерам, т.е где как повезёт)

@ELFMEDIA

11 күн бұрын

@@dmitriyivanich1088 Вспоминаю, как в конце 90х - начале 2000х играл в анрил турнамент (ещё тот, первый) на первом пне на 150 мегагерцах и 16 мегабайтах оперы, и первой вуду 3дфх. Сейчас гигагерцы и гигабайты, это вроде в дохера раз больше, а всё что по сути изменилось - текстуры покрасивше да полигонов побольше. Как-то не пропорционально

7:16 Скорее всего, "чистый код" сделан для того, чтобы люди поняли, как писать *ПОНЯТНЫЙ*, а не компактный код. А еще, всем новичкам было бы неплохо прочитать эту книгу

Помню 2000-е, когда ООП-код на С++ руинил весь перформенс на процессорах с длинным конвейером от Texas Instruments. В то время как плохо-читаемый код на Си, написанный с учетом архитектуры, летал.

@chistovmaxim

4 күн бұрын

в 2020ых 90% оптимизаций под конкретные процессоры применяется автоматически)

Я ещё помню те времена, когда говорил, что преждевременная оптимизация -- источник всех бед :) Все эти микрооптимизации хороши до первого сетевого запроса или неоптимальный выборки из базы, которые съедят всё, что вы наоптимизировали

@SergeyGlotov

12 күн бұрын

Полная цитата говорит именно об этом: "There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

@sir.Geronis

11 күн бұрын

​@@SergeyGlotov и потом мы получаем игры, которые по графике хуже игр 2000 но требуют 4090. Да хули заморачиваться писать оптимизированный код, если можно быстро тяп ляп хуяк и в продакшн. Правда в том, что писать оптимизированный код не сложно и не долго, но приходит с опытом. Ты просто уже на автомате знаешь какие конструкции и алгоритмы быстрые и сразу их пишешь. Программирование с опытом становится стенографией, где ты пишешь код на автомате. Твоя цитата человека, которому похуй на код и его производительность. Ему надо нанять джунов, которые за два рубля напишут любой работающий код и он сможет продать это за сотни рублей.

@0imax

9 күн бұрын

@@sir.Geronisтормозные игры - плохой пример, потому что геймдев - это одно из исключений из правила о преждевременной оптимизации, т.к. о скорости работы нужно заботиться на всём процессе разработки. Ну а появляются такие тормозные игрули из-за того, что даже те самые 3% из цитаты не подвергаются анализу производительности, и лепится всё "как есть". С таким подходом писали тормозное г-но и без всякого клин кода.

@sir.Geronis

9 күн бұрын

@@0imax игры эьто очень хороший пример. Но если тебе не нравится. То давай возьмем офисные приложения. Которые весят десяток ГБ, требуют не один ГБ памяти, только для запуска, а для полноценной работы требуются еще несколько ГБ. И в тоже время есть альтернативные офисные решения где в десятки раз меньше ресурсов требуется. А мобильные приложения, калькулятор 120МБ. Банковское приложение 500МБ. И тп. Таких примеров милион. Просто надо открыть глаза и прекратить сыпать в них соль. А игры это просто самый наглядный пример, где слово оптимизация потом взята за аксиому.

@dmitriylatukhin7356

2 күн бұрын

А знаешь, из-за чего появляется по-настоящему фиговая производительность в больших проектах? Из-за того что один программист наоптимизировал всё, влепил внутри одной функции, а другой вызвал эту оптимизированную под 1 задачу функцию в немного другой задаче, где половина этих операций совсем не нужна. От того, что люди пишут не очень чистый код, другие просто их не понимают полностью и ломают производительность ещё больше, чем если бы код был чистым.

С производительностью ****** везде, один веб чего только стоит с зоопарком фреймворков, смотришь профилирование и ужасаешься всему тому *****, что вылетает там

@BIackFox11

12 күн бұрын

По моему личному мнению, ты можешь использовать фреймворк в том случае, если у тебя достаточно навыков написать такой же если у тебя будет достаточно времени

@MrrrMrrrMrrr

12 күн бұрын

​@@BIackFox11ничего себе, так, получается, все возвращаемся на plain js и jquery?

@_iPilot

5 күн бұрын

@@MrrrMrrrMrrr а может ну нахер этот JS, а? WebAssembly!

"свичи и виртуальный функции реализованы одинаково в компиляторе" 😂

@bookbrain9863

13 күн бұрын

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

@stanislavdenysenko2007

3 күн бұрын

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

В чем проблема писать места не требующие производительности с использованием clean code, но если требуется, то оптимизировать только определенные места.

@CilezSayles

14 күн бұрын

Нет проблем, все так и делают.

@l1nuvv

14 күн бұрын

возможно, code style будет разный

@markovegor4198

14 күн бұрын

@@CilezSayles смысл этого говноспора двух "титанов" я не уоловил

@adori.eterno

12 күн бұрын

Эм... Я типо программист. Даже дипломную скоро сдаю. Вопрос: почему я об этом узнаю только сейчас? У нас в колледже даже по ООП прошлись мимолетом. Посоветуйте курсы по программированию. Есть что то по типу CS50?

@watzephuck7837

12 күн бұрын

@@adori.eterno программист))

Неужели никто «Искусство программирования для Unix» не читал? Эта тема стара как Unix 😁 Эрик Раймонд в этой своей книге уже давно обо всём этом писал. И критика ооп и постулат о приоритете стоимости человеко-часов над стоимостью процессорных циклов. Да. Вот так и живём 🤷‍♂️

@che42cc

14 күн бұрын

KISS - рулит, SOLID - сосёт))

@ulcuber

14 күн бұрын

@@che42cc его надо балансить с GRASP и здравым смыслом

@netricks4100

7 күн бұрын

А ещё там написано предпочитать текстовые протоколы бинарным в ущерб быстродействию, потому что отладку выполнять проще. И это правильно

13 минут, которые экономят часы и доставляют кучу удовольствия! Спасибо!

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

@MaxPV1981

11 күн бұрын

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

@0imax

9 күн бұрын

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

@alexanderd.7818

9 күн бұрын

@@0imax Эти "правила" являются набором догматов, не подкрепленных ничем, кроме субъективных впечатлений и _личного_ опыта. По сути, это религия, то есть полная противоположность научному подходу. Какой-то персонаж решил, что функция не должна быть длиннее 20 строк, к примеру. Или что цикломатическая сложность должна быть не более чем сколько-то там. И всё, толпа овец побежала исполнять. Потому что это же великий (Подставить имя тут) так сказал, посмотрите, он миллиард заработал в 20 лет, плохого не посоветует. Даже и не думая, зачем и почему, ради мнимой простоты чтения и поддержки. Даже не задумываясь о том, что десять функций отладить сложнее, чем одну, просто потому что человеческий мозг - не стековая машина, и он не приспособлен к хранению контекстов. А ведь мы программу пишем, а не духов вызываем. Это самый простой пример.

@alexanderd.7818

9 күн бұрын

@@0imax С остальными "правилами" точно так же. Ни одно из них не является непротиворечивым, работающим независимо от иных условий. Практически любое из них легко довести до маразма, написав код, который будет идеально соответствовать всем этим указаниям, но при этом будет невероятно усложненным и совершенно неподдерживаемым. Если бы эти "правила" были чем-то научно обоснованным, а не набором догматов, то их невозможно было бы довести до подобных предельных случаев. К примеру, возьмем наследование. Вы можете сказать, что это всё придирки, что нужно ограничить количество уровней абстракции разумной глубиной и все возрадуются. Скажем, 3 уровня. На что вам пять программистов скажет, что должно быть четыре или два. Ещё пять скажут, что наследования быть вообще не должно и нужны лишь интерфейсы. А потом подойдет школьник и заявит, что классический полиморфизм вообще не нужен, что это ерунда для старых пердунов, а примеси - это истинный путь в следующий век. И никто из них не сможет предоставить четкие и формализованные, фальсифицируемые критерии, почему именно _ОН_ прав. Которые у всех сойдутся, и с которыми все придут к одному и тому же выводу. Потому что субъективная херня всё это. Конструкт в голове, способ самовыразиться и собрать бабла с тех, кто готов покупать книжки с этой писаниной.

@0imax

9 күн бұрын

@@alexanderd.7818 Аксиома Эскобара говорит, что любые крайности - плохи. Не нужно воспринимать книгу как абсолютную истину, и не будет ни проблем, ни срачей по поводу))

Не жалею, что открыл это видео с кликбейтным заголовком! Спасибо автору за обзор!

О! Наконец-то кто то решился разобрать по фактам весь этот оверинженеринг, который пропагандируют с каждого утюга.... простой пример - любой учебный проект типа Hello World на чистом коде это 100500 разных абстракций погоняющих друг другом, черт ногу сломит понять где что и зачем... а надо то всего std::cout реализовать. а потом удивляемся что софт лагает, пишут то его те кто по таким учебникам учился.

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

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

@Unknown-pg4ss

12 күн бұрын

Когда говорят надо что бы за 500нс считалось, то тут перфоманс) Во всех остальных клин

перформенс давно в угол задвинули - одним лишь фактом, что всюду нынче питхон) самое смешное, что и нормального клин код в реальных проектах нет. код чаще теплый, мягкий и слегка липкий. Тоесть - и производительность просрана, и код аккуратно писать/проектировать не научились. Оба два.

@knarg4682

8 күн бұрын

"перформенс давно в угол задвинули - одним лишь фактом, что всюду нынче питхон) " А теперь представьте себе, сколько "стоит" каждый "шаг" на этом самом пихтоне и осознайте, насколько ТАМ важно, чтобы этих шагов стало не 1000, а 50.

@shurmurray

8 күн бұрын

@@knarg4682 На самом деле тут ситуация гораздо более сложна и многогранна. Можно сказать, что питон просто увековечил факт, что разработчики разучились ценить производительность (а бизнесс просто горизонтально масштабирует машины с бэкэндом на питоне). Обратный яркий пример - жаваскрипт с его JIT. Производительность бешаная, даже с плюсами конкурирует легко. И что толку? Открываешь очередной сайт - текст с картинками. А у тебя минус гиг оперативки и два ядра процессора на 110% загружены - под капотом вертятся мегабайты жаваскрипта непрерывно, всяческие трекеры, телеметрия, фоновая загрузка рекламы и ещё дьявол весь что. Зачем. Нахрена...

Так вот почему броузер жрет гигабайты. или нет?

@keysi6101

13 күн бұрын

Пожалуй, даже не сам браузер. Достаточно посмотреть на диспетчер Хрома, чтобы увидеть страницы с потреблением памяти от 100 до 400 Мб (каждая). И добавить к этому client-side rendering всяких фронтов на модных фреймворках - и здравствуйте! - проц фоном потихоньку "что-то майнит", пока грузит страницу ютуба Например, Notion складывает в куки браузера по 4 гигабайта в фоновом режиме…

@TheCktulhu

12 күн бұрын

он жрет гигабайты, потому что ты открыл сотню вкладок)

@dmitriyivanich1088

12 күн бұрын

ну вообще, оптимизация поскорости != оптимизации по используемой РАМ. вполне себе что быстрый код, может кушац больше оперативы чем медленный, но это не точно.

@pgrusha

12 күн бұрын

Именно так. Просто посмотри размеры и потребность в ресурсах компьютера MS Office 97, 2007 и самый последний. А по функционалу разница не велика. Причем большинству и функционала самой старой версии предостаточно.

@sir.Geronis

11 күн бұрын

И в том числе, но не только. Сами по себе страницы в интернете стали весить больше, больше медиа, больше скриптов и тп.

Наш Сеньер на старой работе всегда твердил сердито, что Чистый Код это хуита и инфоцыганство, все над ним посмеивались, мол бумер опять раскряхтелся, а тут вон оно как...

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

@ok-tz3vw

14 күн бұрын

Аналогичное наблюдение. Смотришь вакансию - в требованиях куча модных слов. А как заходишь в проект - какой там clean, там даже SOLID'ом не пахнет. И так практически везде.

Эм... самое смешное что они оба правы так как говорят о разных вещах. Кейси рассуждает о написании, скажем так, mature продукта, настоящего, ну типа ngnix или sqlite - это идеальные инструменты, которые на любом вейпере вытягивают 100К запросов. Ну или тот же Doom Кармака или OTP Elexir-а - вот такие вещи. А дядя Боб - про сляпывание прототипов, которые вместо того, чтобы выкинуть - раз-раз и в продакшен. ИМХО - 98% всего созданного и работающего софта - это чертовы прототипы, которые еще и постоянно допиливаются, потому что заказчик некомпетентен и не в состоянии видеть вообще, какой уж тут нос. И вот эти прототипы хоть как-то поддерживать в живом состоянии можно только со всеми этими клинкодными делами. Потому что иначе никто и трехметровой палкой не будет трогать оставленное предыдущим программистом. Особенно учитывая, что не все они Линусы и Кармаки. Так что клинкод - реальность галер и кровавого энтерпрайза. А создание настоящих продуктов - удел упоротых одиночек. Чёт типа того.

@manOfPlanetEarth

13 күн бұрын

так, что-то я не понял: прототипы пишутся с использованием клин код, а зрелый продукт типа nginx, который пишут упоротые одиночки, - у него какая история?

@Ktoyatakoiskazhimne

12 күн бұрын

@@manOfPlanetEarth nginx буквально писался одним человеком в свободное от работы время, в какое то время разраб уволился с работы, чтобы посвятить фуллтайм своему детищу. После чего галера(Имя ей Rambler), пытались отжать права на nginx.

@soberTrezviy

11 күн бұрын

продукт типа Doom 2016 написан не одиночками, но и с перфомансом там всё по красоте.

У каждого сообщества есть свой Мурыч

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

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

Ну то, что несмотря на весь прогресс железа, программы становятся все монструозные и работают все медленнее - это факт. Мой свежий ноут грузится и грузит докер десктоп или идею с плагинами или вскод с плагинами, уже столько, что, извините, я успеваю сходить поссать за это время. Мой PC AT в середине девяностых грузился и грузил среду разработки с СУБД гораздо быстрее.

@rkurbatov

10 күн бұрын

Ага. А когда я сажусь написать чего-то для своих ретромашин, мне почему-то больше нравится современная IDE с подсветкой синтаксиса и подсказками. Вы не захотите вернуться в вашу среду разработки середины 90-х.

@yaroslavpiddubnyak2025

8 күн бұрын

​@@rkurbatovэто ж не подсветки тормозят.

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

2:08 нет! не стоит!!! это неправильное понимание SRP! разбивать приложение на классы с одним методом чтобы этот класс мог выполнять только одну задачу - это неправильно! Класс нужно разделять если у него есть несколько причин для изменений. вот автоматизируете вы какой нибудь бизнес. если у вас есть класс, который нужно будет изменять и при обновлении должностной инструкции кладовщика и бухгалтера - это плохо спроектированный класс, он не соответствует SRP, его нужно разделить. Но если у нас есть класс, в котором 100500 методов, он описывает действия которые совершает кладовщик, и изменения законодательства в части налогообложения никак не вынуждают переделать этот класс - он внезапно соответствует SRP.

То что чистый код тормозит всегда было известно. Еще в книге "Рефакторинг кода" об этом говорили - быстрый код преобразуется в чистый. Неудивительно, что код, который пишут железнячники сильно отличается от кода прикладных программистов, потому что первые что-то знают :-) Проблема быстрого кода в том, что при обрастании функционалом объем кода растет и поддерживать его будет нереально сложно. Скорее всего решение должно пойти в сторону компиляторов, которые должны преобразовывать чистый код в быстрый, т.е. преобразовывать интерфейсы в if/switch и тому подобные вещи :-)

@alonecoder600

12 күн бұрын

Компиляторы не помогут. Распаковщик unrar для ZX Spectrum (автор AIG) изначально был сделан из C, скомпилированного ВРУЧНУЮ. Я оптимизировал его в 11 раз за счёт генерации кода разбора дерева на лету. Распаковщик JPEG для ZX Spectrum (автор >>RRA>>) изначально был сделан из ассемблерной программы для 68000, переведённой на Z80 ВРУЧНУЮ. Я оптимизировал его в 5 раз за счёт вылизывания трёх главных операций - выборка из битового потока, IDCT и пересчёт в экранный формат. Про 3D-движки даже говорить нечего, там всё прямо по регистрам раскладывается + используются вычисляемые переходы и патчи. Посмотрите игру Borsch.

Только не говорите этому Кейси про микросервисы😂

Странно, что такой код называют "чистым" скорее бы подошло название "читабельный"

ОС запускается быстрее чем VS, делаем выводы

@fineuarealittlepogchamp

9 күн бұрын

ну на самом деле не правда) В случае с виндовс, компьютер не совсем выключается)

@allstack1293

9 күн бұрын

@@fineuarealittlepogchamp гибернацию можно выключить (разницы по загрузке я не ощутил). Если не брать виндовс, то линуксятина грузится за секунды

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

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

А потом пользователи такие "Вааай, не оптимизировано, игры лагают, движки кривые, раньше было лучше и т.д. Как по мне, лучше быстродействие чем быстровысер.

@forlectures8685

10 күн бұрын

Из одной крайности в другую?

@user-ji4iy8db5k

10 күн бұрын

Да да, лучше писать говнокод, который невозможно адекватно расширять, а каждая новая фича для игры плодит (количество фич)^2 новых багов. Получилось говно, но зато какое быстрое.

@noway1co

6 күн бұрын

а на чьи бабосы то гулять будем, на твои?)

ждем следующую часть про OpenGL

Я не профи, но моё мнение такое: клин код так распиарили ( и многие компании его требуют ) для того, чтобы работника было легко заменить. Какой-то кастомный код другим участникам проекта труднее понять, а главное такой работник еше может и пальцы начать загибать и попросить прибавки зарплаты, а в случае его увольнения замену найти будет непросто, ну или после него там все переделывать, а для бизнеса это неприемлемый вариант, для бизнеса ты просто инструмент, который должен быть легко заменяем, как запчасть.

Все эти клинкодщики впухают когда пробуют написать какой-нибудь вычислительный шейдер.

Я подумал сначала, что видос будет про баттл Soer vs Nazarov😂😂😂

@alexpishvanov736

14 күн бұрын

Кто эти люди? )))

@l1nuvv

14 күн бұрын

вовремя хапапах

@oswi__

14 күн бұрын

ахвахвах легендарная битва P.S. ПРОПЕРТИ

@CHRNBRY

14 күн бұрын

А как же Соер против Мурыча?

неоптимизированный "clean code" в проприетарном закрытом софте заполонил все. лично я выбираю оптимизированный софт где это возможно. Установив какую-то утилиту которая грузит CPU на 100%, а потом попробовав другую похожую по функционалу, я выберу вторую.

@EvgeniyFadeev

5 күн бұрын

Это большая, но весьма типичная ошибка - называть говнокод чистым.

Надо тогда зарплаты программистам резать если они не могут делать программы работающие в 15 раз быстрее.

я пишу код для алготрейдинга, который должен отреагировать на изменение данных и уложиться в минимально возможное время. Цель не выходить из 1мс. Вот тут и приходит необходимость задуматься и над структурами данных, типах данных, циклах и кол-ве операций процессоров, кол-ве ядер, размещении данных данных в памяти, кеше и прочем. Но за 15 лет работы до этого, в этом не было необходимости и я не занимался профайлингом на уровне микро/наносекунд как разработчик.

@0imax

9 күн бұрын

Всё зависит от задачи, и производительность - один из пунктов ТЗ. Большинство софта вообще крутится не на пользовательских ПК, и является довольно сложным, чтобы писать его на ифах/свичах. Часто там вообще не важна скорость, главное - возможность без проблем нанять новую команду для поддержки этого монстра, и чтобы они не повесились, добавляя какой-нибудь мелкий функционал))

Просто не нужно перебарщивать с абстракциями и тому подобным и будет вам баланс

Какая может быть производительность когда большинство программистов пишут в костыльно-ориентированной парадигме?

Каждый код должен быть персонализирован, либо понятен тем, кто реально должен с ним работать. А вот оптимизация нужна везде.

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

Рекомендую к просмотру со скоростью 0.5 )

Ну понятно, что ничего не понятно. Вроде бы хочется скачать что performance и clean code это противоположности, но там вылезает Кейси и говорит что его подход читабельней. Вопросик. А как будет вести себя Архитектура Кейси в Громадном проекте? Будет ли его код настолько же читабельным. Я не разбираюсь, но мне кажется что прогеры отошли в сторону Clean Code именно по этой причине, а перформанс остался для узких мест, и его как модуль можно вставить в Clean Code в места где это действительно важно, и вот тут как мне кажется Clean Code недоработан... Жаль что я не знаю ответа на свой вопрос.

@user-mr9tw6rj9i

10 күн бұрын

Почему все умные комментарии внизу списка а умники по типу клинкод для мелких программ в топе

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

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

"+", если тоже смогли догадаться, что происходит на 3:50

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

@fnhm_

14 күн бұрын

Из очевидности факта X для Боба не следует его очевидность для Алисы. И наоборот

@B-S-A

13 күн бұрын

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

@lutwiy931

13 күн бұрын

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

@nurlansalahaddinov8075

13 күн бұрын

@@lutwiy931какой ужас. Хорошо что я не программист. Если про инструмент коммуникации правда, то это прям жесть. То есть кто-то из программистов может не понять элегантный код? Проясню, что такое элегантность. Это когда написан оптимальный алгоритм, без лишних действий. Бритва Оккама. Когда ты не пишешь лишнее разветвление или цикл. Не используешь лишних переменных. Я когда такой вижу, не то чтобы понимаю, у меня прям мурашки по коже от удовольствия. Это же чистый кайф.

@lutwiy931

13 күн бұрын

@@nurlansalahaddinov8075 и чем твое определение "элегантности" противоречит объяснению Мартина? Ах да. Тем, что ты его объяснение скорее всего даже не открывал. Что в целом нормально для не программиста.

Со свитчами-то код клиновей выглядит

Дядя Боб всё верно написал! Оптимизация не должна наступать на читаемость, потому что потеря читаемости в дальнейшем приведёт к падению оптимизации. Оптимизацию должны выполнять компиляторы, на уровне asm нет никакого полиморфизма, только jmp.

Вот вроде видос ни о чем, просто про срач двух айтишников, но подача аргументов и примеров делают видео очень интересным. Хорошо преподнес тейки Кейси. Думаю можно было даже побольше показать примеров плохого/хорошего кода. Кароч спс за видос, было очень интересно

@world_system3142

14 күн бұрын

в видео только один аргумент, и это скорость работы кода. Все остальное автор растекаться мыслью по древу.

Посмотрел исходное видео - так и не понял почему это нагромождение мусора из примера Боба называется "чистым кодом"? Что именно он делает, понял лишь по объяснению, которое было в сотню раз короче этого кода - примерно на пару строк английского текста. И с каждой модификацией Кейси код становился только более понятным. Возможно лишь когда он ушел в AVX (он кстати так и не показал код с AVX,) читабельность реально стала страдать - да и то не факт, потому, что он упомянул некую библиотеку AVX...

Те кто пишет на Си, конечно же адепты КейСи и перфекционисты. Код должен летать и на тостере, полностью с ним согласен. А все эти командные проекты не так важны в плане производительности, там для них тестировщики существуют, работает и ладно. "Клир" код типа))

с удовольствием просмотрел видос. Оба, Кейси и Боб имеют хорошие факты. Если первый, показывает что CLEAN CODE бывает что нагружает железо, а второй говорит что оно помагает не железу, а будущим людям которые будут работать в этом проекте, то тут невозможно сказать что всегда надо придерживаться одной методологии, ведь бывает что бизнесу нужна обычный продукт, которые будет работать (неважно быстро или медленно, а главное работало), а есть бизнес которой важен не то как "удобно" читать, а как БЫСТРО оно работает. Я считаю что надо найти баланс, если проект нуждается в производительности, а оптимизировать нечего - надо отказаться от принципов CLEAN, а если скорость неважна - то CLEAN лучше. P.S. ВСЁ ЕЩЁ ЖДУ 10 ЧАСОВОЙ ТУТОРИАЛ ПО С++

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

@YaShoom

14 күн бұрын

Думать о чистоте постоянно тоже напряжно. Особенно если это обязанность, должностная или социально.

@rafk5341

14 күн бұрын

Пишем как нравится, чтобы потом переписывать половину кода

@fnhm_

14 күн бұрын

​@@rafk5341Суть в том, что так называемых бутылочных горлышек в программе не так много. Тот же пример с гитхабом показывает, что не столь важно, как написан тестовый редактор, его производительность приемлема, а вот что нужно оптимизировать, закрыв глаза на клин код, так это менеджер эмоджи. И такой баланс 9 к 1 практически везде

@enchv

14 күн бұрын

⁠@@rafk5341половину кода все равно придется переписать, как не старайся в начале:) а некоторым нравится писать так, что потом приходится переписывать все:))

@TheDzzirtuoz

14 күн бұрын

@@rafk5341 итеративность - всё же более светлая альтернатива, чем полная стагнация в попытке с первого раза сделать правильно

Мой дата сайнз настолько высок, что с первого слова понимаю, что сейчас будет реклама и о чем..

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

ещё новые студии собирают более тяжелые приложения по весу нежели старые

Я считаю это комплиментом хотя многие с мной могут не согласиться, но этот канал это лучший канал о айти и программировании для не программистов. Супер легкий и кайфовый материал с приятной подачей

Странно что код написанный на полиморфизме и на свичах не скомпилируется в примерно одно и тоже на уровне ассемблера

@amir32806

14 күн бұрын

Для полиморфизма всё равно придётся использовать виртуальные функции.

@MaxiRPD

13 күн бұрын

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

У челиков случился классический диалог слепого с глухим.

Все видео думал что Кейси крутой чел, а по итогу клин код побеждает ;D

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

Походу вся современная ААА игровая индустрия сидит на этом clean code. В то время как Дум запускали на всём что даже не являлось компьютером, современные игры на современных консолях в лучшем случае выдадут 30 фпс при нарисованных нейросетями 4к разрешении, а ПК скоро снова вернется в эпоху баек про "апгрейд каждые 2 года". Правда где-то посередине. Например вебу не нужна сильно производительность, там лучше следить за качеством кода, в то время как геймдеву нужна производительность, а не макаки которые чето там потыкали в Unreal Engine 5 и как-то это запустилось. Да и по факту, тот "производительный" код, если его аккуратно писать и грамотно документировать, он будет такой же легкий и доступный в чтении код

@ZDenis777

14 күн бұрын

Думаю что нет там никакого clean code, ведь это в прямом смысле от и до должен быть clean code, а обычно в коде встречается "говно случается" "говно случилось снова" "это не трогать тут магия", это просто нулевые технические знания которые видимо пропагандированы вот этими clean codeрами так как clean code оказалась лицемерной вещью не учитывающей производительность то есть как по мне нарушена сама суть "сделать красиво" но без технических знаний красиво не будет будет "говно случается". вобщем это я к чему тут либо ИИ будет писать быстрый код, либо ЯП подтянутся, так как вина за красивый но медленный код на них тоже лежит, нужно чтобы можно было писать все эти красивые конструкции а производительность была всегда на уровне некрасивых но оптимизированных, хых

@EdwardNorthwind

14 күн бұрын

как по мне, производительность нужна всем программам. Очень бесит, когда тот же Офис, не имя толком различий с версией 2003 стал весить в 10 раз больше и работать в 5 раз медленней. Всё это весит в памяти, жрет ОЗУ, процессорное время, а потом у тебя комп лагает просто потому что "и так сойдет"...

@user-zn7uu6xq4h

14 күн бұрын

геймдев - как раз та область, куда "clean code" пробрался в меньшей степени.

@ExaltedHermit

13 күн бұрын

@@EdwardNorthwind Что "нужно" решает рынок. Да, любая программа выигрывает от повышения производительности, но если программой пользуется миллиард низкооплачиваемых леммингов, да и то не каждый день, то могут и подождать 7 секунд на загрузке. Реально видел учетную программу, где заставка с логотипом висит 10 секунд не потому, что там что-то грузится, а потому что если паузу убрать база иногда не стартует. Видимо была непонятная проблема с коннектом к бд и её решили вставкой sleep(10). А че, дешево и клиент теряет 10 секунд всего лишь раз в день при запуске.

@jamboska5700

12 күн бұрын

напомню тебе что старый дум и современные игры это разного масштаба программы.

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

@user-el2xc2su4s

Күн бұрын

А если сразу писать нормально, то особо и оптимизировать не придётся. При меньшем размере и сроках.

а ведь мы по факту живем в мине где VS запускается хрен знает сколько где хром отжирает непонятные Гб и про андроди студио я молчу - это все последствия учения Мартина

Сначала программирование, а как стало бизнесом - клин код)

На самом деле, эта ваша "понятность кода" зависит от опыта. Чем больше у программиста опыта, и чем больше он знает всяких разных алгоритмов/паттернов/идиом, тем большая часть кода ему понятна. Соответственно, популярность чистого кода (и вообще актуальность) объясняется в основном тем, что в нулевые индустрия переживала взрывной рост. Нужно было понабрать очень много людей с улицы, которые лишь вчера осознали себя программистами. Никогда ранее такого роста в индустрии не было. Поэтому практика чистого кода показалась всем спасением. И никода более такого роста уже не повторится. Поскольку быстро расти в разы легко только с нуля. Так что чистый код плавно будет утрачивать свои позиции, уступая место более важным вещам. Уже сам факт того, что уважаемые господа схлестнулись публично, говорит о том, что позиции чистого кода ослабли настолько, что по ним можно попытаться нанести удар, не боясь оказаться посмешищем.

Как раз вчера читать начал эту книгу :)

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

Вы неправильно солид понимаете. OCP к наследованию никакого отношения не имеет.

Если избавиться от clean code, интерпретаторов и перейти на ассемблер, то выигрыш по скорости может возрасти не в десятки, а сотни раз.

@user-mr9tw6rj9i

10 күн бұрын

Компилируемые языки не менее высокоуровневые чем транслируемые

@OlegMasters

5 күн бұрын

Почему вы говорите о том чего нет в видео? В видео про Clean Code и архитектуры приложения, а не про языки программирования.

@user-mr9tw6rj9i

Күн бұрын

@@OlegMasters Архитектура строится от ЯП

@OlegMasters

Күн бұрын

@@user-mr9tw6rj9i нет. Архитектура отдельно, а язык программирования отдельно. В любом языке можно применить различную архитектуру.

Свитчи вообще капец какие быстрые. Крч вывод - не бросаться в крайности 😅

Бро объяснил солид за 2 минуты😂🙏