Инцидент, Который Создал Шум Во Всей IT Сфере
Привет!
Научись создавать нейросети:
go.skillfactory.ru/windertont...
Скидка 50% по промокоду TONKA
+курс по софт скилам в подарок
Бесплатный IT-рентген: go.skillfactory.ru/itwndtn
Если понравилось, то тебе сюда 100% - t.me/wndtn
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Упомянутое в видео:
- Clean Code: horrible performance - • "Clean" Code, Horrible...
- Clean code: Summary - gist.github.com/wojteklu/73c6...
- Общение Кейси И боба: github.com/unclebob/cmuratori...
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Подпишись сюда:
Telega и чатик - t.me/wndtn
Github проекта(код с канала) - github.com/winderton
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Музыка:
SLYNK из фри библиотеки ютюба
00:00 Введение
01:10 Начало "конца"
02:01 Особенности чистого кода
04:25 Бонуска
05:23 Инцидент, который изменил вектор IT
08:20 Король пришел на защиту, но провалился
11:40 Нас с Вами просят решить судьбу ситуации
Нас с вами попросили решить, кто тут прав: Кто и что думает в итоге?
кейси чисто базы навалил, зачем нам читабельный, но медленный код?
Пусть я и не сильный аналитик и не глубоко знаком со структурой вне clean code - но я никогда не задумывался от этом, и теперь я пересмотрю подход к использованию solid и dry, спасибо за ролик.
в итоге как будто все такое позорно медленное из-за денег, внезапно. Опять виноват капитализм :)
Я как адепт чистого Си - за Кейси.
Как и всегда однозначного ответа нет. Под каждую ситуацию нужно просто выбирать наиболее подходящий вариант.
Как говорится "На ассемблере можно написать всё что угодно. Но жизнь коротка."
Языки программирования и были придуманы для удобства и скорости написания программ, а так же, точнее наверно даже в первую очередь для удобства и простоты,чтениятекста программ человеком, внесения корректировок и дополнений . Но что то пошло не так. В итоге- один хрен очень мало кто может читать чужой код, особенно без комментов, но при этом код тормозит по сравнению с тем если бы писали на ассемблере.😢
Видимо в следующей жизни =)
@@user-xi6xo9cu7bспорное заявление про читать чужой код. Если ты опытный ты и всю лапшу индусского кода разберёшь. Мне лично помогло книги по рефакторингу
@@user-xi6xo9cu7bПойдет так, когда каждый сможет написать язык программирования чисто для себя. Под свое понимание реальности, скорости разработки, эффективности. Невозможно создать универсальный интерпретатор, без ИИ
На ассемблере пишут некоторые вставки в c c++ коде, если нужна производительность то будешь писать что даст результат
Раньше я думал, что пишу нечитаемый говнокод. Теперь узнал, что я оптимизирую циклы процессора.
Ахахха))) Новая мета на говнокод грядет?)) Я скоро смогу считать себя программистом?))
Наконец-то выход начинающих геймдеверов...
Эт не так работает)
Скорее ты пишешь плохо читаемый и по прежнему медленный код 😅
@@r-morozov жиза
Был в моей жизни период, когда я одновременно работал над разными проектами. Первый - Backend на Java Spring в команде, второй - прошивка для STM32 (микроконтроллер) на С++ в соло. Мои коллеги (Java разработчики) активно призывали использовать принципы Clean Code и старались обсуждать и доносить идеи до остальных. Тогда я и начал в это активно погружаться. Многие идеи я пытался использовать и в своем проекте на C++. Однако тут мне пришлось осознанно нарушать многие правила, поскольку производительность микроконтроллеров слишком ограниченная, и многое приходилось писать "в лоб", избегая сложных абстракций и т.п. Уже тогда я для себя понял, что важно мыслить гораздо шире, и отталкиваться в первую очередь от целей, а не применять правила ради применения правил. Просто думайте и совершенствуйтесь!!!
Согласен с тобой на 100%
Контекст > Метод
фокус том, что чистый код - первый уровень, а оптимизация его - второй. Итого - пишем все чистым кодом, а потом оптимизируем и при сопровождении. Всегда два этапа. А самое главное - есть нулевой уровень - правильно заданные алгоритмы, в идеале с нулевой задержкой на побочные вычисления. Иначе непонятно к чему стремиться. Можем получить, что при конечной оптимизации без верхних уровней забудем, ради чего это все и что теряем
C++ Variadic Templates :)
На МК надо писать на Си и не выпендриваться.
Программисты когда 10 уровней абстракции лагают: 🤯
Лагают ещё ладно, гораздо хуже когда приходится искать баги в этой кунсткамере...
@@che42cc я посмотрю на тебя если ты будешь искать баги в коде без DRY, где будет миллион расходящихся модификаций
Да хоть 100 Оно в любом случае транслируется в машинный код
@@krevetka4933 В любом случае вызов функции это инструкция процессора, поэтому все абстракции занимают время.
@@che42cc а начинаешь углубляться и понимаешь, что ничего не лагает, просто абстракций так дохуя, что итоговое время огромное, ну то есть лаг. И ты чешешь репу, а как теперь убрать лаг, если для этого надо переписать половину кода и как это переписать, если в принципе написано согласно правилам.
Читал на каком-то форуме пост от чувака, у которого горело от размера приложений на телефон. Что, мол, банковские клиенты весят ~500МБ, в то время как гта 3 (или SA, не помню уже) тоже весила что-то около 500. И, говорит, "сбер, где мой открытый мир в твоем приложении?)" И в комментах люди расписали ему, что пофигу компаниям на размеры приложений сейчас, у телефонов есть ресурсы, так что можно забить и важна лишь скорость написания и выкатывания фич Это я к тому, что бизнесу скорее важна производительность программиста, нежели железа
То же самое про ОС. Винда 7 - 500 МБ, современный андроид - 7-10 ГБ, отжирающий больше половины встроенной памяти
Именно так… Софт ложитек для обновления драйвера мышки - 286 мегабайт "Дальнобойщики 2" - 270 мб 😅
@@TheDzzirtuoz Nadroid LinageOS вдохнул вторую жизнь старому планшету Samsung Galaxy Tab 3 с 1Gb памяти, откудава 10гб андроиды ? )
Я смотрел видос с разбором кода гта 3, там было много свич кейсов)
Вопросы к фронтендерам
"Да, да, производительность важна", покивали головой мы, и пошли заворачивать свои серверки в докер
😂
Которые еще на docker desktop👍🏼
И писать пародию на микросервисную архитектуру где на каждый пук Http запрос😂
@@Milk-gw1zl во во. в вебе где на каждый чих или запрос в базу или вызов апи, все эти "замены полиморфизма на свитч" как экономия на спичках выглядит.
Docker, на самом деле, не даёт никакого дополнительного пенальти производительности. Ну, может, кроме самого демона докера. Тогда возьмите Podman. Всё, что "завёрнуто" в Docker, по сути точно такие же процессы в ОС, мы тут не будем рассматривать, если докер под мастдай в виртуальной машине. Используются всё те же системные вызовы, что и без использования докер.
У меня есть подозрение, что монструозный и тормозящий софт под капотом совсем не clean.
Ну тут сурсы надо смотреть, иначе не скажешь...
имя опыт работы на по настоящему дерьмово написанных проектах, могу уверенно заявить, что я ни разу не видел чтобы "следование клин коду" вызывало проблемы с перфомансом, обычно совсем наоборот
@@roman7956 кто мы, а кто авторы фундаментальных противоборствующих концепций программирования...
@@roman7956 Так и за перфомансом не гнались))
Поддерживаю что проекты с нормальной архитектурой работают лучше. Легче бьются на микросервисы, легче расширяются. А мест где бы нужна хорошая оптимизация очень мало и жертвование читаемостью там допустимо. Но обычно проекты без клин кода это монструозный кусок мусора с имиджем на 30 гигов который писался с идеей «нет времени думать нужно делать». И их улучшение требует такую прорву часов что никто этого не делает.
Если упарываться в удобство программиста, то платим производительностью. Если упарываться в оптимизацию, то платим временем разработки. Наверное лучше искать баланс...
Баланс для каждого субьективен
Именно поэтому я пишу на c++ со вставочными конструкциями asm
@@payrgames поэтому и пишут по-разному
@@FXGO807_7 типо ты лучше компилятора оптимизируешь?
нейронки все разрулят рано или поздно, выдадут каждому желающему х20 производительность (если не всем задачам, то всех уровня мидла), ну а читаемость кода уже не будет важна т.к. проги будут писаться уже не человеком (ну, постепенно вытесняя человека, окей?) из за того что стоимость нейронки будет стоить около 10 центов за написание, а тот же программист мидл будет это же делать за зп в тысячу $. И да, это не я выдумал, так говорит Сэм Олтман, их цель на ближайшие годы это снизить стоимость интеллектуальной работы к 0$
Я когда смотрел оригинальное видео то не мог понять: он то ли троллит, то ли серьёзно. Дональд Кнут когда-то сказал: "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да
Буддист решил помытся и утонул... В желтой воде..
Это вы, батенька, спорите с соломенным чучелом. Где у Кейси было сказано, что трудозатраты на оптимизацию кода окупаются всегда? Он говорит совсем другое: не всегда clean code важен любой ценой, нужно знать его издержки и понимать, когда необходимо от него отступить. И есть масса случаев, когда это случается на практике. Даже тот код, который не выполняется миллионы раз внутри какого-нибудь цикла, бывает нужно оптимизировать, если он сам вызывается миллионы раз в секунду. Я на своей практике сталкивался с такими ситуациями, когда уже не было смысла в программе оптимизировать узкие места, поскольку каждая строчка программы примерно в равной степени тормозила систему до неприемлемого по техзаданию уровня. И я сталкивался в своей работе с тоже-программистами, которые сначала цитировали Кнута про "преждевременную оптимизацию", а потом спустя некоторое время и вполне предсказуемо бегали кругами и кричали, почему продакшен нестерпимо тормозит и что надо срочно что-то с этим делать, желательно вчера. Полагаю, вы так же не сталкивались с проблемами производительности таких вещей как высокочастотный трейдинг и различных OLTP-подобных приложений, а это весьма обширная область. Так что говорить, где лежит большинство проблем, несколько самонадеянно.
> почему при наличии современных мощных профилировщиков никто в индустрии не говорит о тормозящем полиморфизме, а говорят в основном о других проблемах в производительности (память, кэш, i/o)? Потому что новое железо достаточно купить, а новые знания нужно майнить?
Чота я не понел. Чувак доказал, что если убрать vtable и прочие плюшки, написать код, специализированный для данной операции, то он будет быстрее? Ну да, будет, а чего такого-тооооо? Иногда мы именно так и делаем на микроконтроллерах, если нужно прям очень ужаться по производительности или памяти или чтоб выдерживать тайминги до тактов. Но в абсолютном большинстве программ это не требуется. Но есть один нюанс. Очень трудно написать в таком стиле большую программу. Поэтому нужно знать что, когда и в каких случаях применять. Ваш капитан Кэп.
ну вы так в своих рассуждениях вообще можете дойти до идеи что "серебрянной пули нет" и "головой нужно думать что и зачем ты делаешь", а холиварить тогда как????
@@roman7956 да, что это я в самом-то деле. Ну ок, погнали: иногда, в редких случаях, в C можно использовать goto. У меня был кейс, когда буквально пришлось основной цикл программы (на микроконтроллере, оф коз) построить на goto. Там почти вообще не вызывались функции, ибо это дорого по времени.
Кто мы? 2.5 человека и один из них инвалид на голову раз это не понимает.
@@drgluck07 Код с goto нужен, если в конце функции есть finalize-секция, в которую надо переходить в случае ошибок. Сам я такой код не писал (потому что прогаю на C++, где есть RAII), но в весьма известных программах на C видел, и это замечательно читалось и не вызывало никаких вопросов.
Не трудно. А реально. Просто изначально надо не заморачиваться в лищние удобства и с опытом придет скорость.
Вообще-то все зависит от конкретной задачи. Если мы видим, что какой-то кусок кода выполняется раз в 2 часа и его выполнение занимает не 100 наносекунд, а 250 (из-за чистого кода), то ускорять нам ничего и не надо. Он прозрачен и в нем нет ошибок. Если же код выполняется каждые 500мс*100000 раз, то тут уже не до красоты. Фигачим отдельный класс FastMaker в котором будут и свитчи и использование всяких AVX инструкций и вычисление на GPU и asm вставки. Байто*бить это тоже плохо, как и медленный красивый код. Для тех кто не согласен: код который мы пишем был изобретен для упрощения создания машинных кодов. При любом раскладе событий в машинном коде можно добиться лучшей производительности. Это ведь не повод отказаться от языков программирования?
А на фига тебе вообще класс фигачить,может просто макросами там чисто сишным или плюсовым ?
база
@@tohoto2183 чтобы наш быстрый код на свитчах стал черным ящиком для классов, которые будут его использовать на более высоком уровне. А ещё лучше быстрый код делать отдельной библиотекой, чтобы другие разработчики прикладного уровня не тратили время на реализацию того же самого, а красиво его использовали в своем проекте.
Посыл в том, что никто ничего не оптимизирует, все ждут что железо станет лучше.
Правда в словах есть. Иной раз, можно позволить выполняться коду долго.
По моему в какой то книге кента бека была фраза что код сперва должен просто работать, на следующем шаге можно сделать так чтобы он был написан красиво, и в конце чтобы он работал быстро. дядя боб говорить как писать кода на втором этапе, а кейси - на третьем =)
Не подходит , в клин коде не про красиво вообще ,там свой стиль просто у аппонента другой стиль,когда большая программа пиши как хочешь ,все равно заблудишься. Клин код -это про навязывание своих строгих правил написания и не более того,следуя им все-таки легче понимать ,но сомнительно ,что это работает в больших прогах.
Код сначала должен работать, а потом - работать ПРАВИЛЬНО
@@user-el2xc2su4s "должен работать" это и имелось ввиду правильно, он должен делать то, ради чего был написан
@@roman7956 да-да, особенно если постановка задачи написана как курица лапой и внутренне самопротиворечива.
Что любопытно - очень многие воспринимают этот спор так, словно сторонники "чистого кода" топят против производительности, а сторонники производительности топят за говнокод(лишь бы он был быстрым). Но это, на мой взгляд, совсем не так. С высоты своего опыта коммерческой разработки(~25 лет) лишь подметить, что подавляющему большинству коммерческого кода даже до "чистого кода" - как до Китая пешком. А код не должен быть "чистым или быстрым", он должен быть "чистым И быстрым". Но, пока платит бизнес, вряд ли так будет на массовом уровне.
Ото ж. Люди, которые говорят, что Clean Code - фигня, хотят писать еще более медленный говнокод. Для того, чтобы писать оптимально, надо научиться писать ЧИСТО для начала. Я буквально вчера в ревью заставил джуна вынести одну и ту же функцию, которую он создал в каждом месте, где она была нужна - около 20 повторений. Сомневаюсь, что это ускоряло производительность. Он просто быдлокодит.
Когда сроки проекта горят, уже не до чистоты кода и не до производительности. Заказчик этого все равно не оценит, а дорабатывать уже можно и потом за отдельную плату. А если со сроками проблем нет то, конечно - "чисто И быстро".
Все так - код одновременно И должен быть производительным, И не должен быть говнокодом. Но для этого в голове должны быть мозги - а вот с этим сейчас огромнейший дефицит.
@@ValkRover это отмазка. Если навыки есть, быдлокода не будет.
@@rkurbatov Да, знаю я! Не умею плохо, это и беда!
Как по мне тут всё довольно просто: программисты стараются писать чистый код, а там где не хватает производительности, оптимизируют как лучше
Фу, скушный практичный центрист! А как же развести многолетний срач и написать десятки книжек?)
Ну как бы разница в 15-20раз это провалл клинкода. У нас процессоры не стали на столько быстрее с 2007 года. Там хорошо если они стали быстрее раза в 3. Чего реально стало больше это ядер и памяти. Но это не сильно решает проблемму быстродействия. Ядра помогают многозадачности а не ускорению конкретного процесса. Да теперь мы можем и браузер запустить и игру и стрим если количество ядер и памяти позволяет. Но если процесс не оптемезирован то тут уже никакие ядра не спасут.
@@vsevolodkuleshov8551 нет. Это - провал постановки задачи. то есть - руководителя проекта
Что не верится в это. Игровая индустрия тому пример
@@vsevolodkuleshov8551ну это не разницы в 15-20 раз, а в несколько десятков цикла процессора. Когда с бд загрузка идет секунду, все другое не очень играет роль
А потом в телефоне приложение с напоминалкой сжирает 500МБ памяти и батарею сажает :) Утрирую, конечно, но так и есть.
А потом у нас и приложений нет в маркетах ещё))) Да у нас везде проблемы!
Говоря про быстрый код, многие представляют какой-то нечитабельный ужас с указателями на указатели, инлайн ассмебли и кучей симд, хотя зачастую все, что надо для +- производительного кода, это: - грамотное использование фич/языка (зарезервировать место для вектора и скопом добавить объекты, а не резервировать для каждого элемента) - маломальское знание алгоритмов/динамического программирования (сохранить результаты вычислений, чтобы ускорить последующие, не использовать 4 вложенных цикла там, где можно обойтись двумя) И даже так, как по мне, комфорт программистов не стоит того, чтобы у конечного пользователя 30 секунд грузился ГУИ из-за 10 слоев абстракций
Ну правды ради, в каких-то графических решениях, быстрый код это по факту нечитабельный ужас с указателями на указатели, инлайн ассембли и бешенными алгоритмами)
@@user-pd9du9on6s Далеко ходить не нужно, достаточно прикоснутся к DirectX.
@@user-pd9du9on6s вообще да, но тем, кто крутится в таких сферах где производительность очень сильно важна, скорее всего в кайф реализовывать сложные и нечитабельные алгоритмы и выжимать из железа максимум самым малоизвестным методом)
SIMD очень прост и переносим, если ты согласен писать на гнутом диалекте. typedef float vec4 __attribute__((vector_size(4*sizeof(float)))) и пиши
Хорошо смотреть на Xorg и отвечать на вопрос, почему появился Wayland
Странная дискусия. Мне помнится что даже в книге есть сноска, что упарываться не нужно и можно отступать от правил
Иногда - даже нужно.
прав ты, Винд. всем нужны только деньги. и каждый их фармит по своему: кто-то пишет и продвигает свои умные книги, кто-то антихайпит по поводу этих книг, а кто-то хайпит на антихайпе, попутно присовывая подписчикам скильную фактори. а подписчики, хавая весь этот попкорн и чувствуя свою квазипричастность ко всему этому чудесному миру, фармят свои рисовые гроши, гонясь за морковкой, перед их носом... так устроен этот вондерфул ворлд... хеллоу, фускинг ворлд...
Самое важное, что из этого можно сделать выводы, а не слепо следовать чему-то.
Правды ради тот кто хайпит на антихайпе кратко пересказал всё из-за чего был устроен шум
Этот комментарий - большая жирная точка во всём этом споре. Остальное - просто спинофф ради статистики)
Лучший комент) А что еще ожидать: Среди панелек, хрущёвок и деревянных изб По нам палит шрапнелью капитализм 25/17
Да, деньги есть мерило всего в нашем мире, и не важно как их доставать). И всё равно нам на экологию, разрушительные войны...зато столько денег выручают за каждую единицу боевой техники!) одна польза) Живи, пока ты ещё выгоден своему работодателю; диши гразным воздухом за то что экологическое производство устанавливать дорого; лечись в помойке, потому что больница не бесплатная; смотри как миллионы нищих умирают на улицах и живет Африка, пока "крутые" блогеры жируют; вспоминай как расстреливают парламент из танков, как буквально забирают твоих родных на войну прямо в пекло. А если ты не согласен, то ты же "против государства! демократии! украинский иноагент сатанинского гейропейского запада!", тогда берешь красный флаг в руки и вперед за демократию, прямо на баррикады против омона с дубинками, чтобы люди начали жить, а не доживать зарплату
Тотал коммандер, новороченный по самое нехочу файл менеджер, с огромной библиотекой расширямый плагинов, занимает всего несколько мегабайт. Простое приложение ютуб на телефон, с мимимуи функций , жрет больше гигабайта. Что то определенно пошло не так в мире программироваания за эти годы )
Читал я чистый код. Принимать без фанатизма. Во главе всегда дожен быть здравый смысл
маэстро, я вас узнал в гриме😉
@@manOfPlanetEarth убил просто 🤣
@@ralymbetov 🤣
Именно так и есть. Но люди религиозны - именно от отсутствия смысла в голове.
"Принимать без фанатизма." - хорошая фраза, если у тебя есть административные полномочия и нужно косвенно сказать "правильно - это именно не так, как сделал ты".
Проблема не в том чего хочет знать или не знать программист. Если отказаться от непроизводительного чистого кода, то бизнесу придется нанимать Senior и Middle там, где хватило бы одного middle и пачки студентов. А бизнес такого не хочет, сервера докупить дешевле...
Один человек, из толпы просто написал как есть, Спасибо
нет на рынке столько Senior и Middle, чтобы покрыть задачи бизнеса сейчас их и сейчас-то нет, а если упарываться в производительность, то и подавно не будет
с каких пор студенты пишут чистый код ?
@@Firegalensk бизнес занимается пилежом бабла и погоней за свистопирделками тиктокерскими, поэтому программистов и не хватает :)) маркетологи шарлатаны накалывают владельцев бизнеса
Самое лучшее объяснение SOLID из возможных!!! 90 секунд суперпонятной базы, я в шоке. Респектище ❤
Это конечно все очень круто и интерестно, но когда плюсы за 10 часов?
а че не за час? И после сразу отклик на сеньора плюсов.
Так гайд на сами плюсы, вдобавок, его надо учить, а не посмотрел=понял. Все остальное прилагаемое и можно учить, делая свой проект, к примеру.
После войны пчёл
@@aririi6016человек культуры
@@aririi6016 слишком сырно
7:16 Скорее всего, "чистый код" сделан для того, чтобы люди поняли, как писать *ПОНЯТНЫЙ*, а не компактный код. А еще, всем новичкам было бы неплохо прочитать эту книгу
На самом деле спор ни о чем. Там где нужна производительность - пишут производительный код, но в современном мире большинство программ работают с I/O нагрузками, и плевать сколько тактов процессора тратит программа, если потом сидит и ждет ответ от сервера/базы данных/чтения файла/действия пользователя и кучи чего еще.
Хорошо, что человек из комментариев пришел и развалил двух гениев и их спор, а то сцепились ни о чем
Для бекенда производительность очень важна, которая напрямую влияет на расходы кол-ва серверов и их поддержку и кол-во пользователей которые смогут использовать один сервер в локации. Для любого софта который работает с графикой и большими вычислениями, перечислять можно долго.
@@fein7068 да, интересно какая там производительность у Бэка на джаваскрипте или питоне) С графикой согласен, но там и используют производительный код, я ж пишу, где что надо, там то и используют.
как хорошо жить в мире, в котором задержки не суммируются, а накладываются :D
@@fein7068 хочу глянуть на этот производительный бекенд на джаваскрипте или питоне) А для графики и математики, да производительность нужна, но я об этом и говорю, где надо, там пишут производительный код, где не надо - лучше писать чистый)
Эм... самое смешное что они оба правы так как говорят о разных вещах. Кейси рассуждает о написании, скажем так, mature продукта, настоящего, ну типа ngnix или sqlite - это идеальные инструменты, которые на любом вейпере вытягивают 100К запросов. Ну или тот же Doom Кармака или OTP Elexir-а - вот такие вещи. А дядя Боб - про сляпывание прототипов, которые вместо того, чтобы выкинуть - раз-раз и в продакшен. ИМХО - 98% всего созданного и работающего софта - это чертовы прототипы, которые еще и постоянно допиливаются, потому что заказчик некомпетентен и не в состоянии видеть вообще, какой уж тут нос. И вот эти прототипы хоть как-то поддерживать в живом состоянии можно только со всеми этими клинкодными делами. Потому что иначе никто и трехметровой палкой не будет трогать оставленное предыдущим программистом. Особенно учитывая, что не все они Линусы и Кармаки. Так что клинкод - реальность галер и кровавого энтерпрайза. А создание настоящих продуктов - удел упоротых одиночек. Чёт типа того.
так, что-то я не понял: прототипы пишутся с использованием клин код, а зрелый продукт типа nginx, который пишут упоротые одиночки, - у него какая история?
@@manOfPlanetEarth nginx буквально писался одним человеком в свободное от работы время, в какое то время разраб уволился с работы, чтобы посвятить фуллтайм своему детищу. После чего галера(Имя ей Rambler), пытались отжать права на nginx.
продукт типа Doom 2016 написан не одиночками, но и с перфомансом там всё по красоте.
Наш Сеньер на старой работе всегда твердил сердито, что Чистый Код это хуита и инфоцыганство, все над ним посмеивались, мол бумер опять раскряхтелся, а тут вон оно как...
"свичи и виртуальный функции реализованы одинаково в компиляторе" 😂
я хочу выбросить его книгу в окно, как это можно было пердануть
Ну, 25 лет назад почти наверняка так и было. В каждом объекте - указатель на таблицу виртуальных функций. Вызов функции - по адресу, который берется в этом массиве. свич, почти наверняка, организовывался так же, только указатель на аналогичную таблицу - статический. Это если компилятор умел немного оптимизировать и аргумент свича - небольшое число, в противном случае - куча if-ов. Правда, подозреваю, с тех пор много воды утекло.
Я ещё помню те времена, когда говорил, что преждевременная оптимизация -- источник всех бед :) Все эти микрооптимизации хороши до первого сетевого запроса или неоптимальный выборки из базы, которые съедят всё, что вы наоптимизировали
Полная цитата говорит именно об этом: "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%."
@@SergeyGlotov и потом мы получаем игры, которые по графике хуже игр 2000 но требуют 4090. Да хули заморачиваться писать оптимизированный код, если можно быстро тяп ляп хуяк и в продакшн. Правда в том, что писать оптимизированный код не сложно и не долго, но приходит с опытом. Ты просто уже на автомате знаешь какие конструкции и алгоритмы быстрые и сразу их пишешь. Программирование с опытом становится стенографией, где ты пишешь код на автомате. Твоя цитата человека, которому похуй на код и его производительность. Ему надо нанять джунов, которые за два рубля напишут любой работающий код и он сможет продать это за сотни рублей.
@@sir.Geronisтормозные игры - плохой пример, потому что геймдев - это одно из исключений из правила о преждевременной оптимизации, т.к. о скорости работы нужно заботиться на всём процессе разработки. Ну а появляются такие тормозные игрули из-за того, что даже те самые 3% из цитаты не подвергаются анализу производительности, и лепится всё "как есть". С таким подходом писали тормозное г-но и без всякого клин кода.
@@0imax игры эьто очень хороший пример. Но если тебе не нравится. То давай возьмем офисные приложения. Которые весят десяток ГБ, требуют не один ГБ памяти, только для запуска, а для полноценной работы требуются еще несколько ГБ. И в тоже время есть альтернативные офисные решения где в десятки раз меньше ресурсов требуется. А мобильные приложения, калькулятор 120МБ. Банковское приложение 500МБ. И тп. Таких примеров милион. Просто надо открыть глаза и прекратить сыпать в них соль. А игры это просто самый наглядный пример, где слово оптимизация потом взята за аксиому.
А знаешь, из-за чего появляется по-настоящему фиговая производительность в больших проектах? Из-за того что один программист наоптимизировал всё, влепил внутри одной функции, а другой вызвал эту оптимизированную под 1 задачу функцию в немного другой задаче, где половина этих операций совсем не нужна. От того, что люди пишут не очень чистый код, другие просто их не понимают полностью и ломают производительность ещё больше, чем если бы код был чистым.
Для бизнес логики в нетребовательных приложениях - чистый код. Для системного программирования и огромных, сложных софтин типа игровых движков - максимальная производительность. От чистого кода там будет мало потому-что ничего не поделать. И то и то используется и практикуется.
ммм, то-то я смотрю игры у нас пиздец какие производительные, не лагают никогда и у всех все идет в +100500 фпс в разрешение 16к, ага. А если серьезно, то у нас два главных движка это Анриал и Юнити и оба используют ООП.
@@dmitriyivanich1088 не играй во всякое говно просто)
@@dmitriyivanich1088не знаю как анрил, но в юнити конечно такое ооп царское, просто залюбуешься. Весь апи это статика в статике под статикой и статикой погоняет. Ах, ну да, там же наследование есть от MonoBehavior и полиморфизм на Update() и некоторые другие ивенты, ну это, конечно, да, всё меняет )
@@dmitriyivanich1088 И в обоих лютый говокод и никакого CleanCod-а, тонны багов и отсутствие хорошей производительности. И таких проектов большинство, компании даже могут и не знать об этом, спасибо техлидам и менеджерам, т.е где как повезёт)
@@dmitriyivanich1088 Вспоминаю, как в конце 90х - начале 2000х играл в анрил турнамент (ещё тот, первый) на первом пне на 150 мегагерцах и 16 мегабайтах оперы, и первой вуду 3дфх. Сейчас гигагерцы и гигабайты, это вроде в дохера раз больше, а всё что по сути изменилось - текстуры покрасивше да полигонов побольше. Как-то не пропорционально
Клинкод дает одну особенность, которую не дает подход кейси: расширяемость На примере фигур он переделал классы в енамы и свитчи. Но если у тебя система плагинов, ты не воткнешься в енам, а свитчи сами не расширятся. Здесь нужен именно полиморфизм. Надо брать лучшее от этого и не застревать на одном месте. Если ты будешь тупить 10 минут над ускорением горячего кода - ок, если день над холодным - не ок.
Удивительно как мало людей понимают этот, в целом довольно тривиальный, факт...
Помню 2000-е, когда ООП-код на С++ руинил весь перформенс на процессорах с длинным конвейером от Texas Instruments. В то время как плохо-читаемый код на Си, написанный с учетом архитектуры, летал.
в 2020ых 90% оптимизаций под конкретные процессоры применяется автоматически)
С производительностью ****** везде, один веб чего только стоит с зоопарком фреймворков, смотришь профилирование и ужасаешься всему тому *****, что вылетает там
По моему личному мнению, ты можешь использовать фреймворк в том случае, если у тебя достаточно навыков написать такой же если у тебя будет достаточно времени
@@BIackFox11ничего себе, так, получается, все возвращаемся на plain js и jquery?
@@MrrrMrrrMrrr а может ну нахер этот JS, а? WebAssembly!
@@MrrrMrrrMrrr таки звучит как прекрасная идея! Может перестанем прелоадер загружать, используя скрипт на 0.5мб.
В чем проблема писать места не требующие производительности с использованием clean code, но если требуется, то оптимизировать только определенные места.
Нет проблем, все так и делают.
возможно, code style будет разный
@@CilezSayles смысл этого говноспора двух "титанов" я не уоловил
Эм... Я типо программист. Даже дипломную скоро сдаю. Вопрос: почему я об этом узнаю только сейчас? У нас в колледже даже по ООП прошлись мимолетом. Посоветуйте курсы по программированию. Есть что то по типу CS50?
@@adori.eterno программист))
Писк про производительность - это голос тех, кто делал только малые проекты, кого не волнуют ошибки, а бюджет его не ограничен. Повышать производительность нужно средствами архитектуры и техническими. Мы разрабатываем систему, ускоряющую выполнение скриптовых языков в 10-20 раз, что убивает писклявые аргументы.
Так вот почему броузер жрет гигабайты. или нет?
Пожалуй, даже не сам браузер. Достаточно посмотреть на диспетчер Хрома, чтобы увидеть страницы с потреблением памяти от 100 до 400 Мб (каждая). И добавить к этому client-side rendering всяких фронтов на модных фреймворках - и здравствуйте! - проц фоном потихоньку "что-то майнит", пока грузит страницу ютуба Например, Notion складывает в куки браузера по 4 гигабайта в фоновом режиме…
он жрет гигабайты, потому что ты открыл сотню вкладок)
ну вообще, оптимизация поскорости != оптимизации по используемой РАМ. вполне себе что быстрый код, может кушац больше оперативы чем медленный, но это не точно.
Именно так. Просто посмотри размеры и потребность в ресурсах компьютера MS Office 97, 2007 и самый последний. А по функционалу разница не велика. Причем большинству и функционала самой старой версии предостаточно.
И в том числе, но не только. Сами по себе страницы в интернете стали весить больше, больше медиа, больше скриптов и тп.
Изобретение правил ради только лишь их соблюдения, а не решения конкретной проблемы - это один из главных признаков "погромиста". И главное отличие "погромиста" от "программиста".
Одна из самых грамотных мыслей в комментариях, и как обычно, в самом низу по количеству "лайков". Людям часто не нужно "решение проблемы", им нужно подтверждение своей правоты. Причём это справедливо как для поставщика услуг, так и для потребителя.
Правила эти появились не на ровном месте, и не для слепого их соблюдения. Если писать большой софт, намеренно игнорируя все практики клин кода, получится абсолютно неподдерживаемое нечто, где внесение мизерных изменений будет стоить несоизмеримо много человеко-часов.
@@0imax Эти "правила" являются набором догматов, не подкрепленных ничем, кроме субъективных впечатлений и _личного_ опыта. По сути, это религия, то есть полная противоположность научному подходу. Какой-то персонаж решил, что функция не должна быть длиннее 20 строк, к примеру. Или что цикломатическая сложность должна быть не более чем сколько-то там. И всё, толпа овец побежала исполнять. Потому что это же великий (Подставить имя тут) так сказал, посмотрите, он миллиард заработал в 20 лет, плохого не посоветует. Даже и не думая, зачем и почему, ради мнимой простоты чтения и поддержки. Даже не задумываясь о том, что десять функций отладить сложнее, чем одну, просто потому что человеческий мозг - не стековая машина, и он не приспособлен к хранению контекстов. А ведь мы программу пишем, а не духов вызываем. Это самый простой пример.
@@0imax С остальными "правилами" точно так же. Ни одно из них не является непротиворечивым, работающим независимо от иных условий. Практически любое из них легко довести до маразма, написав код, который будет идеально соответствовать всем этим указаниям, но при этом будет невероятно усложненным и совершенно неподдерживаемым. Если бы эти "правила" были чем-то научно обоснованным, а не набором догматов, то их невозможно было бы довести до подобных предельных случаев. К примеру, возьмем наследование. Вы можете сказать, что это всё придирки, что нужно ограничить количество уровней абстракции разумной глубиной и все возрадуются. Скажем, 3 уровня. На что вам пять программистов скажет, что должно быть четыре или два. Ещё пять скажут, что наследования быть вообще не должно и нужны лишь интерфейсы. А потом подойдет школьник и заявит, что классический полиморфизм вообще не нужен, что это ерунда для старых пердунов, а примеси - это истинный путь в следующий век. И никто из них не сможет предоставить четкие и формализованные, фальсифицируемые критерии, почему именно _ОН_ прав. Которые у всех сойдутся, и с которыми все придут к одному и тому же выводу. Потому что субъективная херня всё это. Конструкт в голове, способ самовыразиться и собрать бабла с тех, кто готов покупать книжки с этой писаниной.
@@alexanderd.7818 Аксиома Эскобара говорит, что любые крайности - плохи. Не нужно воспринимать книгу как абсолютную истину, и не будет ни проблем, ни срачей по поводу))
Неужели никто «Искусство программирования для Unix» не читал? Эта тема стара как Unix 😁 Эрик Раймонд в этой своей книге уже давно обо всём этом писал. И критика ооп и постулат о приоритете стоимости человеко-часов над стоимостью процессорных циклов. Да. Вот так и живём 🤷♂️
KISS - рулит, SOLID - сосёт))
@@che42cc его надо балансить с GRASP и здравым смыслом
А ещё там написано предпочитать текстовые протоколы бинарным в ущерб быстродействию, потому что отладку выполнять проще. И это правильно
Ага, вот только на собеседовании скажешь хоть слово против чистого кода и тебя посчитают нубом. И доказывай потом кадровику
Не жалею, что открыл это видео с кликбейтным заголовком! Спасибо автору за обзор!
Их дебаты можно было бы свести к другому аналогичному вопросу: "На чём бы вы хотели писать программу: на условно Питоне или на ассемблере? А почему? Ведь на ассемблере же быстрее работать будет..."
Такое ощущение, что люди забыли историю развития программирования и откатились лет на 10-20 назад ко временам, когда ещё не сделали популярные нынче "простые языки", которые изначально и сделали, чтобы было более удобно для людей в ущерб производительности. Странно почему не откатились ещё дальше ко временам, когда чуть ли ни самостоятельно ОС нужно было писать каждый раз для каждого железа. А что? Ведь тогда всё ещё быстрее работать будет, ведь не будет лишних функций.
Какая может быть производительность когда большинство программистов пишут в костыльно-ориентированной парадигме?
Все это результат развития мощностей, что позволяет программистам не париться особо о том как работает их программа. Когда мощностей было недостаточно, тогда и писали максимально оптимизированные программы. А сейчас это никому не нужно. А страдают пользователи)
Как по мне, не нужно уходить в крайности только одной концепции, а смотреть с проверками, какой подход, когда будет лучше и в какой ситуации.
Когда говорят надо что бы за 500нс считалось, то тут перфоманс) Во всех остальных клин
У каждого сообщества есть свой Мурыч
О! Наконец-то кто то решился разобрать по фактам весь этот оверинженеринг, который пропагандируют с каждого утюга.... простой пример - любой учебный проект типа Hello World на чистом коде это 100500 разных абстракций погоняющих друг другом, черт ногу сломит понять где что и зачем... а надо то всего std::cout реализовать. а потом удивляемся что софт лагает, пишут то его те кто по таким учебникам учился.
не знаю как в других сферах, но в web всё лагает из-за фронта. И вот фронтеры как раз преисполнились, отреклись от богомерзкого клинкода, ооп и прочих ваших задростких штук. А по итогу на 12-ом поколении intel ютюб безбожно лагает. И лагает не подгрузка видео или ещё чего-то, а именно фронт. Вот пока пишу этот комментарий, горю от киселя, вместо ввода. На моём, хоть и не большом опыте, бэк в вебе тормозно работает либо совсем с большими данными, либо когда как раз избегают "оверинженеринг" и не переносят в какие-нибудь очереди то, что должно быть в них.
13 минут, которые экономят часы и доставляют кучу удовольствия! Спасибо!
Бля, я бы посмотрел как бы этот Кейси разрабатывал и поддерживал проект из дохульярда строк, который одновременно пилят 20 разработчиков, а в общей сложности над ним работают 500 человек. И ответ на вопрос "навернет ли твое изменение все к херам" буквально стоит миллионы.
За все фичи повышения производительности не скажу, но вот преимущества switch/case/enum заканчиваются тогда, когда по результатам эксплуатации кода появляется очередной case, под который надо прописать свой enum и добавить в swich. Когда таких case накапливается уже пару десятков со своими под-case, сопровождение кода (исправление ошибок/добавление фич) превращается в АД.
Я клинкод давно считаю субъективным понятием, которое не очень умные коллеги используют когда видят некрасивый текст. Вот и все. Квалификации большей части клинкодеров просто недостаточно что бы сделать лучше, они могут сделать только по своему и потому им кажется, что это лучше...если вообще могут.
перформенс давно в угол задвинули - одним лишь фактом, что всюду нынче питхон) самое смешное, что и нормального клин код в реальных проектах нет. код чаще теплый, мягкий и слегка липкий. Тоесть - и производительность просрана, и код аккуратно писать/проектировать не научились. Оба два.
"перформенс давно в угол задвинули - одним лишь фактом, что всюду нынче питхон) " А теперь представьте себе, сколько "стоит" каждый "шаг" на этом самом пихтоне и осознайте, насколько ТАМ важно, чтобы этих шагов стало не 1000, а 50.
@@knarg4682 На самом деле тут ситуация гораздо более сложна и многогранна. Можно сказать, что питон просто увековечил факт, что разработчики разучились ценить производительность (а бизнесс просто горизонтально масштабирует машины с бэкэндом на питоне). Обратный яркий пример - жаваскрипт с его JIT. Производительность бешаная, даже с плюсами конкурирует легко. И что толку? Открываешь очередной сайт - текст с картинками. А у тебя минус гиг оперативки и два ядра процессора на 110% загружены - под капотом вертятся мегабайты жаваскрипта непрерывно, всяческие трекеры, телеметрия, фоновая загрузка рекламы и ещё дьявол весь что. Зачем. Нахрена...
А потом пользователи такие "Вааай, не оптимизировано, игры лагают, движки кривые, раньше было лучше и т.д. Как по мне, лучше быстродействие чем быстровысер.
Из одной крайности в другую?
Да да, лучше писать говнокод, который невозможно адекватно расширять, а каждая новая фича для игры плодит (количество фич)^2 новых багов. Получилось говно, но зато какое быстрое.
а на чьи бабосы то гулять будем, на твои?)
Супер видео! На самом деле, я давно уже на практике заметил насколько субъективно понятие КлинКод. Поработав в 4 разных компаниях, с 4мя лидами - увидел 4 типа этого самого 'клина'. И попробуй им доказать, что их КлинКод недостаточно клин) Как по мне, самое главное в сегодняшней разработке, чтобы в команде были четкие, закрепленные подходы к разработке. Но на их описание нужно потратить уйму времени
2:08 нет! не стоит!!! это неправильное понимание SRP! разбивать приложение на классы с одним методом чтобы этот класс мог выполнять только одну задачу - это неправильно! Класс нужно разделять если у него есть несколько причин для изменений. вот автоматизируете вы какой нибудь бизнес. если у вас есть класс, который нужно будет изменять и при обновлении должностной инструкции кладовщика и бухгалтера - это плохо спроектированный класс, он не соответствует SRP, его нужно разделить. Но если у нас есть класс, в котором 100500 методов, он описывает действия которые совершает кладовщик, и изменения законодательства в части налогообложения никак не вынуждают переделать этот класс - он внезапно соответствует SRP.
вот не знаю насчет экономии времени. казалось бы клин код должен быть тем полезнее чем больше проект, но получается наоборот. на практике же тонна времени уходит на то чтобы разобраться как в эту эифелуву башню из интерфесов и абстракций вставить свой этаж и ничего по дороге не сломать. еще больше времени идет на то чтобы вычленить из огромной свалки существующего кода реюзабл блоки которые ты можешь переиспользовать для своей задачи. Зачастую кажется что написать что-то с нуля проще и быстрее чем пытаться переиспользовать существующую кодовую базу(
Странно, что такой код называют "чистым" скорее бы подошло название "читабельный"
Клин код не самый удобный стандарт, он и читабельности далеко не всегда добавляет. Мы в принципе всегда когда кодим пытаемся найти баланс между простотой и гибкостью, понять какие части вряд ли поменяются и их можно хардкодить и оптимизировать, а по каким завтра могут принести "уточнённые требования" и кусок придётся выкидывать нафиг. И где будет этот оптимальный баланс зависит и от человека, и от задачи, и от стека. То есть мы этот навык не только с опытом нарабатываем, но и каждый раз вообще-то переизобретаем.
То что чистый код тормозит всегда было известно. Еще в книге "Рефакторинг кода" об этом говорили - быстрый код преобразуется в чистый. Неудивительно, что код, который пишут железнячники сильно отличается от кода прикладных программистов, потому что первые что-то знают :-) Проблема быстрого кода в том, что при обрастании функционалом объем кода растет и поддерживать его будет нереально сложно. Скорее всего решение должно пойти в сторону компиляторов, которые должны преобразовывать чистый код в быстрый, т.е. преобразовывать интерфейсы в if/switch и тому подобные вещи :-)
Компиляторы не помогут. Распаковщик unrar для ZX Spectrum (автор AIG) изначально был сделан из C, скомпилированного ВРУЧНУЮ. Я оптимизировал его в 11 раз за счёт генерации кода разбора дерева на лету. Распаковщик JPEG для ZX Spectrum (автор >>RRA>>) изначально был сделан из ассемблерной программы для 68000, переведённой на Z80 ВРУЧНУЮ. Я оптимизировал его в 5 раз за счёт вылизывания трёх главных операций - выборка из битового потока, IDCT и пересчёт в экранный формат. Про 3D-движки даже говорить нечего, там всё прямо по регистрам раскладывается + используются вычисляемые переходы и патчи. Посмотрите игру Borsch.
Компиляторы с ИИ?
@@edranovdenis Не знаю, но конструкции на языке программирования наверное должны задавать не то, какой результирующий код ты хочешь получить, а какое внешнее поведение ты хочешь получить. Наверное для этого придется отказаться от каких-то базовых понятий, как таблица виртуальных методов - не факт что она всегда будет создаваться для заданного класса.
Ну как сказать, от собеса к собесу вижу клин код только там, как трудоустраиваешься кал из кала... Если бы разрабы писали все так чисто, не было бы слова "рефакторинг"... Все пишут гавнокод, да и бизнесу по факту срать на чистоту вашего кода, фичи фичи, и желательно их уже вчера написать...
Аналогичное наблюдение. Смотришь вакансию - в требованиях куча модных слов. А как заходишь в проект - какой там clean, там даже SOLID'ом не пахнет. И так практически везде.
Я не профи, но моё мнение такое: клин код так распиарили ( и многие компании его требуют ) для того, чтобы работника было легко заменить. Какой-то кастомный код другим участникам проекта труднее понять, а главное такой работник еше может и пальцы начать загибать и попросить прибавки зарплаты, а в случае его увольнения замену найти будет непросто, ну или после него там все переделывать, а для бизнеса это неприемлемый вариант, для бизнеса ты просто инструмент, который должен быть легко заменяем, как запчасть.
ОС запускается быстрее чем VS, делаем выводы
ну на самом деле не правда) В случае с виндовс, компьютер не совсем выключается)
@@fineuarealittlepogchamp гибернацию можно выключить (разницы по загрузке я не ощутил). Если не брать виндовс, то линуксятина грузится за секунды
Ну то, что несмотря на весь прогресс железа, программы становятся все монструозные и работают все медленнее - это факт. Мой свежий ноут грузится и грузит докер десктоп или идею с плагинами или вскод с плагинами, уже столько, что, извините, я успеваю сходить поссать за это время. Мой PC AT в середине девяностых грузился и грузил среду разработки с СУБД гораздо быстрее.
Ага. А когда я сажусь написать чего-то для своих ретромашин, мне почему-то больше нравится современная IDE с подсветкой синтаксиса и подсказками. Вы не захотите вернуться в вашу среду разработки середины 90-х.
@@rkurbatovэто ж не подсветки тормозят.
Запусти Eclipse, почувствуй "Разницу" :)
Только не говорите этому Кейси про микросервисы😂
Мартин - чувак, который понимает что программирование - это про людей, а не про железяки. Вот и вся разница.
Чтобы код был и впрямь быстрым - надо писать на ассемблере. Да, долго, сложно и нечитаемо, но если написан прямыми руками, то работать будет быстрее, чем аналогичный код, собранный компилятором какого либо высокоуровневого языка. Тем не менее был выпущен С/С++ еще в далёком 1973, когда большинство из тех, кто сейчас это читает, даже не родились. Скорость разработки и скорость приложения всегда по разную сторону весов. Истина где то посередине, но её позиция не однозначна. В зависимости от задачи акцент смещается в нужную сторону.
Ну про ассемблер ты загнул. На нём пишут что-то низкоуровневое типо драйверов и компиляторов. Максимум в код Си делают вставки ассемблера там где это необходимо. Но в 99.999% используют высокоуровневые языки. Потому что никакой жизни не хватит писать на оссемблере, да оно зачастую и не нужно. Потому что программист общается обычно не с процессором а с операционной системой. Ну и каждый раз вручную прописывать элементарные операции на ассемблере это маразм. Эти операции уже давно прописанные и зачастую отлично оптимизированны.
Я подумал сначала, что видос будет про баттл Soer vs Nazarov😂😂😂
Кто эти люди? )))
вовремя хапапах
ахвахвах легендарная битва P.S. ПРОПЕРТИ
А как же Соер против Мурыча?
Много комментариев про "тяжелые приложения" и 100 уровней абстракции. Но Роберт Мартин как раз и борется с этим. Он продвигает культуру разработки как в коде, так и вне кода (говоря про ответственность перед пользователем и бизнесом). "Клин код" это только одна из "глав" его идеологии. Если не ограничиваться только одной его книгой (судя по всему ещё и бегло прочитанной), то всё встанет на свои места. Продукты тормозят и лагают не из-за Роберта. А из-за низкой квалификации разработчиков (в целом по индустрии) и наплевательского отношения к продукту этих самых разработчиков. И виной вовсе не бизнес, который "торопит и не даёт сделать как надо", а разработчики которые либо не умеют, либо ленятся (или просто плевать). Самому же бизнесу не нужны тормозные и глючные приложения. Да, есть блоки где нужна максимальная эффективность, но это ничтожно малая часть всей бизнес-логики. Такие вещи, изолированы и им требуется изначально другой подход. А если текущие продукты написать просто оптимально, этого будет более чем достаточно для всех.
А у нас в расте вообще нет ООП, зато свич один из самых мощных. Это к тому, что всё это давно не секрет, причем настолько, что задизайнено в основу языка.
неоптимизированный "clean code" в проприетарном закрытом софте заполонил все. лично я выбираю оптимизированный софт где это возможно. Установив какую-то утилиту которая грузит CPU на 100%, а потом попробовав другую похожую по функционалу, я выберу вторую.
Это большая, но весьма типичная ошибка - называть говнокод чистым.
Ну понятно, что ничего не понятно. Вроде бы хочется скачать что performance и clean code это противоположности, но там вылезает Кейси и говорит что его подход читабельней. Вопросик. А как будет вести себя Архитектура Кейси в Громадном проекте? Будет ли его код настолько же читабельным. Я не разбираюсь, но мне кажется что прогеры отошли в сторону Clean Code именно по этой причине, а перформанс остался для узких мест, и его как модуль можно вставить в Clean Code в места где это действительно важно, и вот тут как мне кажется Clean Code недоработан... Жаль что я не знаю ответа на свой вопрос.
Почему все умные комментарии внизу списка а умники по типу клинкод для мелких программ в топе
Те кто пишет на Си, конечно же адепты КейСи и перфекционисты. Код должен летать и на тостере, полностью с ним согласен. А все эти командные проекты не так важны в плане производительности, там для них тестировщики существуют, работает и ладно. "Клир" код типа))
Со свитчами-то код клиновей выглядит
ждем следующую часть про OpenGL
Просто не нужно перебарщивать с абстракциями и тому подобным и будет вам баланс
Надо тогда зарплаты программистам резать если они не могут делать программы работающие в 15 раз быстрее.
Любой бизнес, это обман. А большой бизнес, это большой обман. Все коммерсанты, это самураи, для которых важен путь, а не результат. Когда задачу решает инженер, он решает ее качественно, эффективно, оптимально и с минимальными издержками. Но когда ту же задачу решает коммерсант, он решает ее не оптимально , некачественно, с максимумом издержек и не оптимально. Иначе, когда потребителю ясна и понятна цепочка превращений сырья в товар, или услугу, много не заработать. Но это, как всегда 2 крайности, а оптимум где-то посередине.
Рекомендую к просмотру со скоростью 0.5 )
"+", если тоже смогли догадаться, что происходит на 3:50
А вы не заметили что раньше вам хватало 1 гб оперативки, а теперь уже 16гб мало. Это такой же принцип. Раньше больше парились по поводу оптимизаций и скорости, с развитием железа все меньше этим парятся, делают упор больше в сторону удобства разработки, поддержки. Правильно это или нет, это уже другой вопрос. Мне интересно что будет если АИ напишет очень скоростной и оптимизированый код, насколько сложно человеку будет поддерживать этот код. Если в будущем АИ сможет и сам писать и сам поддерживать, тогда АИ нет смысла придерживаться клин кода, он может использовать максимально оптимальную модель которая даст максимальную скорость и будет использовать минимальное количество ресурсов.
с удовольствием просмотрел видос. Оба, Кейси и Боб имеют хорошие факты. Если первый, показывает что CLEAN CODE бывает что нагружает железо, а второй говорит что оно помагает не железу, а будущим людям которые будут работать в этом проекте, то тут невозможно сказать что всегда надо придерживаться одной методологии, ведь бывает что бизнесу нужна обычный продукт, которые будет работать (неважно быстро или медленно, а главное работало), а есть бизнес которой важен не то как "удобно" читать, а как БЫСТРО оно работает. Я считаю что надо найти баланс, если проект нуждается в производительности, а оптимизировать нечего - надо отказаться от принципов CLEAN, а если скорость неважна - то CLEAN лучше. P.S. ВСЁ ЕЩЁ ЖДУ 10 ЧАСОВОЙ ТУТОРИАЛ ПО С++
Да хз, все же просто, пишем как нравится, потом берем профайлер и делаем код быстрым. А писать прям весь код чтобы думать только о производительности напряжно и выглядит порой плохо
Думать о чистоте постоянно тоже напряжно. Особенно если это обязанность, должностная или социально.
Пишем как нравится, чтобы потом переписывать половину кода
@@rafk5341Суть в том, что так называемых бутылочных горлышек в программе не так много. Тот же пример с гитхабом показывает, что не столь важно, как написан тестовый редактор, его производительность приемлема, а вот что нужно оптимизировать, закрыв глаза на клин код, так это менеджер эмоджи. И такой баланс 9 к 1 практически везде
@@rafk5341половину кода все равно придется переписать, как не старайся в начале:) а некоторым нравится писать так, что потом приходится переписывать все:))
@@rafk5341 итеративность - всё же более светлая альтернатива, чем полная стагнация в попытке с первого раза сделать правильно
Странно что код написанный на полиморфизме и на свичах не скомпилируется в примерно одно и тоже на уровне ассемблера
Для полиморфизма всё равно придётся использовать виртуальные функции.
Классическое заблуждение основанное на базе прочтения рекламных статей продавцов компиляторов. Да не скомпилируется он в одно и то-же никогда в реальном мире!
я пишу код для алготрейдинга, который должен отреагировать на изменение данных и уложиться в минимально возможное время. Цель не выходить из 1мс. Вот тут и приходит необходимость задуматься и над структурами данных, типах данных, циклах и кол-ве операций процессоров, кол-ве ядер, размещении данных данных в памяти, кеше и прочем. Но за 15 лет работы до этого, в этом не было необходимости и я не занимался профайлингом на уровне микро/наносекунд как разработчик.
Всё зависит от задачи, и производительность - один из пунктов ТЗ. Большинство софта вообще крутится не на пользовательских ПК, и является довольно сложным, чтобы писать его на ифах/свичах. Часто там вообще не важна скорость, главное - возможность без проблем нанять новую команду для поддержки этого монстра, и чтобы они не повесились, добавляя какой-нибудь мелкий функционал))
ещё новые студии собирают более тяжелые приложения по весу нежели старые
Вот вроде видос ни о чем, просто про срач двух айтишников, но подача аргументов и примеров делают видео очень интересным. Хорошо преподнес тейки Кейси. Думаю можно было даже побольше показать примеров плохого/хорошего кода. Кароч спс за видос, было очень интересно
в видео только один аргумент, и это скорость работы кода. Все остальное автор растекаться мыслью по древу.
Всегда скептически смотрел на эту книгу, а теперь все прояснилось. В принципе, если ты учил компьютерные науки, то чувство элегантного кода будет на нужном уровне, как и понимание где и что нужно комментировать, как называть переменные и прочее.
Из очевидности факта X для Боба не следует его очевидность для Алисы. И наоборот
Абсолютно согласен. К примеру, DRY. Джун буквально после пары-тройки правок двух одинаковых кусков кода, которые он ранее Ctrl-C Ctrl-V, когда возникнет необходимость изменить функционал, автоматически смекнёт вынести это в отдельную функцию. Ну если он не идиот, конечно. Ах да, если он "учил компьютерные науки" и вообще отдупляет, что такое программирование. Достаточно просто понимать, что ты делаешь. К сожалению, слышал, что сейчас, на волне хайпа, появляются такие "программисты", у которых даже не возникает желания разобрать и понять, что код, собственно делает и как вообще работает, так и тычуться, как слепые котята, в одни и те же грабли.
Элегантный код для кого? Клин код требует от разработчиков писать такой код, который будет понятен другим разработчиков. Потому что в корпоративной разработке не столько важна алгоритмистика. Код в корпоративной системе это в первую очередь средство коммуникации с другими разработчиками. Потому что в корпоративной разработке работают командами. И с кодом чаще взаимодействуют люди. Поэтому и элегантный код это такой код, который хорошо читается и понятен. А не просто красивое однострочное не пойми что, которое вроде работает.
@@lutwiy931какой ужас. Хорошо что я не программист. Если про инструмент коммуникации правда, то это прям жесть. То есть кто-то из программистов может не понять элегантный код? Проясню, что такое элегантность. Это когда написан оптимальный алгоритм, без лишних действий. Бритва Оккама. Когда ты не пишешь лишнее разветвление или цикл. Не используешь лишних переменных. Я когда такой вижу, не то чтобы понимаю, у меня прям мурашки по коже от удовольствия. Это же чистый кайф.
@@nurlansalahaddinov8075 и чем твое определение "элегантности" противоречит объяснению Мартина? Ах да. Тем, что ты его объяснение скорее всего даже не открывал. Что в целом нормально для не программиста.
Писала программу для анализа и работы с большим количеством данных на python. Разработала несколько версий и смотрела на производительность. Решение с ООП справилось за 30 секунд, черновой вариант написанный лишь чтобы работало справилось за 1.5 минут, но что интересно, самый чистый код, который я буквально сделала по книжечке, соблюдала все принципы чистого кода справилась за 10минут, меня это сильно шокировало, не знала как с этим быть, но вдруг встретилось это видео и многое встало на свои места.
Все эти клинкодщики впухают когда пробуют написать какой-нибудь вычислительный шейдер.
Написание и оптимизация приложений - это два разных этапа разработки. Люди, которые начали оптимизировать свое приложение до того, как его доделали хотя бы до альфа-сырца - никогда не доберутся даже до альфа-сырца.
А если сразу писать нормально, то особо и оптимизировать не придётся. При меньшем размере и сроках.
Если избавиться от clean code, интерпретаторов и перейти на ассемблер, то выигрыш по скорости может возрасти не в десятки, а сотни раз.
Компилируемые языки не менее высокоуровневые чем транслируемые
Почему вы говорите о том чего нет в видео? В видео про Clean Code и архитектуры приложения, а не про языки программирования.
@@OlegMasters Архитектура строится от ЯП
@@user-mr9tw6rj9i нет. Архитектура отдельно, а язык программирования отдельно. В любом языке можно применить различную архитектуру.
Дядя Боб всё верно написал! Оптимизация не должна наступать на читаемость, потому что потеря читаемости в дальнейшем приведёт к падению оптимизации. Оптимизацию должны выполнять компиляторы, на уровне asm нет никакого полиморфизма, только jmp.
Когда я открываю вкантактик с его новым дизайном и скруглёнными иконками, я открываю суровый монитор ресурсов прям из нулевых и вижу там 0.5-2 гигабайта на вкладку. Насколько бизнесу выгодно, чтобы за их программистов расплачивались клиенты?
Раньше уповали на то, что производительность железа каждый год увеличивается в 1.5-2 раза, так что это было не так важно. Сейчас хоть и другие времена, но всё равно время разработки обычно важнее производительности: хорошо платить программистам меньше за меньшее время работы и получать больше за частые нововведения.
Вы неправильно солид понимаете. OCP к наследованию никакого отношения не имеет.
Я хеллоу вролдщик, но вкину свои соображения: 1. Если ты используешь конструкции языка а не низкоуровневые самописные костыли - это может быть медленнее в какой-то верси языка, но сам язык скорее всего развивается и оптимизируется, и со временем исопльзование конструкций языка может стать сравнимо а то и лучше самописных костылей, а вот самописные костыли оптимизировать придётся самому если вообще на это будут ресурсы (то есть врятли костыли со временем ускорятся, в отличии от нативных инструментов языка или фреймворка) 2. Тема с оптимизацией вроде сто раз обсосана, и в подавляющем большинстве от процессора нужно менее 1% скорости. Во многих "ресурсоёмких проектах" обычно есть 1% кода который занимает 99% машинного времени, и именно для этого 1% имеет смысл отступать от чистокода вспоминать математику и логику, а ещё лучше пригласить специалистов которые понимает это на совсем другом уровне. Ещё частая проблема кода написанного просто чтоб поднять рабочий концепт - запросы в БД в цикле просто вынос логики из запроса в код, тогда ресурсы клиента используются тупо на ожидание ответа БД когда всё это можно было сделать в одном запросе и ждать не тыщу раз а один. (иногда смотрю на работу некоторых вэб страничек, и просто физически больно и по времени затратно настолько, что появляется желание написать свой клиент, который имитировал бы эту страничку и делал в разы меньше запросов, но для этого надо хакать а я хоть бы кодить научился по-нормальному хоть где-то, чуть сложнее задача - сразу кончается докментация и начинается тыкание башкой в стены в темноте) 3. Развивая мысль из первого пункта - когда код типа оптимизирован и вместо вызовов тучи функций идёт гладко и кешированно - это збс для маленьких проектов как по времени так и по объёму, когда он весь помещается в одной голове. ПРи работе команды же приходится делить код на законченные части которые стыкуются между собой через заранее обговорённые параметры, и может такое получится что код который гладко выполнялся бы делится на части которые вызывают ошибки запросов в кеш или прочие задержки по времени, но разработка больших проектов и тем более их поддержка без деления невозможна, а значит изначально надо делать проект максимлаьно гибким к изминениям, ведь консолидировать несколько функций или классов в один гораздо проще чем растаскивать суперкласс на сущности.
- ты читал «Война и мир»? - Да - А что там? - Ну там сначала была война а потом Мир… - Спасибо, почитал😥
На самом деле, эта ваша "понятность кода" зависит от опыта. Чем больше у программиста опыта, и чем больше он знает всяких разных алгоритмов/паттернов/идиом, тем большая часть кода ему понятна. Соответственно, популярность чистого кода (и вообще актуальность) объясняется в основном тем, что в нулевые индустрия переживала взрывной рост. Нужно было понабрать очень много людей с улицы, которые лишь вчера осознали себя программистами. Никогда ранее такого роста в индустрии не было. Поэтому практика чистого кода показалась всем спасением. И никода более такого роста уже не повторится. Поскольку быстро расти в разы легко только с нуля. Так что чистый код плавно будет утрачивать свои позиции, уступая место более важным вещам. Уже сам факт того, что уважаемые господа схлестнулись публично, говорит о том, что позиции чистого кода ослабли настолько, что по ним можно попытаться нанести удар, не боясь оказаться посмешищем.
Clean Code побеждает не потому что он "выгоден бизнесу", а потому что он создаёт у разработчика ощущение того, что его работа - rocket science, он - творец и созидатель в мире абстракций (которые он же и выдумал). Этот tech-инфантилизм распространен просто по причине того, что люди не хотят учиться, не хотят копать в глубь, не хотят думать о "циклах и ядрах" и вместо этого придумывают свое фэнтези на том уровне, на котором им комфортно и играют в него.
люди вообще не хотят делать машинную работу - пусть ею занимается машина. для этого и существуют программисты чтоб машина работала
кажется, кое-кто кодит в соло
Каждый код должен быть персонализирован, либо понятен тем, кто реально должен с ним работать. А вот оптимизация нужна везде.
По-моему, ответом на тормоза "чистого кода" стало появления языков типа Rust, Zig. Автор Zig утверждает, что ещё и читабельность его кода лучше, чем на C++, на котором он до этого писал.