Пусть я и не сильный аналитик и не глубоко знаком со структурой вне clean code - но я никогда не задумывался от этом, и теперь я пересмотрю подход к использованию solid и dry, спасибо за ролик.
Языки программирования и были придуманы для удобства и скорости написания программ, а так же, точнее наверно даже в первую очередь для удобства и простоты,чтениятекста программ человеком, внесения корректировок и дополнений . Но что то пошло не так. В итоге- один хрен очень мало кто может читать чужой код, особенно без комментов, но при этом код тормозит по сравнению с тем если бы писали на ассемблере.😢
@@АлексейКруговой-н9успорное заявление про читать чужой код. Если ты опытный ты и всю лапшу индусского кода разберёшь. Мне лично помогло книги по рефакторингу
@@АлексейКруговой-н9уПойдет так, когда каждый сможет написать язык программирования чисто для себя. Под свое понимание реальности, скорости разработки, эффективности. Невозможно создать универсальный интерпретатор, без ИИ
Был в моей жизни период, когда я одновременно работал над разными проектами. Первый - Backend на Java Spring в команде, второй - прошивка для STM32 (микроконтроллер) на С++ в соло. Мои коллеги (Java разработчики) активно призывали использовать принципы Clean Code и старались обсуждать и доносить идеи до остальных. Тогда я и начал в это активно погружаться. Многие идеи я пытался использовать и в своем проекте на C++. Однако тут мне пришлось осознанно нарушать многие правила, поскольку производительность микроконтроллеров слишком ограниченная, и многое приходилось писать "в лоб", избегая сложных абстракций и т.п. Уже тогда я для себя понял, что важно мыслить гораздо шире, и отталкиваться в первую очередь от целей, а не применять правила ради применения правил. Просто думайте и совершенствуйтесь!!!
фокус том, что чистый код - первый уровень, а оптимизация его - второй. Итого - пишем все чистым кодом, а потом оптимизируем и при сопровождении. Всегда два этапа. А самое главное - есть нулевой уровень - правильно заданные алгоритмы, в идеале с нулевой задержкой на побочные вычисления. Иначе непонятно к чему стремиться. Можем получить, что при конечной оптимизации без верхних уровней забудем, ради чего это все и что теряем
@@che42cc а начинаешь углубляться и понимаешь, что ничего не лагает, просто абстракций так дохуя, что итоговое время огромное, ну то есть лаг. И ты чешешь репу, а как теперь убрать лаг, если для этого надо переписать половину кода и как это переписать, если в принципе написано согласно правилам.
Читал на каком-то форуме пост от чувака, у которого горело от размера приложений на телефон. Что, мол, банковские клиенты весят ~500МБ, в то время как гта 3 (или SA, не помню уже) тоже весила что-то около 500. И, говорит, "сбер, где мой открытый мир в твоем приложении?)" И в комментах люди расписали ему, что пофигу компаниям на размеры приложений сейчас, у телефонов есть ресурсы, так что можно забить и важна лишь скорость написания и выкатывания фич Это я к тому, что бизнесу скорее важна производительность программиста, нежели железа
На самом деле есть такой парадокс, работал 13 лет назад над андроид приложением - магазином, куча деталей продукта, когда листаешь много чего отрисовывать - запихнули в кастомные вьюхи и рисовали прямо на канвасе - работало шикарно. Судьба вернула к этому же заказчику на тот же проект, команда в 10 раз больше, все на современном стэке, клин и тд. Так вот сейчас все зашиваются, перегруз по работе, а самое главное на современном железе все лагает жутко. Я хз куда этот мир катится, 13 лет назад нас троих хватало на все, сейчас все тот же функционал, но намного хуже переписанный просто в 100 раз хуже перформанс.😢
Что Windows, что MacOS от версии к версии утверждают, что улучшили то-то и то-то, заменили что-то старое на новое и быстрое. Загрузка ОС и работа стали быстрее, НО... старое железо больше не поддерживается, а общие требования к железу выросли. Из чего можно сделать вывод, что быстрее становится не из-зи оптимизации, а исключительно из-за более быстрых CPU, RAM, SSD и бОльшего объема RAM, которую засирают по черному. ((
зато у них всё на МОДНЫХ фреймворках и они "крутые", и начальство может писюнами меряться с конкурентами "мы используем новейший стек технологий XYZ", а ты в их глазах - "жалкий дилетант-писатель велосипедов" [сарказм, ирония, стёб]. А вообще Андроид окончательно скатился в унылое говно, во многом изза подхода к GUI, ну и котлин не всем нравится (и хотя модный ныне джетпак-композ по своему оригинален и впечатляет, но он не всегда прост для понимания). Похоже надо переходить в другую специализацию.
Вообще-то все зависит от конкретной задачи. Если мы видим, что какой-то кусок кода выполняется раз в 2 часа и его выполнение занимает не 100 наносекунд, а 250 (из-за чистого кода), то ускорять нам ничего и не надо. Он прозрачен и в нем нет ошибок. Если же код выполняется каждые 500мс*100000 раз, то тут уже не до красоты. Фигачим отдельный класс FastMaker в котором будут и свитчи и использование всяких AVX инструкций и вычисление на GPU и asm вставки. Байто*бить это тоже плохо, как и медленный красивый код. Для тех кто не согласен: код который мы пишем был изобретен для упрощения создания машинных кодов. При любом раскладе событий в машинном коде можно добиться лучшей производительности. Это ведь не повод отказаться от языков программирования?
@@tohoto2183 чтобы наш быстрый код на свитчах стал черным ящиком для классов, которые будут его использовать на более высоком уровне. А ещё лучше быстрый код делать отдельной библиотекой, чтобы другие разработчики прикладного уровня не тратили время на реализацию того же самого, а красиво его использовали в своем проекте.
имя опыт работы на по настоящему дерьмово написанных проектах, могу уверенно заявить, что я ни разу не видел чтобы "следование клин коду" вызывало проблемы с перфомансом, обычно совсем наоборот
Поддерживаю что проекты с нормальной архитектурой работают лучше. Легче бьются на микросервисы, легче расширяются. А мест где бы нужна хорошая оптимизация очень мало и жертвование читаемостью там допустимо. Но обычно проекты без клин кода это монструозный кусок мусора с имиджем на 30 гигов который писался с идеей «нет времени думать нужно делать». И их улучшение требует такую прорву часов что никто этого не делает.
Если упарываться в удобство программиста, то платим производительностью. Если упарываться в оптимизацию, то платим временем разработки. Наверное лучше искать баланс...
нейронки все разрулят рано или поздно, выдадут каждому желающему х20 производительность (если не всем задачам, то всех уровня мидла), ну а читаемость кода уже не будет важна т.к. проги будут писаться уже не человеком (ну, постепенно вытесняя человека, окей?) из за того что стоимость нейронки будет стоить около 10 центов за написание, а тот же программист мидл будет это же делать за зп в тысячу $. И да, это не я выдумал, так говорит Сэм Олтман, их цель на ближайшие годы это снизить стоимость интеллектуальной работы к 0$
Docker, на самом деле, не даёт никакого дополнительного пенальти производительности. Ну, может, кроме самого демона докера. Тогда возьмите Podman. Всё, что "завёрнуто" в Docker, по сути точно такие же процессы в ОС, мы тут не будем рассматривать, если докер под мастдай в виртуальной машине. Используются всё те же системные вызовы, что и без использования докер.
Пишешь чистый код, твой код ждёт больше циклов процессора, больше циклов процессора, больше тратиться электричества, больше электричества - больше выбросов в атмосферу. Надо дождаться когда "зелёные" доберутся до программистов, и можно будет забыть про чистый код.
Чота я не понел. Чувак доказал, что если убрать vtable и прочие плюшки, написать код, специализированный для данной операции, то он будет быстрее? Ну да, будет, а чего такого-тооооо? Иногда мы именно так и делаем на микроконтроллерах, если нужно прям очень ужаться по производительности или памяти или чтоб выдерживать тайминги до тактов. Но в абсолютном большинстве программ это не требуется. Но есть один нюанс. Очень трудно написать в таком стиле большую программу. Поэтому нужно знать что, когда и в каких случаях применять. Ваш капитан Кэп.
ну вы так в своих рассуждениях вообще можете дойти до идеи что "серебрянной пули нет" и "головой нужно думать что и зачем ты делаешь", а холиварить тогда как????
@@roman7956 да, что это я в самом-то деле. Ну ок, погнали: иногда, в редких случаях, в C можно использовать goto. У меня был кейс, когда буквально пришлось основной цикл программы (на микроконтроллере, оф коз) построить на goto. Там почти вообще не вызывались функции, ибо это дорого по времени.
ты не понял сути ролика? Посмотри еще раз, там же четко всё расписанно, тебе твой боб внедряет свою идею написания кода, ты буквально пишешь по шаблону другого человека, и это не есть хорошо, когда ты сам не думаешь о том как бы оптимизированнее и быстрее код написать может просто тебя оставить без развития в своей сфере, я считаю надо сначала посмотреть а потом додумать и сделать еще лучше, а повторять за кем-то не пытаясь что-то изменить в лучшую сторону, для меня это не программист а фальшивка
Я когда смотрел оригинальное видео то не мог понять: он то ли троллит, то ли серьёзно. Дональд Кнут когда-то сказал: "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 платформ я никогда не видел, чтобы в них кто-то в здравом уме в циклы с миллионами итераций вставлял вызывы каких-то ф-ии и уж тем более полиморфных. Большинство проблем производительности сегодня это обработка огромных массивов данных (в основном графика), которые не умещаются в кэше процессора, за что мы каждую секунду получаем громаднейшие пенальти. В профилировщике обычно в топ вылезает именно это, а не какие-то вызовы. При обработке громандных массивов данных в огромных циклах как раз и применяются оптимизации упомянутые Кейси, но зачем тащить оптимизации приминимые для больших данных/итераций туда, где они не дадут значимого выигрыша, но усложнят читаемость кода?
Это вы, батенька, спорите с соломенным чучелом. Где у Кейси было сказано, что трудозатраты на оптимизацию кода окупаются всегда? Он говорит совсем другое: не всегда clean code важен любой ценой, нужно знать его издержки и понимать, когда необходимо от него отступить. И есть масса случаев, когда это случается на практике. Даже тот код, который не выполняется миллионы раз внутри какого-нибудь цикла, бывает нужно оптимизировать, если он сам вызывается миллионы раз в секунду. Я на своей практике сталкивался с такими ситуациями, когда уже не было смысла в программе оптимизировать узкие места, поскольку каждая строчка программы примерно в равной степени тормозила систему до неприемлемого по техзаданию уровня. И я сталкивался в своей работе с тоже-программистами, которые сначала цитировали Кнута про "преждевременную оптимизацию", а потом спустя некоторое время и вполне предсказуемо бегали кругами и кричали, почему продакшен нестерпимо тормозит и что надо срочно что-то с этим делать, желательно вчера. Полагаю, вы так же не сталкивались с проблемами производительности таких вещей как высокочастотный трейдинг и различных OLTP-подобных приложений, а это весьма обширная область. Так что говорить, где лежит большинство проблем, несколько самонадеянно.
> почему при наличии современных мощных профилировщиков никто в индустрии не говорит о тормозящем полиморфизме, а говорят в основном о других проблемах в производительности (память, кэш, i/o)? Потому что новое железо достаточно купить, а новые знания нужно майнить?
Говоря про быстрый код, многие представляют какой-то нечитабельный ужас с указателями на указатели, инлайн ассмебли и кучей симд, хотя зачастую все, что надо для +- производительного кода, это: - грамотное использование фич/языка (зарезервировать место для вектора и скопом добавить объекты, а не резервировать для каждого элемента) - маломальское знание алгоритмов/динамического программирования (сохранить результаты вычислений, чтобы ускорить последующие, не использовать 4 вложенных цикла там, где можно обойтись двумя) И даже так, как по мне, комфорт программистов не стоит того, чтобы у конечного пользователя 30 секунд грузился ГУИ из-за 10 слоев абстракций
Ну правды ради, в каких-то графических решениях, быстрый код это по факту нечитабельный ужас с указателями на указатели, инлайн ассембли и бешенными алгоритмами)
@@Мояшарага-ъ2ж вообще да, но тем, кто крутится в таких сферах где производительность очень сильно важна, скорее всего в кайф реализовывать сложные и нечитабельные алгоритмы и выжимать из железа максимум самым малоизвестным методом)
Ну как бы разница в 15-20раз это провалл клинкода. У нас процессоры не стали на столько быстрее с 2007 года. Там хорошо если они стали быстрее раза в 3. Чего реально стало больше это ядер и памяти. Но это не сильно решает проблемму быстродействия. Ядра помогают многозадачности а не ускорению конкретного процесса. Да теперь мы можем и браузер запустить и игру и стрим если количество ядер и памяти позволяет. Но если процесс не оптемезирован то тут уже никакие ядра не спасут.
@@vsevolodkuleshov8551ну это не разницы в 15-20 раз, а в несколько десятков цикла процессора. Когда с бд загрузка идет секунду, все другое не очень играет роль
По моему в какой то книге кента бека была фраза что код сперва должен просто работать, на следующем шаге можно сделать так чтобы он был написан красиво, и в конце чтобы он работал быстро. дядя боб говорить как писать кода на втором этапе, а кейси - на третьем =)
Не подходит , в клин коде не про красиво вообще ,там свой стиль просто у аппонента другой стиль,когда большая программа пиши как хочешь ,все равно заблудишься. Клин код -это про навязывание своих строгих правил написания и не более того,следуя им все-таки легче понимать ,но сомнительно ,что это работает в больших прогах.
Эм... самое смешное что они оба правы так как говорят о разных вещах. Кейси рассуждает о написании, скажем так, mature продукта, настоящего, ну типа ngnix или sqlite - это идеальные инструменты, которые на любом вейпере вытягивают 100К запросов. Ну или тот же Doom Кармака или OTP Elexir-а - вот такие вещи. А дядя Боб - про сляпывание прототипов, которые вместо того, чтобы выкинуть - раз-раз и в продакшен. ИМХО - 98% всего созданного и работающего софта - это чертовы прототипы, которые еще и постоянно допиливаются, потому что заказчик некомпетентен и не в состоянии видеть вообще, какой уж тут нос. И вот эти прототипы хоть как-то поддерживать в живом состоянии можно только со всеми этими клинкодными делами. Потому что иначе никто и трехметровой палкой не будет трогать оставленное предыдущим программистом. Особенно учитывая, что не все они Линусы и Кармаки. Так что клинкод - реальность галер и кровавого энтерпрайза. А создание настоящих продуктов - удел упоротых одиночек. Чёт типа того.
так, что-то я не понял: прототипы пишутся с использованием клин код, а зрелый продукт типа nginx, который пишут упоротые одиночки, - у него какая история?
@@manOfPlanetEarth nginx буквально писался одним человеком в свободное от работы время, в какое то время разраб уволился с работы, чтобы посвятить фуллтайм своему детищу. После чего галера(Имя ей Rambler), пытались отжать права на nginx.
Вот как раз зрелые продукты особенно большие на тяп ляп не пишутся. Не стоит просто упарываться по чистому коду. Писал код еще до прочтения книги, ну и почитав просто сказал ок кеп. Т.е. хорошие практики они приходят с опытом а не с книгой или инструкциями как писать и не иначе. На практике скажу что чистый код больше актуален на высоком уровне приложения или в какой-то сложной бизнес-логике, чтобы можно было быстро разобраться или изменить/поправить. Когда залезешь в код который написан "одной простыней" или на столько связан и засран, то невероятное кол-во времени уходит не только чтобы разобраться как оно работает и что имелось ввиду, но и придумать стратегию как это все изменить согласно новому требованию чтобы не сломать. Иногда кажется что это время соизмеримо с разницей процессорного временем потраченного за все время существования программы написанной "чисто" и "грязно". В больших проектах, по опыту побеждает Понимание того о чем Чистый код, а не его неприкословное соблюдение. И есть пример когда приходили молодые и заряженные теорией и книгами и спустя время "все начинало тормозить" - отнюдь не из-за чистого кода а бездумному и местами неверному его трактованию (а масштабируя на количество мест с неверным решением - это все превращалось в процессорный ад). Понимаю что ролик не об этом но все же.
Не стоит брать за основу объяснение SOLID из этого ролика. OCP вообще не про полиморфизм и может быть реализован кучей разных способов. Мне это слух жуть как резануло.
Клинкод дает одну особенность, которую не дает подход кейси: расширяемость На примере фигур он переделал классы в енамы и свитчи. Но если у тебя система плагинов, ты не воткнешься в енам, а свитчи сами не расширятся. Здесь нужен именно полиморфизм. Надо брать лучшее от этого и не застревать на одном месте. Если ты будешь тупить 10 минут над ускорением горячего кода - ок, если день над холодным - не ок. Тем не менее, благодаря JIT можно на лету генерировать свитчи на основе информации в рантайме
@@user-gy8xn4kt7s представь, что ты представляешь клиенту интегрироваться в свое приложение. Например у тебя ПО по отправке файлов на файлообменник с выводом ссылки на экран. Ты реализовал это для trashbox и regfiles с кнопками выбора, и позволил пользователю добавлять другие файлообменники через плагины на основе скриптов js например. Приходит Вася, добавляет 100500 js файлов не только под trashbox, а еще и под гугл, яндекс, mail, ipfs, S3, R2, M1... Начинает продавать все это и получает профит больше тебя. У тебя ведь FOSS, да? Если бы ты вместо плагинов использовал switch-case, Вася не воткнулся бы, а ты бы туда не смог добавить систему плагинов.
@@user-gy8xn4kt7s ну плагины Ты создал ПО и хочешь позволить пользователю добавлять туда свои кнопки через js скрипты Когда у тебя кнопки работают на свитчах, это работает не очень
@@user-gy8xn4kt7s кстати, если отойти от системы плагинов, если такая вещь как мономорфизация обобщений, а также сведение полиморфизма к конечному перечню вариантов и используемых логик. LLVM такое вполне себе развернет в switch-case... Надо только писать на плюсах, зигах и всяких вот таких
Я как мидл со своей практикой скажу так: если вы пишете какую-то приложуху для ИП за 250к то тут вообще пофиг т.к. скорее всего приложение не будет расширятся, а если и будет, то опять же скорее всего, вновь обратятся к вам и тут вы можете немного чек задрать, что скомпенсирует ваш технический долг; если же вы пишите высоко нагруженное приложение и/или интерпрайз уровня то тут нужно тщательно анализировать, где важна скорость - жертвовать всем ради скорости, а где нет, использовать тот самый "чистый код" т.к. если расширением будете заниматся вы то вам придется объяснять тимлиду компании почему придется потратить доп. 2-6 часов на допилы, а если не вы, то уже объяснять почему у вас руки из странных мест ростут.
Насчет самого клинкога не уверен, а вот во всех принципах. Том же солиде это прописано точно. Я вот чаще всего пишу сначала 1 мега класс без интерфейсов, а когда он заработает, уже чищу код. Потому что вносить новый тип переменной во всю структуру наследования и все интерфейсы это дичь. А если потом откатывать, то двойная дичь.
@@tashihu Интересно... Где такой подход работает? Быть может у вас проблемы с архитектурой приложения и потому вы не можете сразу понять куда какая часть вашего божественного класса должна быть вынесена?
"Принимать без фанатизма." - хорошая фраза, если у тебя есть административные полномочия и нужно косвенно сказать "правильно - это именно не так, как сделал ты".
Когда начинал программировать в 2014 году - увидел курс от кейси под названием Handmade Hero. Для начала мне было трудно въехать что он там вообще пишет и как это соотносится вообще с тем чему меня учили в универе или в книгах, но со временем я всё понял. Отныне я никогда не назову клин кодом то что является "нормальным" в современной практике. Его способ написания кода гораздо более легкий и натуральный. И хочу сказать что я кайфую от программирования - чего точно бы не было бы пиши я "Clean code"
Что любопытно - очень многие воспринимают этот спор так, словно сторонники "чистого кода" топят против производительности, а сторонники производительности топят за говнокод(лишь бы он был быстрым). Но это, на мой взгляд, совсем не так. С высоты своего опыта коммерческой разработки(~25 лет) лишь подметить, что подавляющему большинству коммерческого кода даже до "чистого кода" - как до Китая пешком. А код не должен быть "чистым или быстрым", он должен быть "чистым И быстрым". Но, пока платит бизнес, вряд ли так будет на массовом уровне.
Ото ж. Люди, которые говорят, что Clean Code - фигня, хотят писать еще более медленный говнокод. Для того, чтобы писать оптимально, надо научиться писать ЧИСТО для начала. Я буквально вчера в ревью заставил джуна вынести одну и ту же функцию, которую он создал в каждом месте, где она была нужна - около 20 повторений. Сомневаюсь, что это ускоряло производительность. Он просто быдлокодит.
Когда сроки проекта горят, уже не до чистоты кода и не до производительности. Заказчик этого все равно не оценит, а дорабатывать уже можно и потом за отдельную плату. А если со сроками проблем нет то, конечно - "чисто И быстро".
Все так - код одновременно И должен быть производительным, И не должен быть говнокодом. Но для этого в голове должны быть мозги - а вот с этим сейчас огромнейший дефицит.
прав ты, Винд. всем нужны только деньги. и каждый их фармит по своему: кто-то пишет и продвигает свои умные книги, кто-то антихайпит по поводу этих книг, а кто-то хайпит на антихайпе, попутно присовывая подписчикам скильную фактори. а подписчики, хавая весь этот попкорн и чувствуя свою квазипричастность ко всему этому чудесному миру, фармят свои рисовые гроши, гонясь за морковкой, перед их носом... так устроен этот вондерфул ворлд... хеллоу, фускинг ворлд...
Да, деньги есть мерило всего в нашем мире, и не важно как их доставать). И всё равно нам на экологию, разрушительные войны...зато столько денег выручают за каждую единицу боевой техники!) одна польза) Живи, пока ты ещё выгоден своему работодателю; диши гразным воздухом за то что экологическое производство устанавливать дорого; лечись в помойке, потому что больница не бесплатная; смотри как миллионы нищих умирают на улицах и живет Африка, пока "крутые" блогеры жируют; вспоминай как расстреливают парламент из танков, как буквально забирают твоих родных на войну прямо в пекло. А если ты не согласен, то ты же "против государства! демократии! украинский иноагент сатанинского гейропейского запада!", тогда берешь красный флаг в руки и вперед за демократию, прямо на баррикады против омона с дубинками, чтобы люди начали жить, а не доживать зарплату
2:08 нет! не стоит!!! это неправильное понимание SRP! разбивать приложение на классы с одним методом чтобы этот класс мог выполнять только одну задачу - это неправильно! Класс нужно разделять если у него есть несколько причин для изменений. вот автоматизируете вы какой нибудь бизнес. если у вас есть класс, который нужно будет изменять и при обновлении должностной инструкции кладовщика и бухгалтера - это плохо спроектированный класс, он не соответствует SRP, его нужно разделить. Но если у нас есть класс, в котором 100500 методов, он описывает действия которые совершает кладовщик, и изменения законодательства в части налогообложения никак не вынуждают переделать этот класс - он внезапно соответствует SRP.
Я считаю что производительность это не забота программиста, а забота создателей языка на котором он пишет, производителей железа на котором этот код запускается и т.д. То есть медленный чистый код должен автоматически приводиться к быстром грязному коду
Проблема не в том чего хочет знать или не знать программист. Если отказаться от непроизводительного чистого кода, то бизнесу придется нанимать Senior и Middle там, где хватило бы одного middle и пачки студентов. А бизнес такого не хочет, сервера докупить дешевле...
нет на рынке столько Senior и Middle, чтобы покрыть задачи бизнеса сейчас их и сейчас-то нет, а если упарываться в производительность, то и подавно не будет
@@Firegalensk бизнес занимается пилежом бабла и погоней за свистопирделками тиктокерскими, поэтому программистов и не хватает :)) маркетологи шарлатаны накалывают владельцев бизнеса
Вот вам супер совет по клинкоду. Делайте что бы в микросервисе было не больше одной ручки, в редких случаях можно больше. Если надо что то дорабатывать, делаете новый репо с новой версией микросервиса. Это решает все проблемы, лапша код из одного АПИ-метода норм выглядит и работает быстро. MVC, DI, SOLID и прочий панос не нужны т.к. для одной-пары ручек это избыток.
Программисты раньше: Как мне уложить эту задачу в 512кб памяти? Программисты сейчас: берём тучу библиотек, плюс ещё тучу "на всякий случай", собираем из них какую-то программу - готово. Глючит, лагает? У вас просто оборудование плохое.
@@edranovdenis Я не об этом. Я тоже когда пишу например скрипты, юзаю библиотеки. Я о том, что на сегодняшний день никто не думает об оптимизации. Собрали как конструктор из библиотек софт. Вместе с ними набрали багов из-за несовместимости различных процедур и функций. И всё. Работает, бизнесу достаточно. Оставляем так. Через год, два следующий продукт, новая версия за отдельные деньги. Он лучше там больше возможностей, ура. Только комп ещё мощнее нужен, что бы ещё больше глюков переварить. Вот за что я уважал Эпл, так это то, что там боролись за оптимизацию... Раньше боролись.
Мне кажется, что бизнесу важнее именно поддержка продукта в долгую, а значит именно концепция клин кода будет выигрывать. Ведь если ты работаешь в команде, твой код должны суметь прочитать и остальные, при этом сразу поняв, что происходит. Но если ты соло разработчик, то конечно лучше сразу писать оптимизированный код, хотя в таком случае не факт, что ты поймешь, что писал нежелю назад)
Ну, 25 лет назад почти наверняка так и было. В каждом объекте - указатель на таблицу виртуальных функций. Вызов функции - по адресу, который берется в этом массиве. свич, почти наверняка, организовывался так же, только указатель на аналогичную таблицу - статический. Это если компилятор умел немного оптимизировать и аргумент свича - небольшое число, в противном случае - куча if-ов. Правда, подозреваю, с тех пор много воды утекло.
Я далек от программирования, но если я правильно понял - весь спор в "+" и"-" стандартизации, и применим он по сути к любой области труда человека. Исторически человечество приходит к стандартизации в той или иной мере в каждой области. Причина проста, для удовлетворения спроса в условиях ограниченного ресурса по созданию конкретного блага, мы сознательно занижаем максимальную планку требований к этому благу до уровня когда спрос будет удовлетворен, а так же сдвигаем нижнюю планку требований выше за счет масштаба. Но при этом никто не отменял различного рода уникальные или единичные изделия, где выдвигаемые требования не вписываются в общепринятые стандарты, просто производство таких изделий/услуг будет значительно дороже, поскольку потребует уникальных навыков, материалов, приспособлений и д.р.
Помню 2000-е, когда ООП-код на С++ руинил весь перформенс на процессорах с длинным конвейером от Texas Instruments. В то время как плохо-читаемый код на Си, написанный с учетом архитектуры, летал.
Всегда думал, что Clean Code - это не про скорость вот этой конкретной программы, а про то, как ее сопровождать, расширять, изменять в течение ее жизненного цикла, когда меняются люди, которые этим заменяются, т.е. про ее изучение кода, скорость его модификации, скорость исправления ошибок и их локализации. И вот с этой точки зрения написать новую программу зачастую много дороже, чем просто пойти и проапгрейдить сервак, которой что-то слишком медленно исполняет. А железостроители весьма неплохо увеличивали производительность своих поделок, поэтому якобы перечеркивание 12 лет прогресса - это на самом деле фундамент под удешевление сопровождения софта в течение десятилетий. Clean Code обеспечивает гибкость, приспосабливаемость, подход Кейси дает доминирование в текущих условиях. А потом прилетает метеорит Чиксулуб и погибшим динозавром интересуются только палеонтологи (читай, борцы с legacy).
Для бизнес логики в нетребовательных приложениях - чистый код. Для системного программирования и огромных, сложных софтин типа игровых движков - максимальная производительность. От чистого кода там будет мало потому-что ничего не поделать. И то и то используется и практикуется.
ммм, то-то я смотрю игры у нас пиздец какие производительные, не лагают никогда и у всех все идет в +100500 фпс в разрешение 16к, ага. А если серьезно, то у нас два главных движка это Анриал и Юнити и оба используют ООП.
@@dmitriyivanich1088не знаю как анрил, но в юнити конечно такое ооп царское, просто залюбуешься. Весь апи это статика в статике под статикой и статикой погоняет. Ах, ну да, там же наследование есть от MonoBehavior и полиморфизм на Update() и некоторые другие ивенты, ну это, конечно, да, всё меняет )
@@dmitriyivanich1088 И в обоих лютый говокод и никакого CleanCod-а, тонны багов и отсутствие хорошей производительности. И таких проектов большинство, компании даже могут и не знать об этом, спасибо техлидам и менеджерам, т.е где как повезёт)
@@dmitriyivanich1088 Вспоминаю, как в конце 90х - начале 2000х играл в анрил турнамент (ещё тот, первый) на первом пне на 150 мегагерцах и 16 мегабайтах оперы, и первой вуду 3дфх. Сейчас гигагерцы и гигабайты, это вроде в дохера раз больше, а всё что по сути изменилось - текстуры покрасивше да полигонов побольше. Как-то не пропорционально
Их дебаты можно было бы свести к другому аналогичному вопросу: "На чём бы вы хотели писать программу: на условно Питоне или на ассемблере? А почему? Ведь на ассемблере же быстрее работать будет..."
Такое ощущение, что люди забыли историю развития программирования и откатились лет на 10-20 назад ко временам, когда ещё не сделали популярные нынче "простые языки", которые изначально и сделали, чтобы было более удобно для людей в ущерб производительности. Странно почему не откатились ещё дальше ко временам, когда чуть ли ни самостоятельно ОС нужно было писать каждый раз для каждого железа. А что? Ведь тогда всё ещё быстрее работать будет, ведь не будет лишних функций.
Супер видео! На самом деле, я давно уже на практике заметил насколько субъективно понятие КлинКод. Поработав в 4 разных компаниях, с 4мя лидами - увидел 4 типа этого самого 'клина'. И попробуй им доказать, что их КлинКод недостаточно клин) Как по мне, самое главное в сегодняшней разработке, чтобы в команде были четкие, закрепленные подходы к разработке. Но на их описание нужно потратить уйму времени
Тут просто нужно понимать где и что использовать. Это два противоположных подхода для противоположных задач. 1) Clean Code - очень удобен на огромных проектах, со сложной GUI и множеством различных данных. Т.е. в общих чертах - это организация процесса получения и обработки данных. И тут не важна скорость т.к. это только подготовительный этап, либо не нагруженный из-за того что одет ожидания данных от пользователя. 2) Второй подход - очень удобен именно в обработке информации, а так как объемы вычислений не соизмеримые с первым подходом, то и скорость по этому растёт. То что используется как примеру - это как "из пушки по воробьям" - абсолютно бесполезно, но только если воробьев не много, а вот если их миллионы - тут уже совсем другое дело. Исходя из этого получаем то, что нужно использовать оба подхода и каждый в своей стихии.
"Кейси мало на что повлиял" - оно, конечно да, с т.з. общемировой практики, Но в конкретно взятых проектах, например в embedded разработке, останется меньше вопросов тогда, когда ты хочешь создать быстрый, отзывчивый код. Спасибо за видео!
Разносим каждую фигуру иерархии в отдельную библиотеку, написанную не то что отдельным программистом, а отдельной конторой. А теперь расскажите мне про свитч
@@ВладимирЧескидов У него мысль что пример не корректен Перечисленные концепции создавались для огромных проектов офисы браузеры иде смм А сейчас эти принципы начали на серьезных щах внедрять в проекты уровня хелоу ворд
@@ВладимирЧескидов Попробую на пальцах объяснить, упрощённо. Код не пишет 1 человек. Работа делится на несколько человек или несколько команд, каждая пилит свой кусок максимально изолированно от остальных, чтобы не мешать друг другу, не вносить свои изменения в код другой команды. А свич требует в любой ситуации взаимодействия с объектом проверять его тип и выбирать соответствующее действие, таким образом все команды будут стукаться лбами в каждом свиче, добавляя туда свои типы объектов. Помните письмо Дяди Фёдора, которое дописывали то кот, то пёс? Вот примерно так, только в тысячу раз хуже и с матами))
Байто- и такто*бы не осознают реальности разработки ПО. Им кажется, что можно всё ускорить в стопицот раз, написав весь код линейно, без этих ваших абстрактных фабрик и визиторов, но они не понимают, что именно благодаря всем этим штукам и получилось написать столь огромную хреновину в довольно ограниченное время, распределив работу на большое количество человек.
Дядя Боб всё верно написал! Оптимизация не должна наступать на читаемость, потому что потеря читаемости в дальнейшем приведёт к падению оптимизации. Оптимизацию должны выполнять компиляторы, на уровне asm нет никакого полиморфизма, только jmp.
я пишу код для алготрейдинга, который должен отреагировать на изменение данных и уложиться в минимально возможное время. Цель не выходить из 1мс. Вот тут и приходит необходимость задуматься и над структурами данных, типах данных, циклах и кол-ве операций процессоров, кол-ве ядер, размещении данных данных в памяти, кеше и прочем. Но за 15 лет работы до этого, в этом не было необходимости и я не занимался профайлингом на уровне микро/наносекунд как разработчик.
Всё зависит от задачи, и производительность - один из пунктов ТЗ. Большинство софта вообще крутится не на пользовательских ПК, и является довольно сложным, чтобы писать его на ифах/свичах. Часто там вообще не важна скорость, главное - возможность без проблем нанять новую команду для поддержки этого монстра, и чтобы они не повесились, добавляя какой-нибудь мелкий функционал))
оба правы. Clean code хорош, на примерах фигур, но посмотрите на все эти визиторы и фабрики в исходниках хромиума, когда нужно держать в уме по 10 модулей, чтобы понять как оно там работает и что править/менять. функциональное программирование имеет меньшую когнитивную нагрузку, имхо
проблема функциональщины в том, что код пишется буквально задом наперёд. Да, оно работает, и иногда работает хорошо, но очень уж специфично для восприятия здоровым человеком, не обременённым учёной степенью по математике))
@@0imax "буквально задом наперед" - это далеко не всегда. в некоторых функциональных языках можно определять переменные после выражения (например блок where), можно создавать лямбды частично применив функции и тогда применение функции к аргументу будет идти "справа налево" или использовать правоассоциативные операторы композиции, но все это опционально и никто не запрещает использовать левоассоциативные операторы и префиксное описание переменных (блоком let). Я бы не сказал, что это сложнее чем держать в голове что оператор () или + могут быть виртуальными или перегруженными
@@vatne4eg Скобки, плюсы и другие операторы перегружают в весьма специфических случаях) Ну и не все пишут на С++, где разрешены такие извращения (на самом деле иногда полезные).
На самом деле спор ни о чем. Там где нужна производительность - пишут производительный код, но в современном мире большинство программ работают с I/O нагрузками, и плевать сколько тактов процессора тратит программа, если потом сидит и ждет ответ от сервера/базы данных/чтения файла/действия пользователя и кучи чего еще.
Для бекенда производительность очень важна, которая напрямую влияет на расходы кол-ва серверов и их поддержку и кол-во пользователей которые смогут использовать один сервер в локации. Для любого софта который работает с графикой и большими вычислениями, перечислять можно долго.
@@fein7068 да, интересно какая там производительность у Бэка на джаваскрипте или питоне) С графикой согласен, но там и используют производительный код, я ж пишу, где что надо, там то и используют.
@@fein7068 хочу глянуть на этот производительный бекенд на джаваскрипте или питоне) А для графики и математики, да производительность нужна, но я об этом и говорю, где надо, там пишут производительный код, где не надо - лучше писать чистый)
Изобретение правил ради только лишь их соблюдения, а не решения конкретной проблемы - это один из главных признаков "погромиста". И главное отличие "погромиста" от "программиста".
Одна из самых грамотных мыслей в комментариях, и как обычно, в самом низу по количеству "лайков". Людям часто не нужно "решение проблемы", им нужно подтверждение своей правоты. Причём это справедливо как для поставщика услуг, так и для потребителя.
Правила эти появились не на ровном месте, и не для слепого их соблюдения. Если писать большой софт, намеренно игнорируя все практики клин кода, получится абсолютно неподдерживаемое нечто, где внесение мизерных изменений будет стоить несоизмеримо много человеко-часов.
@@0imax Эти "правила" являются набором догматов, не подкрепленных ничем, кроме субъективных впечатлений и _личного_ опыта. По сути, это религия, то есть полная противоположность научному подходу. Какой-то персонаж решил, что функция не должна быть длиннее 20 строк, к примеру. Или что цикломатическая сложность должна быть не более чем сколько-то там. И всё, толпа овец побежала исполнять. Потому что это же великий (Подставить имя тут) так сказал, посмотрите, он миллиард заработал в 20 лет, плохого не посоветует. Даже и не думая, зачем и почему, ради мнимой простоты чтения и поддержки. Даже не задумываясь о том, что десять функций отладить сложнее, чем одну, просто потому что человеческий мозг - не стековая машина, и он не приспособлен к хранению контекстов. А ведь мы программу пишем, а не духов вызываем. Это самый простой пример.
@@0imax С остальными "правилами" точно так же. Ни одно из них не является непротиворечивым, работающим независимо от иных условий. Практически любое из них легко довести до маразма, написав код, который будет идеально соответствовать всем этим указаниям, но при этом будет невероятно усложненным и совершенно неподдерживаемым. Если бы эти "правила" были чем-то научно обоснованным, а не набором догматов, то их невозможно было бы довести до подобных предельных случаев. К примеру, возьмем наследование. Вы можете сказать, что это всё придирки, что нужно ограничить количество уровней абстракции разумной глубиной и все возрадуются. Скажем, 3 уровня. На что вам пять программистов скажет, что должно быть четыре или два. Ещё пять скажут, что наследования быть вообще не должно и нужны лишь интерфейсы. А потом подойдет школьник и заявит, что классический полиморфизм вообще не нужен, что это ерунда для старых пердунов, а примеси - это истинный путь в следующий век. И никто из них не сможет предоставить четкие и формализованные, фальсифицируемые критерии, почему именно _ОН_ прав. Которые у всех сойдутся, и с которыми все придут к одному и тому же выводу. Потому что субъективная херня всё это. Конструкт в голове, способ самовыразиться и собрать бабла с тех, кто готов покупать книжки с этой писаниной.
@@alexanderd.7818 Аксиома Эскобара говорит, что любые крайности - плохи. Не нужно воспринимать книгу как абсолютную истину, и не будет ни проблем, ни срачей по поводу))
По собственному многолетнему опыту могу сказать, что оба подхода релеванты в зависимости от задачи, инструментов и прочих факторов при написании софта. Клин код хорош в случаях, когда производительность не важна. В крупных проектах так же часто приходилось искать компромиссные решения: удобство в понимании кода против производительности в отдельных местах. Самое сложное в данном вопросе, понимать когда можно себе позволить четкую сегрегацию по клин коду, а когда нужно придержать коней и выдать максимальную производительность. Многие этого не умеют :)
OCP - это не про наследование, а про расширяемость базового класса без необходимости его изменения. Это можно достичь разными путями. KISS - не про имена переменных, а про общее стремление к простоте системы. Сложную систему сложно поддерживать, больше шансов, что в ней что-то пойдёт не так и есть скрытые проблемы. Это базовый инжереный принцип, что в механике, что в электронике, что в программировании. Ещё можно было бы упомянуть YAGNI - в целом про овер-инжиниринг, преждевременную оптимизацию и желание написать супер-абстрактный код на все случаи жизни. Про вред наследования(ну и полиморфизма) писали ещё в GoF 30 лет назад. И дело даже не производительности. То, что абстракция бьёт по производительности - это common sense, те же споры C++ vs C я видел и 20 лет назад. Даже у Страуструп писал о то, что полиморфизм - это -25% от производительности. К слову, Clean Code - это больше про Java(ну и отчасти C#), где ООП по полной программе и свои особенности. То, что это сильно бьёт по производительности в примере про вычисление площади - ничего удивительного, по сравнению с простой арифметической операцией оверхед на виртуальный вызов слишком большой. То, что инкапсуляция - миф, это правда. Во многих ситуациях приходится лезть в исходники, чтобы понять, как лучше работать с этим кодом. Чувак набросил знатно, конечно. Оценивать парадигму по скорости вычисления площадей фигур - это полная глупость. Очевидно, что любая абстракция - это оверхед. В реальной большой системе этот оверхед на фоне всей логики уже не так заметен. В Java/C#/Python/V8/Golang есть ещё сборка мусора, например. Давайте хейтить их за это. Если посмотреть на бенчмарки языков, то C++ лидирует по всем показателям, он в разы быстрее перемалывает числа. Однако, если сравнивать веб-фрейморки, то почему-то в топе фреймворки на Rust/C/Java/JS. Единственное исключение - это возврат простого plain text в ответе. Почему же язык такой быстрый, он так быстро вычисляет площади фигур, а фреймворки на нём медленные? Потому что высоко-производительный код - это сложный код. Сложность кода накладывается на сложность системы, в итоге получается монстр, который нереально трудно поддерживать. Этот монстр ещё и сложно написать. Несомненно, код на Rust или C будет быстрее кода на C#/Java. Помню лет 15 назад были срачи на тему C++ vs C#, в относительно сложных системах действительно C# процентов на 20-30 медленнее(по-крайней мере на тот момент, сейчас разница уже меньше). С ростом сложности системы разница становится всё менее заметной. В реальной жизни бОльшую роль играют алгоритмы и понимание разработчиком особенностей выбранного языка/рантайма/фреймворка. Я лично видел примеры, когда разработчик умудряется создать экспоненциальную сложность там, где можно было бы сделать константную. Разработчик должен понимать, как выделяется и освобождается память в его программе (я говорю и про ненужные выделения, про копирования, про работу GC), понимать вычислительную сложность своего кода.
1. GoF писали "наследование вредно, давайте не будем его использовать"? Можете скинуть цитату? 2. "Инкапсуляция - миф" - это как? Вы утверждаете, что невозможно писать классы и интерфейсы, которыми можно пользоваться, "не заглядывая под капот"? 3. Если глупость - рассматривать пример из книги Боба, то что должен был сделать Кейси, чтобы обсудить с Бобом проблемы clean code? Достать код, к которому Боб не имеет никакого отношения? 4. Далеко не всегда код на C++ будет быстрее чем на Java или C#. Зависит от задачи. Зависит от качества кода. От затраченного на код времени. Среднее по больнице не имеет смысла для принятия решений.
С производительностью ****** везде, один веб чего только стоит с зоопарком фреймворков, смотришь профилирование и ужасаешься всему тому *****, что вылетает там
По моему личному мнению, ты можешь использовать фреймворк в том случае, если у тебя достаточно навыков написать такой же если у тебя будет достаточно времени
@@MrrrMrrrMrrr Все правильно написал @BlackFox11. В свое время фреймворки и появились благодаря тому, что надоело реализовывать все время одни и те же части приложения. Ты знаешь как, знаешь зачем и почему, но писать снова и снова... Собрали в "одну кучу" и получили фреймворк (грубо говоря). Понимание того как оно работает под капотом дает понимание что и где использовать в своем проекте и как это повлияет на скорость работы. Сейчас некоторые умеют только во фреймворки как в "отдельный язык программирования". Не умеешь написать свой имея 100500 часов в запасе (т.е. не обладаешь теоретическими знаниями и пониманием зачем его писать) - значит не достаточно практики - пиши на js и jquery пока не поймешь что что-то ты делаешь не так и не поймешь что тебе надо))
Одним предложением всё решается: воспроизводство железа проще и дешевле, чем воспроизводство программистов, и значит жертвовать железом выгоднее,чем человека-часами.
Я хоть аналитик и как Прогер где-то застрял в районе Джуна, думаю, что в плане удобства взаимодействия Clean code топ и там где производительность не является критичной, лучше использовать этот подход, но там где производительность критична, там уже надо оптимизировать даже если будет не клинкод. В общем всё зависит в первую очередь от задачи. Мы и правда сейчас живём в мире, где железо достаточно мощное и достаточно неплохо переваривает не самый оптимизированный код, но это также не означает, что можно говнокодить.
Самые тормозные штуки, которые видел, писали для небольшого количества данных, а потом данных стало много или назрузка увеличилась и все зависло. И без клинкода такие штуки улучшать (оптимизировать, масштабировать, переписывать без тестов) - это адище. Клинкод как раз направлен на то, чтобы этот процесс упростить. А есил у вас клинкод не упрощает - значит вы делаете что-то не так и не понятно для чего вы это делаете и так это применяете... Был один проект с устаревшим кодом и решили ребята его переписать с нуля, понахватались где-то трендовых вещей: микросервисы, go и прочее. И давай писать, 1.5 года писали, ни хрена не смогли. Так что если кошки вам не нравятся - значит не умеете готовить.
Неужели никто «Искусство программирования для Unix» не читал? Эта тема стара как Unix 😁 Эрик Раймонд в этой своей книге уже давно обо всём этом писал. И критика ооп и постулат о приоритете стоимости человеко-часов над стоимостью процессорных циклов. Да. Вот так и живём 🤷♂️
Кроме проблемы молотка и гвоздей важно помнить о стандартизации. Как было сказано, клин кодом и его подходом пользуются миллионы. Это позволяет быстрее понимать и изменять проект. В то время как типичный Кейси может понаписать такого, что все будет работать в 20 раз быстрее, но он один будет понимать, что вообще происходит. Интересно было бы увидеть книгу в духе optimized code с паттернами написания оптимизированного, но гибкого и читаемого кода.
@@etodemerzel2627 а зачем нам сажать кучу разработчиков за один проект? чтобы ускорить его разработку и сохранить поддерживаемость. По моему Кейси попытался всем доказать что лучше качественно чем быстро и дешево😁
В начале 90ых, когда железо было, мягко говоря не очень производительное, писали мы лабы на бейсике, рисовали они себе круги, вычисляли массивы... Мой же пытливый ум, прочитав в журнале наука и жизнь про игру "жизнь", решил ее визуализировать. Правила простые, накидал за одну перемену. Однако смотреть на это было невозможно, каждый цикл прорисовывался с минуту. Организмы рисовались просто символами, никакой графики, но вывод функциями Бейсика принт. В итоге заморочился выводить символы, записывая их байты прям в видеопамять. Как же я охренел, увидев, насколько всё полетело. Пришлось даже задержку добавлять, чтобы можно было насладиться анимацией циклов жизни. Говнооптимизация, отрывает прогу от железонезависимости. Ни на чем, кроме тех хт это уже не будет работать, зато какой эффект.
А у нас в расте вообще нет ООП, зато свич один из самых мощных. Это к тому, что всё это давно не секрет, причем настолько, что задизайнено в основу языка.
Первое правило оптимизации: не оптимизируй. Молли просто молчит про это, оптимизируя код там, где он типа медленный. На практике расчёт площади может делаться 1 раз за запуск, и будет абсолютно насрать на его перф.
В чем проблема писать места не требующие производительности с использованием clean code, но если требуется, то оптимизировать только определенные места.
Эм... Я типо программист. Даже дипломную скоро сдаю. Вопрос: почему я об этом узнаю только сейчас? У нас в колледже даже по ООП прошлись мимолетом. Посоветуйте курсы по программированию. Есть что то по типу CS50?
Очень забавно слышать про "20 раз быстрее". На практике всё может быть куда веселее. Когда вместо простого массива значений, заводят для значений целый отдельный класс с интерфейсами, интерфейсы оных суют в хэш мэпу, а её суют в абстрактный класс, а сверху наворчивают наследование из нескольких классов... Производительность проседает в 10-20 ТЫСЯЧ раз. Реальный случай из практики.
Ну то, что несмотря на весь прогресс железа, программы становятся все монструозные и работают все медленнее - это факт. Мой свежий ноут грузится и грузит докер десктоп или идею с плагинами или вскод с плагинами, уже столько, что, извините, я успеваю сходить поссать за это время. Мой PC AT в середине девяностых грузился и грузил среду разработки с СУБД гораздо быстрее.
Ага. А когда я сажусь написать чего-то для своих ретромашин, мне почему-то больше нравится современная IDE с подсветкой синтаксиса и подсказками. Вы не захотите вернуться в вашу среду разработки середины 90-х.
Бля, я бы посмотрел как бы этот Кейси разрабатывал и поддерживал проект из дохульярда строк, который одновременно пилят 20 разработчиков, а в общей сложности над ним работают 500 человек. И ответ на вопрос "навернет ли твое изменение все к херам" буквально стоит миллионы.
А вы не заметили что раньше вам хватало 1 гб оперативки, а теперь уже 16гб мало. Это такой же принцип. Раньше больше парились по поводу оптимизаций и скорости, с развитием железа все меньше этим парятся, делают упор больше в сторону удобства разработки, поддержки. Правильно это или нет, это уже другой вопрос. Мне интересно что будет если АИ напишет очень скоростной и оптимизированый код, насколько сложно человеку будет поддерживать этот код. Если в будущем АИ сможет и сам писать и сам поддерживать, тогда АИ нет смысла придерживаться клин кода, он может использовать максимально оптимальную модель которая даст максимальную скорость и будет использовать минимальное количество ресурсов.
А вы не заметили что сейчас приложения имеют гораздо больше функций и гораздо более дружественные к пользователю? А весь этот такой естественный дополнительный функционал который вы не замечаетет тоже тянет ресурсы. Может потому 1Гб уже не хватает, а не только от отсутствия оптимизации?
@@dmaraptor Во-первых, это не совсем правда. Многие современные преложения/сервисы почти не отличаются функционалом от старых, но тем не менее едят в сотни раз больше ресурсов. Во-вторых, то что у приложения больше функций, не значит, что оно должно есть в сотни раз больше ресурсов, когда пользователь не использует эти самые функции.
Мне кажется, тейк про перфоманс в мире, где питон является одним из самых популярных языков в мире и, в тоже время, одним из самых медленным, как минимум странно. 2 язык выбирается под задачи. Если нужна производительность - бери низкоуровневый функциональный язык. Нужны интерфейсы - ооп языки в помощь) 3 любые тесты по сравнению производительности надо перепроверять, так как уже не раз сталкивался с «экспертами» которые находят в версию компилятора или интерпретатора с багами с каким-то кейсом и потом показывают «объективные» результаты) 4если это большой проект, который пишут 10 лет, то без солида, дизайн паттернов и подходов из разряда «best practices» код изначально станет легаси.
с удовольствием просмотрел видос. Оба, Кейси и Боб имеют хорошие факты. Если первый, показывает что CLEAN CODE бывает что нагружает железо, а второй говорит что оно помагает не железу, а будущим людям которые будут работать в этом проекте, то тут невозможно сказать что всегда надо придерживаться одной методологии, ведь бывает что бизнесу нужна обычный продукт, которые будет работать (неважно быстро или медленно, а главное работало), а есть бизнес которой важен не то как "удобно" читать, а как БЫСТРО оно работает. Я считаю что надо найти баланс, если проект нуждается в производительности, а оптимизировать нечего - надо отказаться от принципов CLEAN, а если скорость неважна - то CLEAN лучше. P.S. ВСЁ ЕЩЁ ЖДУ 10 ЧАСОВОЙ ТУТОРИАЛ ПО С++
Надо смотреть ситуации когда работают большие команды программистов, которым приходится плотно взаимодействовать. Тогда на первый план выходит архитектура и интерфейсы и соответственно "клин код" или нечто подобное выходит на первое место иначе просто все развалится. Но при этом нужно понимать где есть узкие места , требующие оптимизации и вот там уже можно изголяться, чтобы достигнуть нужной производительности.
1. Подавляющее число оптимизаций в коде в виденном мной прикладном коде упрется в то, что запрос в БД своими миллисекундами перекроет оптимтзации прикладного кода. 2. Кроме этого вашего Мартина есть Фауллер, который про "полиморфизм vs switch" говорил, что многочисленные свитчи по одному enum'у, разбросанные по коду, замедляют внесение изменений. С чем согласен: не раз по просьбе аналитика, желающего добавить или убрать новое значение enum'а, составлял список использований этого enum'а в давнокоде.
То что чистый код тормозит всегда было известно. Еще в книге "Рефакторинг кода" об этом говорили - быстрый код преобразуется в чистый. Неудивительно, что код, который пишут железнячники сильно отличается от кода прикладных программистов, потому что первые что-то знают :-) Проблема быстрого кода в том, что при обрастании функционалом объем кода растет и поддерживать его будет нереально сложно. Скорее всего решение должно пойти в сторону компиляторов, которые должны преобразовывать чистый код в быстрый, т.е. преобразовывать интерфейсы в if/switch и тому подобные вещи :-)
Компиляторы не помогут. Распаковщик unrar для ZX Spectrum (автор AIG) изначально был сделан из C, скомпилированного ВРУЧНУЮ. Я оптимизировал его в 11 раз за счёт генерации кода разбора дерева на лету. Распаковщик JPEG для ZX Spectrum (автор >>RRA>>) изначально был сделан из ассемблерной программы для 68000, переведённой на Z80 ВРУЧНУЮ. Я оптимизировал его в 5 раз за счёт вылизывания трёх главных операций - выборка из битового потока, IDCT и пересчёт в экранный формат. Про 3D-движки даже говорить нечего, там всё прямо по регистрам раскладывается + используются вычисляемые переходы и патчи. Посмотрите игру Borsch.
@@edranovdenis Не знаю, но конструкции на языке программирования наверное должны задавать не то, какой результирующий код ты хочешь получить, а какое внешнее поведение ты хочешь получить. Наверное для этого придется отказаться от каких-то базовых понятий, как таблица виртуальных методов - не факт что она всегда будет создаваться для заданного класса.
@@edranovdenis Ага, чтобы всё поведение программы зависило от GPT. Сегодня всё работает, а завтра оно решит, что вы расист и половину функций вам отключит.
7:16 Скорее всего, "чистый код" сделан для того, чтобы люди поняли, как писать *ПОНЯТНЫЙ*, а не компактный код. А еще, всем новичкам было бы неплохо прочитать эту книгу
Вся ценность этого видео в том, что нельзя просто взять и применить какие-то принципы и получить оптимальное для данной задачи решение. Всегда приходится думать.
Ну понятно, что ничего не понятно. Вроде бы хочется скачать что performance и clean code это противоположности, но там вылезает Кейси и говорит что его подход читабельней. Вопросик. А как будет вести себя Архитектура Кейси в Громадном проекте? Будет ли его код настолько же читабельным. Я не разбираюсь, но мне кажется что прогеры отошли в сторону Clean Code именно по этой причине, а перформанс остался для узких мест, и его как модуль можно вставить в Clean Code в места где это действительно важно, и вот тут как мне кажется Clean Code недоработан... Жаль что я не знаю ответа на свой вопрос.
А где подтверждение, что Clean Code действительно делает код читабельным? Сплошной карго-культ. Никто не знает как на самом деле, но зато все верят. Подход Casey не столько про производительность, сколько про делать логично с учётом архитектуры компьютера. Такой код будет иметь хорошую производительность без лишних телодвижений.
Пожалуй, даже не сам браузер. Достаточно посмотреть на диспетчер Хрома, чтобы увидеть страницы с потреблением памяти от 100 до 400 Мб (каждая). И добавить к этому client-side rendering всяких фронтов на модных фреймворках - и здравствуйте! - проц фоном потихоньку "что-то майнит", пока грузит страницу ютуба Например, Notion складывает в куки браузера по 4 гигабайта в фоновом режиме…
ну вообще, оптимизация поскорости != оптимизации по используемой РАМ. вполне себе что быстрый код, может кушац больше оперативы чем медленный, но это не точно.
Именно так. Просто посмотри размеры и потребность в ресурсах компьютера MS Office 97, 2007 и самый последний. А по функционалу разница не велика. Причем большинству и функционала самой старой версии предостаточно.
С точки зрения работы ПО, 90% кода работают в редких случаях, допустим раз в день, месяц, год, а 10% кода программы отрабатывают постоянно в бесконечном цикле. Так, может тогда, на B-версии программы отпрофайлить наиболее нагруженные участки и переписать их без виртуальных функций, полиморфизма и подобного. - а 90% оставить в нормальном удобном виде.
Работая более 10 лет в ИТ на разных позициях, не могу не заметить одну грустную тенденцию: Если раньше на собеседованиях требовали понимание UML и умение им пользоваться, то сейчас на входе в каждый офис спрашивают про SOLID, паттерны и так далее. То есть, от умения проектировать и излагать решение мы перешли графомании-говнописанию, взяв за "стандарт" свод рекомендаций от чего страдает и индустрия и конечный пользователь. С легкой руки говнокурсов и solid-культистов у нас каждый второй джун может сшлепать абстрактную фабрику, но никто не сможет объяснить как это решает стоящую задачу и почему именно фабрика. Если говорить о вкате в IT и менторинге в IT, то clean code принципы должны быть на самом последнем месте, следом за паттернами. Потому как рекомендации должны отвечать на вопросы, появившиеся в процессе практики, в противном случае это превращается в очередной говнокульт аутистов.
Текущая ситуация просто замечательная: Бизнес тратит овер 9000 тонн нефти на SRE/Platform Engineers, потому как погроммисты не могут ни в бизнес, ни в архитектуру того, под что разрабатывают. Все это виснет-глючит, сыплет исключениями и срет логами дай этому нагрузку.
Думаю да проблема не в "чистом коде" и иже с ними, а в том что он не дополняет цепочку необходимых умений, а заменяет. Увы. Я не буду рад как соискателю который только и умеет в чистый код, но и не буду рад тому кто думает и пишет так что из код можно носить как свитер. Достаточно долго проработал на одном проекте, где бизнес требований помодульно было выше крыши. Спустя время начали расширять команду и когда поприходили молодые и в разговорах начало всплывать SOLID, DRY и т.п. начал комплексовать - неужели я так отстал... Почитал и понял что это давно ясная истина в обертке для любителей смузи или на скорую руку новых специалистов. То что приходит с практикой просто заменили "быстрой теорией" (а практику не прилагают).
@@hardcoreeptu Бизнес тратит овер 9000 тонн нефти... Это потому что бизнес не хочет всех этих сложных схем. Ему нужно прямо сейчас пока Вася Пупкин не написал быстрее и не вышел на рынок. Или просто не хотят, не могут услышать. Или зачастую некому предложить и обосновать подход к решению вопроса в котором стоит планирование и стратегия развития самого кода.
@@hardcoreeptu Также бизнес тратит огромные бабки на урегулирование отрасли все теми же методами, которые привели к такому поожению вещей, что сравнимо с тушением костра бензином. По типу: мы потратили человеко-тысячеления и миллиарды и придумали эджайл с микросервисами, лишь бы не увеличить ФОТ отдела разработки. Правда его все равно придется увеличить, наняв менеджеров, аналитиков и скрам-мастера, и поставив во главе бестолочь с гордым названием "архитектор" но это другое, вы не понимаете : ) По сути, это карго-культ. Но иначе не получается.
Как же я надеюсь, что с развитием нейронок программисты хоть обложатся со всех сторон клинкодом, хоть маркером интерфейсы рисовать будут и потом будут двигать ноды, но в итоге нейронка, будучи прослойкой на пару с оптимизатором компилятора, будет ориентирована на оптимизацию того, что получилось, следуя принципу: сохрани функциональность такой, как хотел мясной, но бесконечно стремись к оптимизации. Вот только компании, которые это бы могли внедрить давно забили на своих пользователей и на их комфорт. Некоторое даже открыто говорят "все лягает, да? Так купите себе нормальное железо, мы то тут при чем?", а самим производителям железа это даже выгодно. Делать все более красивые цифры, которые фактически не привносят улучшений, по тому что ПО жрет все больше, не давая улучшений. Я последнее время открываю многие программы к старым версиям по той причине, что функционал либо не изменился, либо изменился незначительно, а жрать они стали заметно больше, так еще и стабильность уменьшилась. В целом скажу так: я надеюсь на оптимизацию, но не верю, что большие компании почешутся, пока под их ногами не будет гореть земля от критики оплёванных клиентов
@@АлександрОрлов-п9ч Так же, как сейчас все остальное делают с нейронками. Обратное распространение ошибки в случае, если код работает не так, как ожидалось. А про контроль... Ты же не проверяешь за компилятором, во что он превратил код? Вот и тут проверять никто не станет просто так. Если что-то не так, нужно лишь сопоставить с оригиналом кола и если там все работает, то дать нейронке обратную связь. Она скорректирует веса и даст новый ответ. Но что-то меня в нейронную базу понесло. В общем, я ожидаю то, что легкочитамый говнокод станет чем-то типа промпта для такой нейронки, а в ответ она выдаст уже что-то адекватное. Далее может быть ещё несколько генераций, итерации проверок и тестов производительности. Лучшее будет выбрано и в дальнейший тест на соответствие хотелкам человека
О! Наконец-то кто то решился разобрать по фактам весь этот оверинженеринг, который пропагандируют с каждого утюга.... простой пример - любой учебный проект типа Hello World на чистом коде это 100500 разных абстракций погоняющих друг другом, черт ногу сломит понять где что и зачем... а надо то всего std::cout реализовать. а потом удивляемся что софт лагает, пишут то его те кто по таким учебникам учился.
не знаю как в других сферах, но в web всё лагает из-за фронта. И вот фронтеры как раз преисполнились, отреклись от богомерзкого клинкода, ооп и прочих ваших задростких штук. А по итогу на 12-ом поколении intel ютюб безбожно лагает. И лагает не подгрузка видео или ещё чего-то, а именно фронт. Вот пока пишу этот комментарий, горю от киселя, вместо ввода. На моём, хоть и не большом опыте, бэк в вебе тормозно работает либо совсем с большими данными, либо когда как раз избегают "оверинженеринг" и не переносят в какие-нибудь очереди то, что должно быть в них.
Кейси, кстати, крайне недооценён имхо, но это идёт на поправку. Его сейчас в том числе достаточно известный ThePrimeagen пиарит. Сейчас вообще достаточно интересные события и персонажи из сферы программирования на ютубике пробиваются :)
Вот вроде видос ни о чем, просто про срач двух айтишников, но подача аргументов и примеров делают видео очень интересным. Хорошо преподнес тейки Кейси. Думаю можно было даже побольше показать примеров плохого/хорошего кода. Кароч спс за видос, было очень интересно
Всё что я понял из видео, так это то что, если мы программируем что-то маленькое, то можно использовать клин код, чтобы сделать это быстрее, а если делаем что-то больше, например АААА игру, то нужно всё оптимизировать обычным старым кодом.
Тотал коммандер, новороченный по самое нехочу файл менеджер, с огромной библиотекой расширямый плагинов, занимает всего несколько мегабайт. Простое приложение ютуб на телефон, с мимимуи функций , жрет больше гигабайта. Что то определенно пошло не так в мире программироваания за эти годы )
Тотал коммандер - единственная программа, которой я продолжаю пользоваться с тех пор как у меня появился первый компьютер. К слову, он вроде на паскале написан.
Ни разу я еще не видел, чтобы бутылочное горлышко какой-либо программы было в виртуальном вызове. Ну и самом собой, что какую-нибудь суперкритичную алгоритмику нужно писать не как программисту удобно, а как машине проще считать. Тут ребята оба правы и странно что они не сошлись на едином мнении.
Я ещё помню те времена, когда говорил, что преждевременная оптимизация -- источник всех бед :) Все эти микрооптимизации хороши до первого сетевого запроса или неоптимальный выборки из базы, которые съедят всё, что вы наоптимизировали
Полная цитата говорит именно об этом: "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%."
@@sergei_sergeich и потом мы получаем игры, которые по графике хуже игр 2000 но требуют 4090. Да хули заморачиваться писать оптимизированный код, если можно быстро тяп ляп хуяк и в продакшн. Правда в том, что писать оптимизированный код не сложно и не долго, но приходит с опытом. Ты просто уже на автомате знаешь какие конструкции и алгоритмы быстрые и сразу их пишешь. Программирование с опытом становится стенографией, где ты пишешь код на автомате. Твоя цитата человека, которому похуй на код и его производительность. Ему надо нанять джунов, которые за два рубля напишут любой работающий код и он сможет продать это за сотни рублей.
@@sir.Geronisтормозные игры - плохой пример, потому что геймдев - это одно из исключений из правила о преждевременной оптимизации, т.к. о скорости работы нужно заботиться на всём процессе разработки. Ну а появляются такие тормозные игрули из-за того, что даже те самые 3% из цитаты не подвергаются анализу производительности, и лепится всё "как есть". С таким подходом писали тормозное г-но и без всякого клин кода.
@@0imax игры эьто очень хороший пример. Но если тебе не нравится. То давай возьмем офисные приложения. Которые весят десяток ГБ, требуют не один ГБ памяти, только для запуска, а для полноценной работы требуются еще несколько ГБ. И в тоже время есть альтернативные офисные решения где в десятки раз меньше ресурсов требуется. А мобильные приложения, калькулятор 120МБ. Банковское приложение 500МБ. И тп. Таких примеров милион. Просто надо открыть глаза и прекратить сыпать в них соль. А игры это просто самый наглядный пример, где слово оптимизация потом взята за аксиому.
А знаешь, из-за чего появляется по-настоящему фиговая производительность в больших проектах? Из-за того что один программист наоптимизировал всё, влепил внутри одной функции, а другой вызвал эту оптимизированную под 1 задачу функцию в немного другой задаче, где половина этих операций совсем не нужна. От того, что люди пишут не очень чистый код, другие просто их не понимают полностью и ломают производительность ещё больше, чем если бы код был чистым.
На сколько помню, в самой книге данная тема была частично затронута как "преждевременная оптимизация", в ней говорилось примерно о том, что эффективнее писать clean code, а затем оптимизировать если нужно. P.S. Как-то смотрел source код blender, подробно не изучал, но по первому впечатлению он довольно читаемый, особенно для C. При этом я не помню чтобы в самом blender интерфейс как-либо подтормаживал. Плюс опять же какие-нибудь "такты процессора" это уже проблема компилятора как по мне.
Раньше уповали на то, что производительность железа каждый год увеличивается в 1.5-2 раза, так что это было не так важно. Сейчас хоть и другие времена, но всё равно время разработки обычно важнее производительности: хорошо платить программистам меньше за меньшее время работы и получать больше за частые нововведения.
На самом деле если ты разбираешься в том, как работает весь этот ООП на низком уровне, понимаешь какой код генерирует компилятор, с умом используешь все его фичи, собирать с проект с опцией -О3, то ты можешь писать производительный клинкод, работающий ничуть не хуже кода, ООП не использующего (а если ещё применять параллелизм и simd, так вообще всё будет летать). Проблема в том, что это верно только для языка C++, т.к. программы на нём компилятся непосредственно в машинный код CPU, и представлять себе, какой код будет сгенерирован из той или иной строки исходника при должном опыте сравнительно легко (в особых случаях можно дизассемблировать и проверить). А вот работа виртуальных машин Java, C# и пр. совершенно непрозрачна. Как там реальзовано ООП под капотом не ясно. Отсюда и лаги. Байткод - зло)
А можно не ебать себе мозг, не использовать ООП и писать используя процедурное программирование. Код получится проще, легче понимать что комп будет делать, производительность будет лучше сама собой и т.д. ООП это слишком высокоуровневая хрень. Использование его повсюду в проекте не даёт никаких плюсов, а одни только минусы.
@@etodemerzel2627с вами не соглашусь. ООП - это не какая-то мегавысокоуровневая хрень, а по сути синтаксическая надстройка над т.н. обычной процедурной парадигмой. Ведь что такое программа? Это данные, плюс код, обрабатывающий эти данные. В процедурном программировании данные - это переменные и структуры, а код - функции, работающие с ними. Назовите структуры классами, а функции - методами, либо фунуциями-членами - вот вам и ООП в первом приближении) Те же яйца, только в крутую))) А для ассемблера вообще без разницы. Программы получаются кривыми не от выбранной парадигмы, а от кривых рук программиста.
Наш Сеньер на старой работе всегда твердил сердито, что Чистый Код это хуита и инфоцыганство, все над ним посмеивались, мол бумер опять раскряхтелся, а тут вон оно как...
Нас с вами попросили решить, кто тут прав:
Кто и что думает в итоге?
кейси чисто базы навалил, зачем нам читабельный, но медленный код?
Пусть я и не сильный аналитик и не глубоко знаком со структурой вне clean code - но я никогда не задумывался от этом, и теперь я пересмотрю подход к использованию solid и dry, спасибо за ролик.
в итоге как будто все такое позорно медленное из-за денег, внезапно. Опять виноват капитализм :)
Я как адепт чистого Си - за Кейси.
Как и всегда однозначного ответа нет. Под каждую ситуацию нужно просто выбирать наиболее подходящий вариант.
Как говорится "На ассемблере можно написать всё что угодно. Но жизнь коротка."
Языки программирования и были придуманы для удобства и скорости написания программ, а так же, точнее наверно даже в первую очередь для удобства и простоты,чтениятекста программ человеком, внесения корректировок и дополнений . Но что то пошло не так.
В итоге- один хрен очень мало кто может читать чужой код, особенно без комментов, но при этом код тормозит по сравнению с тем если бы писали на ассемблере.😢
Видимо в следующей жизни =)
@@АлексейКруговой-н9успорное заявление про читать чужой код. Если ты опытный ты и всю лапшу индусского кода разберёшь. Мне лично помогло книги по рефакторингу
@@АлексейКруговой-н9уПойдет так, когда каждый сможет написать язык программирования чисто для себя. Под свое понимание реальности, скорости разработки, эффективности. Невозможно создать универсальный интерпретатор, без ИИ
На ассемблере пишут некоторые вставки в 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, там было много свич кейсов)
Вопросы к фронтендерам
На самом деле есть такой парадокс, работал 13 лет назад над андроид приложением - магазином, куча деталей продукта, когда листаешь много чего отрисовывать - запихнули в кастомные вьюхи и рисовали прямо на канвасе - работало шикарно. Судьба вернула к этому же заказчику на тот же проект, команда в 10 раз больше, все на современном стэке, клин и тд. Так вот сейчас все зашиваются, перегруз по работе, а самое главное на современном железе все лагает жутко. Я хз куда этот мир катится, 13 лет назад нас троих хватало на все, сейчас все тот же функционал, но намного хуже переписанный просто в 100 раз хуже перформанс.😢
Ха-ха )
Реально
Что Windows, что MacOS от версии к версии утверждают, что улучшили то-то и то-то, заменили что-то старое на новое и быстрое. Загрузка ОС и работа стали быстрее, НО... старое железо больше не поддерживается, а общие требования к железу выросли. Из чего можно сделать вывод, что быстрее становится не из-зи оптимизации, а исключительно из-за более быстрых CPU, RAM, SSD и бОльшего объема RAM, которую засирают по черному. ((
Архитекторы тоже кушать хотят, ну
зато у них всё на МОДНЫХ фреймворках и они "крутые", и начальство может писюнами меряться с конкурентами "мы используем новейший стек технологий XYZ", а ты в их глазах - "жалкий дилетант-писатель велосипедов" [сарказм, ирония, стёб].
А вообще Андроид окончательно скатился в унылое говно, во многом изза подхода к GUI, ну и котлин не всем нравится (и хотя модный ныне джетпак-композ по своему оригинален и впечатляет, но он не всегда прост для понимания). Похоже надо переходить в другую специализацию.
Вообще-то все зависит от конкретной задачи.
Если мы видим, что какой-то кусок кода выполняется раз в 2 часа и его выполнение занимает не 100 наносекунд, а 250 (из-за чистого кода), то ускорять нам ничего и не надо. Он прозрачен и в нем нет ошибок.
Если же код выполняется каждые 500мс*100000 раз, то тут уже не до красоты. Фигачим отдельный класс FastMaker в котором будут и свитчи и использование всяких AVX инструкций и вычисление на GPU и asm вставки.
Байто*бить это тоже плохо, как и медленный красивый код.
Для тех кто не согласен: код который мы пишем был изобретен для упрощения создания машинных кодов.
При любом раскладе событий в машинном коде можно добиться лучшей производительности. Это ведь не повод отказаться от языков программирования?
А на фига тебе вообще класс фигачить,может просто макросами там чисто сишным или плюсовым ?
база
@@tohoto2183 чтобы наш быстрый код на свитчах стал черным ящиком для классов, которые будут его использовать на более высоком уровне.
А ещё лучше быстрый код делать отдельной библиотекой, чтобы другие разработчики прикладного уровня не тратили время на реализацию того же самого, а красиво его использовали в своем проекте.
Посыл в том, что никто ничего не оптимизирует, все ждут что железо станет лучше.
Правда в словах есть. Иной раз, можно позволить выполняться коду долго.
У меня есть подозрение, что монструозный и тормозящий софт под капотом совсем не clean.
Ну тут сурсы надо смотреть, иначе не скажешь...
имя опыт работы на по настоящему дерьмово написанных проектах, могу уверенно заявить, что я ни разу не видел чтобы "следование клин коду" вызывало проблемы с перфомансом, обычно совсем наоборот
@@roman7956 кто мы, а кто авторы фундаментальных противоборствующих концепций программирования...
@@roman7956 Так и за перфомансом не гнались))
Поддерживаю что проекты с нормальной архитектурой работают лучше. Легче бьются на микросервисы, легче расширяются. А мест где бы нужна хорошая оптимизация очень мало и жертвование читаемостью там допустимо. Но обычно проекты без клин кода это монструозный кусок мусора с имиджем на 30 гигов который писался с идеей «нет времени думать нужно делать». И их улучшение требует такую прорву часов что никто этого не делает.
Если упарываться в удобство программиста, то платим производительностью.
Если упарываться в оптимизацию, то платим временем разработки.
Наверное лучше искать баланс...
Баланс для каждого субьективен
Именно поэтому я пишу на c++ со вставочными конструкциями asm
@@payrgames поэтому и пишут по-разному
@@FXGO807_7 типо ты лучше компилятора оптимизируешь?
нейронки все разрулят рано или поздно, выдадут каждому желающему х20 производительность (если не всем задачам, то всех уровня мидла), ну а читаемость кода уже не будет важна т.к. проги будут писаться уже не человеком (ну, постепенно вытесняя человека, окей?) из за того что стоимость нейронки будет стоить около 10 центов за написание, а тот же программист мидл будет это же делать за зп в тысячу $. И да, это не я выдумал, так говорит Сэм Олтман, их цель на ближайшие годы это снизить стоимость интеллектуальной работы к 0$
"Да, да, производительность важна", покивали головой мы, и пошли заворачивать свои серверки в докер
😂
Которые еще на docker desktop👍🏼
И писать пародию на микросервисную архитектуру где на каждый пук Http запрос😂
@@Milk-gw1zl во во. в вебе где на каждый чих или запрос в базу или вызов апи, все эти "замены полиморфизма на свитч" как экономия на спичках выглядит.
Docker, на самом деле, не даёт никакого дополнительного пенальти производительности. Ну, может, кроме самого демона докера. Тогда возьмите Podman. Всё, что "завёрнуто" в Docker, по сути точно такие же процессы в ОС, мы тут не будем рассматривать, если докер под мастдай в виртуальной машине. Используются всё те же системные вызовы, что и без использования докер.
Пишешь чистый код, твой код ждёт больше циклов процессора, больше циклов процессора, больше тратиться электричества, больше электричества - больше выбросов в атмосферу. Надо дождаться когда "зелёные" доберутся до программистов, и можно будет забыть про чистый код.
Так уже добрались- Green coding
@@artjomsfomenko757 поподробнее про это, пожалуйста.
Чота я не понел. Чувак доказал, что если убрать vtable и прочие плюшки, написать код, специализированный для данной операции, то он будет быстрее? Ну да, будет, а чего такого-тооооо? Иногда мы именно так и делаем на микроконтроллерах, если нужно прям очень ужаться по производительности или памяти или чтоб выдерживать тайминги до тактов. Но в абсолютном большинстве программ это не требуется.
Но есть один нюанс. Очень трудно написать в таком стиле большую программу. Поэтому нужно знать что, когда и в каких случаях применять. Ваш капитан Кэп.
ну вы так в своих рассуждениях вообще можете дойти до идеи что "серебрянной пули нет" и "головой нужно думать что и зачем ты делаешь", а холиварить тогда как????
@@roman7956 да, что это я в самом-то деле. Ну ок, погнали: иногда, в редких случаях, в C можно использовать goto. У меня был кейс, когда буквально пришлось основной цикл программы (на микроконтроллере, оф коз) построить на goto. Там почти вообще не вызывались функции, ибо это дорого по времени.
Кто мы? 2.5 человека и один из них инвалид на голову раз это не понимает.
Не трудно. А реально. Просто изначально надо не заморачиваться в лищние удобства и с опытом придет скорость.
ты не понял сути ролика? Посмотри еще раз, там же четко всё расписанно, тебе твой боб внедряет свою идею написания кода, ты буквально пишешь по шаблону другого человека, и это не есть хорошо, когда ты сам не думаешь о том как бы оптимизированнее и быстрее код написать может просто тебя оставить без развития в своей сфере, я считаю надо сначала посмотреть а потом додумать и сделать еще лучше, а повторять за кем-то не пытаясь что-то изменить в лучшую сторону, для меня это не программист а фальшивка
Я когда смотрел оригинальное видео то не мог понять: он то ли троллит, то ли серьёзно. Дональд Кнут когда-то сказал: "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 платформ я никогда не видел, чтобы в них кто-то в здравом уме в циклы с миллионами итераций вставлял вызывы каких-то ф-ии и уж тем более полиморфных. Большинство проблем производительности сегодня это обработка огромных массивов данных (в основном графика), которые не умещаются в кэше процессора, за что мы каждую секунду получаем громаднейшие пенальти. В профилировщике обычно в топ вылезает именно это, а не какие-то вызовы. При обработке громандных массивов данных в огромных циклах как раз и применяются оптимизации упомянутые Кейси, но зачем тащить оптимизации приминимые для больших данных/итераций туда, где они не дадут значимого выигрыша, но усложнят читаемость кода?
А станет ли он сильно сложнее без клин кода ?
@@КоляКоронов-к9эда
Буддист решил помытся и утонул... В желтой воде..
Это вы, батенька, спорите с соломенным чучелом. Где у Кейси было сказано, что трудозатраты на оптимизацию кода окупаются всегда? Он говорит совсем другое: не всегда clean code важен любой ценой, нужно знать его издержки и понимать, когда необходимо от него отступить. И есть масса случаев, когда это случается на практике. Даже тот код, который не выполняется миллионы раз внутри какого-нибудь цикла, бывает нужно оптимизировать, если он сам вызывается миллионы раз в секунду. Я на своей практике сталкивался с такими ситуациями, когда уже не было смысла в программе оптимизировать узкие места, поскольку каждая строчка программы примерно в равной степени тормозила систему до неприемлемого по техзаданию уровня. И я сталкивался в своей работе с тоже-программистами, которые сначала цитировали Кнута про "преждевременную оптимизацию", а потом спустя некоторое время и вполне предсказуемо бегали кругами и кричали, почему продакшен нестерпимо тормозит и что надо срочно что-то с этим делать, желательно вчера. Полагаю, вы так же не сталкивались с проблемами производительности таких вещей как высокочастотный трейдинг и различных OLTP-подобных приложений, а это весьма обширная область. Так что говорить, где лежит большинство проблем, несколько самонадеянно.
> почему при наличии современных мощных профилировщиков никто в индустрии не говорит о тормозящем полиморфизме, а говорят в основном о других проблемах в производительности (память, кэш, i/o)?
Потому что новое железо достаточно купить, а новые знания нужно майнить?
Говоря про быстрый код, многие представляют какой-то нечитабельный ужас с указателями на указатели, инлайн ассмебли и кучей симд, хотя зачастую все, что надо для +- производительного кода, это:
- грамотное использование фич/языка (зарезервировать место для вектора и скопом добавить объекты, а не резервировать для каждого элемента)
- маломальское знание алгоритмов/динамического программирования (сохранить результаты вычислений, чтобы ускорить последующие, не использовать 4 вложенных цикла там, где можно обойтись двумя)
И даже так, как по мне, комфорт программистов не стоит того, чтобы у конечного пользователя 30 секунд грузился ГУИ из-за 10 слоев абстракций
Ну правды ради, в каких-то графических решениях, быстрый код это по факту нечитабельный ужас с указателями на указатели, инлайн ассембли и бешенными алгоритмами)
@@Мояшарага-ъ2ж Далеко ходить не нужно, достаточно прикоснутся к DirectX.
@@Мояшарага-ъ2ж вообще да, но тем, кто крутится в таких сферах где производительность очень сильно важна, скорее всего в кайф реализовывать сложные и нечитабельные алгоритмы и выжимать из железа максимум самым малоизвестным методом)
SIMD очень прост и переносим, если ты согласен писать на гнутом диалекте. typedef float vec4 __attribute__((vector_size(4*sizeof(float)))) и пиши
Хорошо смотреть на Xorg и отвечать на вопрос, почему появился Wayland
Как по мне тут всё довольно просто: программисты стараются писать чистый код, а там где не хватает производительности, оптимизируют как лучше
Фу, скушный практичный центрист! А как же развести многолетний срач и написать десятки книжек?)
Ну как бы разница в 15-20раз это провалл клинкода. У нас процессоры не стали на столько быстрее с 2007 года. Там хорошо если они стали быстрее раза в 3. Чего реально стало больше это ядер и памяти. Но это не сильно решает проблемму быстродействия. Ядра помогают многозадачности а не ускорению конкретного процесса. Да теперь мы можем и браузер запустить и игру и стрим если количество ядер и памяти позволяет. Но если процесс не оптемезирован то тут уже никакие ядра не спасут.
@@vsevolodkuleshov8551 нет. Это - провал постановки задачи. то есть - руководителя проекта
Что не верится в это. Игровая индустрия тому пример
@@vsevolodkuleshov8551ну это не разницы в 15-20 раз, а в несколько десятков цикла процессора. Когда с бд загрузка идет секунду, все другое не очень играет роль
По моему в какой то книге кента бека была фраза что код сперва должен просто работать, на следующем шаге можно сделать так чтобы он был написан красиво, и в конце чтобы он работал быстро. дядя боб говорить как писать кода на втором этапе, а кейси - на третьем =)
Не подходит , в клин коде не про красиво вообще ,там свой стиль просто у аппонента другой стиль,когда большая программа пиши как хочешь ,все равно заблудишься. Клин код -это про навязывание своих строгих правил написания и не более того,следуя им все-таки легче понимать ,но сомнительно ,что это работает в больших прогах.
Код сначала должен работать, а потом - работать ПРАВИЛЬНО
@@ВиталийДербенцев-щ7ж "должен работать" это и имелось ввиду правильно, он должен делать то, ради чего был написан
@@roman7956 да-да, особенно если постановка задачи написана как курица лапой и внутренне самопротиворечива.
Эм... самое смешное что они оба правы так как говорят о разных вещах. Кейси рассуждает о написании, скажем так, mature продукта, настоящего, ну типа ngnix или sqlite - это идеальные инструменты, которые на любом вейпере вытягивают 100К запросов. Ну или тот же Doom Кармака или OTP Elexir-а - вот такие вещи. А дядя Боб - про сляпывание прототипов, которые вместо того, чтобы выкинуть - раз-раз и в продакшен. ИМХО - 98% всего созданного и работающего софта - это чертовы прототипы, которые еще и постоянно допиливаются, потому что заказчик некомпетентен и не в состоянии видеть вообще, какой уж тут нос. И вот эти прототипы хоть как-то поддерживать в живом состоянии можно только со всеми этими клинкодными делами. Потому что иначе никто и трехметровой палкой не будет трогать оставленное предыдущим программистом. Особенно учитывая, что не все они Линусы и Кармаки. Так что клинкод - реальность галер и кровавого энтерпрайза. А создание настоящих продуктов - удел упоротых одиночек. Чёт типа того.
так, что-то я не понял: прототипы пишутся с использованием клин код, а зрелый продукт типа nginx, который пишут упоротые одиночки, - у него какая история?
@@manOfPlanetEarth nginx буквально писался одним человеком в свободное от работы время, в какое то время разраб уволился с работы, чтобы посвятить фуллтайм своему детищу. После чего галера(Имя ей Rambler), пытались отжать права на nginx.
продукт типа Doom 2016 написан не одиночками, но и с перфомансом там всё по красоте.
Вот как раз зрелые продукты особенно большие на тяп ляп не пишутся. Не стоит просто упарываться по чистому коду. Писал код еще до прочтения книги, ну и почитав просто сказал ок кеп. Т.е. хорошие практики они приходят с опытом а не с книгой или инструкциями как писать и не иначе.
На практике скажу что чистый код больше актуален на высоком уровне приложения или в какой-то сложной бизнес-логике, чтобы можно было быстро разобраться или изменить/поправить. Когда залезешь в код который написан "одной простыней" или на столько связан и засран, то невероятное кол-во времени уходит не только чтобы разобраться как оно работает и что имелось ввиду, но и придумать стратегию как это все изменить согласно новому требованию чтобы не сломать. Иногда кажется что это время соизмеримо с разницей процессорного временем потраченного за все время существования программы написанной "чисто" и "грязно".
В больших проектах, по опыту побеждает Понимание того о чем Чистый код, а не его неприкословное соблюдение. И есть пример когда приходили молодые и заряженные теорией и книгами и спустя время "все начинало тормозить" - отнюдь не из-за чистого кода а бездумному и местами неверному его трактованию (а масштабируя на количество мест с неверным решением - это все превращалось в процессорный ад).
Понимаю что ролик не об этом но все же.
Самое лучшее объяснение SOLID из возможных!!!
90 секунд суперпонятной базы, я в шоке.
Респектище ❤
Не стоит брать за основу объяснение SOLID из этого ролика. OCP вообще не про полиморфизм и может быть реализован кучей разных способов. Мне это слух жуть как резануло.
Клинкод дает одну особенность, которую не дает подход кейси: расширяемость
На примере фигур он переделал классы в енамы и свитчи. Но если у тебя система плагинов, ты не воткнешься в енам, а свитчи сами не расширятся. Здесь нужен именно полиморфизм.
Надо брать лучшее от этого и не застревать на одном месте. Если ты будешь тупить 10 минут над ускорением горячего кода - ок, если день над холодным - не ок.
Тем не менее, благодаря JIT можно на лету генерировать свитчи на основе информации в рантайме
Удивительно как мало людей понимают этот, в целом довольно тривиальный, факт...
Подробнее бы про плагины, ибо в моём понимании просто добавляется новый switch или даже функция и всё
@@user-gy8xn4kt7s представь, что ты представляешь клиенту интегрироваться в свое приложение.
Например у тебя ПО по отправке файлов на файлообменник с выводом ссылки на экран. Ты реализовал это для trashbox и regfiles с кнопками выбора, и позволил пользователю добавлять другие файлообменники через плагины на основе скриптов js например.
Приходит Вася, добавляет 100500 js файлов не только под trashbox, а еще и под гугл, яндекс, mail, ipfs, S3, R2, M1... Начинает продавать все это и получает профит больше тебя. У тебя ведь FOSS, да?
Если бы ты вместо плагинов использовал switch-case, Вася не воткнулся бы, а ты бы туда не смог добавить систему плагинов.
@@user-gy8xn4kt7s ну плагины
Ты создал ПО и хочешь позволить пользователю добавлять туда свои кнопки через js скрипты
Когда у тебя кнопки работают на свитчах, это работает не очень
@@user-gy8xn4kt7s кстати, если отойти от системы плагинов, если такая вещь как мономорфизация обобщений, а также сведение полиморфизма к конечному перечню вариантов и используемых логик.
LLVM такое вполне себе развернет в switch-case... Надо только писать на плюсах, зигах и всяких вот таких
Я как мидл со своей практикой скажу так: если вы пишете какую-то приложуху для ИП за 250к то тут вообще пофиг т.к. скорее всего приложение не будет расширятся, а если и будет, то опять же скорее всего, вновь обратятся к вам и тут вы можете немного чек задрать, что скомпенсирует ваш технический долг; если же вы пишите высоко нагруженное приложение и/или интерпрайз уровня то тут нужно тщательно анализировать, где важна скорость - жертвовать всем ради скорости, а где нет, использовать тот самый "чистый код" т.к. если расширением будете заниматся вы то вам придется объяснять тимлиду компании почему придется потратить доп. 2-6 часов на допилы, а если не вы, то уже объяснять почему у вас руки из странных мест ростут.
Странная дискусия. Мне помнится что даже в книге есть сноска, что упарываться не нужно и можно отступать от правил
Иногда - даже нужно.
Насчет самого клинкога не уверен, а вот во всех принципах. Том же солиде это прописано точно. Я вот чаще всего пишу сначала 1 мега класс без интерфейсов, а когда он заработает, уже чищу код. Потому что вносить новый тип переменной во всю структуру наследования и все интерфейсы это дичь. А если потом откатывать, то двойная дичь.
@@tashihu Интересно... Где такой подход работает? Быть может у вас проблемы с архитектурой приложения и потому вы не можете сразу понять куда какая часть вашего божественного класса должна быть вынесена?
@@tashihu Если у Вас много уровней наследования (больше трёх), то Вы что-то делаете не так)
Читал я чистый код. Принимать без фанатизма. Во главе всегда дожен быть здравый смысл
маэстро, я вас узнал в гриме😉
@@manOfPlanetEarth убил просто 🤣
@@ralymbetov
🤣
Именно так и есть. Но люди религиозны - именно от отсутствия смысла в голове.
"Принимать без фанатизма." - хорошая фраза, если у тебя есть административные полномочия и нужно косвенно сказать "правильно - это именно не так, как сделал ты".
Когда начинал программировать в 2014 году - увидел курс от кейси под названием Handmade Hero. Для начала мне было трудно въехать что он там вообще пишет и как это соотносится вообще с тем чему меня учили в универе или в книгах, но со временем я всё понял. Отныне я никогда не назову клин кодом то что является "нормальным" в современной практике. Его способ написания кода гораздо более легкий и натуральный. И хочу сказать что я кайфую от программирования - чего точно бы не было бы пиши я "Clean code"
Что любопытно - очень многие воспринимают этот спор так, словно сторонники "чистого кода" топят против производительности, а сторонники производительности топят за говнокод(лишь бы он был быстрым). Но это, на мой взгляд, совсем не так.
С высоты своего опыта коммерческой разработки(~25 лет) лишь подметить, что подавляющему большинству коммерческого кода даже до "чистого кода" - как до Китая пешком.
А код не должен быть "чистым или быстрым", он должен быть "чистым И быстрым". Но, пока платит бизнес, вряд ли так будет на массовом уровне.
Ото ж. Люди, которые говорят, что Clean Code - фигня, хотят писать еще более медленный говнокод. Для того, чтобы писать оптимально, надо научиться писать ЧИСТО для начала. Я буквально вчера в ревью заставил джуна вынести одну и ту же функцию, которую он создал в каждом месте, где она была нужна - около 20 повторений. Сомневаюсь, что это ускоряло производительность. Он просто быдлокодит.
Когда сроки проекта горят, уже не до чистоты кода и не до производительности. Заказчик этого все равно не оценит, а дорабатывать уже можно и потом за отдельную плату. А если со сроками проблем нет то, конечно - "чисто И быстро".
Все так - код одновременно И должен быть производительным, И не должен быть говнокодом. Но для этого в голове должны быть мозги - а вот с этим сейчас огромнейший дефицит.
@@ValkRover это отмазка. Если навыки есть, быдлокода не будет.
@@rkurbatov Да, знаю я! Не умею плохо, это и беда!
прав ты, Винд. всем нужны только деньги. и каждый их фармит по своему: кто-то пишет и продвигает свои умные книги, кто-то антихайпит по поводу этих книг, а кто-то хайпит на антихайпе, попутно присовывая подписчикам скильную фактори. а подписчики, хавая весь этот попкорн и чувствуя свою квазипричастность ко всему этому чудесному миру, фармят свои рисовые гроши, гонясь за морковкой, перед их носом... так устроен этот вондерфул ворлд...
хеллоу, фускинг ворлд...
Самое важное, что из этого можно сделать выводы, а не слепо следовать чему-то.
Правды ради тот кто хайпит на антихайпе кратко пересказал всё из-за чего был устроен шум
Этот комментарий - большая жирная точка во всём этом споре. Остальное - просто спинофф ради статистики)
Лучший комент) А что еще ожидать:
Среди панелек, хрущёвок и деревянных изб
По нам палит шрапнелью капитализм
25/17
Да, деньги есть мерило всего в нашем мире, и не важно как их доставать). И всё равно нам на экологию, разрушительные войны...зато столько денег выручают за каждую единицу боевой техники!) одна польза)
Живи, пока ты ещё выгоден своему работодателю; диши гразным воздухом за то что экологическое производство устанавливать дорого; лечись в помойке, потому что больница не бесплатная; смотри как миллионы нищих умирают на улицах и живет Африка, пока "крутые" блогеры жируют; вспоминай как расстреливают парламент из танков, как буквально забирают твоих родных на войну прямо в пекло.
А если ты не согласен, то ты же "против государства! демократии! украинский иноагент сатанинского гейропейского запада!", тогда берешь красный флаг в руки и вперед за демократию, прямо на баррикады против омона с дубинками, чтобы люди начали жить, а не доживать зарплату
Мартин - чувак, который понимает что программирование - это про людей, а не про железяки. Вот и вся разница.
Проблема, как раз, в том, что программирование - это про железяки, а не про людей. И упомянутый в видео Mike Acton утверждает аналогичное.
@@Lsp-plugIn в таком случае искренне желаю вам всю оставшуюся жизнь заниматься оптимизацией сгенерированного автоматами/алгоритмами кода.
@@EvgeniyFadeev ваш ответ выдаёт полное непонимание того, что я написал. Для начала бы посмотрели упомянутый доклад на CppCon 2014 от Mike Acton.
2:08 нет! не стоит!!! это неправильное понимание SRP! разбивать приложение на классы с одним методом чтобы этот класс мог выполнять только одну задачу - это неправильно!
Класс нужно разделять если у него есть несколько причин для изменений. вот автоматизируете вы какой нибудь бизнес. если у вас есть класс, который нужно будет изменять и при обновлении должностной инструкции кладовщика и бухгалтера - это плохо спроектированный класс, он не соответствует SRP, его нужно разделить.
Но если у нас есть класс, в котором 100500 методов, он описывает действия которые совершает кладовщик, и изменения законодательства в части налогообложения никак не вынуждают переделать этот класс - он внезапно соответствует SRP.
Я считаю что производительность это не забота программиста, а забота создателей языка на котором он пишет, производителей железа на котором этот код запускается и т.д. То есть медленный чистый код должен автоматически приводиться к быстром грязному коду
Проблема не в том чего хочет знать или не знать программист.
Если отказаться от непроизводительного чистого кода, то бизнесу придется нанимать Senior и Middle там, где хватило бы одного middle и пачки студентов.
А бизнес такого не хочет, сервера докупить дешевле...
Один человек, из толпы просто написал как есть, Спасибо
нет на рынке столько Senior и Middle, чтобы покрыть задачи бизнеса сейчас
их и сейчас-то нет, а если упарываться в производительность, то и подавно не будет
с каких пор студенты пишут чистый код ?
@@Firegalensk бизнес занимается пилежом бабла и погоней за свистопирделками тиктокерскими, поэтому программистов и не хватает :)) маркетологи шарлатаны накалывают владельцев бизнеса
Дайте мне тех студентов и мидлов, которые могут свободно писать чистый код! Вот уж фантазии, Гыгыгыг
Вот вам супер совет по клинкоду. Делайте что бы в микросервисе было не больше одной ручки, в редких случаях можно больше. Если надо что то дорабатывать, делаете новый репо с новой версией микросервиса. Это решает все проблемы, лапша код из одного АПИ-метода норм выглядит и работает быстро. MVC, DI, SOLID и прочий панос не нужны т.к. для одной-пары ручек это избыток.
13 минут, которые экономят часы и доставляют кучу удовольствия! Спасибо!
"Шли годы. Clean code использовали..." - да вы оптимисты, ребята
Программисты раньше: Как мне уложить эту задачу в 512кб памяти?
Программисты сейчас: берём тучу библиотек, плюс ещё тучу "на всякий случай", собираем из них какую-то программу - готово. Глючит, лагает? У вас просто оборудование плохое.
Ох. Попробуй сформулировать мысли из 500000 слов. Да даже из одной тысячи.
@@edranovdenis Я не об этом. Я тоже когда пишу например скрипты, юзаю библиотеки. Я о том, что на сегодняшний день никто не думает об оптимизации. Собрали как конструктор из библиотек софт. Вместе с ними набрали багов из-за несовместимости различных процедур и функций. И всё. Работает, бизнесу достаточно. Оставляем так. Через год, два следующий продукт, новая версия за отдельные деньги. Он лучше там больше возможностей, ура. Только комп ещё мощнее нужен, что бы ещё больше глюков переварить.
Вот за что я уважал Эпл, так это то, что там боролись за оптимизацию... Раньше боролись.
Программисты раньше: нифига себе! У него 512кб памяти!!! 😂
Мне кажется, что бизнесу важнее именно поддержка продукта в долгую, а значит именно концепция клин кода будет выигрывать. Ведь если ты работаешь в команде, твой код должны суметь прочитать и остальные, при этом сразу поняв, что происходит. Но если ты соло разработчик, то конечно лучше сразу писать оптимизированный код, хотя в таком случае не факт, что ты поймешь, что писал нежелю назад)
Я обычно читаю свой старый код с вопросом "какой *** это написал?"
"свичи и виртуальный функции реализованы одинаково в компиляторе"
😂
я хочу выбросить его книгу в окно, как это можно было пердануть
Ну, 25 лет назад почти наверняка так и было. В каждом объекте - указатель на таблицу виртуальных функций. Вызов функции - по адресу, который берется в этом массиве.
свич, почти наверняка, организовывался так же, только указатель на аналогичную таблицу - статический. Это если компилятор умел немного оптимизировать и аргумент свича - небольшое число, в противном случае - куча if-ов.
Правда, подозреваю, с тех пор много воды утекло.
Я далек от программирования, но если я правильно понял - весь спор в "+" и"-" стандартизации, и применим он по сути к любой области труда человека.
Исторически человечество приходит к стандартизации в той или иной мере в каждой области. Причина проста, для удовлетворения спроса в условиях ограниченного ресурса по созданию конкретного блага, мы сознательно занижаем максимальную планку требований к этому благу до уровня когда спрос будет удовлетворен, а так же сдвигаем нижнюю планку требований выше за счет масштаба.
Но при этом никто не отменял различного рода уникальные или единичные изделия, где выдвигаемые требования не вписываются в общепринятые стандарты, просто производство таких изделий/услуг будет значительно дороже, поскольку потребует уникальных навыков, материалов, приспособлений и д.р.
Помню 2000-е, когда ООП-код на С++ руинил весь перформенс на процессорах с длинным конвейером от Texas Instruments. В то время как плохо-читаемый код на Си, написанный с учетом архитектуры, летал.
в 2020ых 90% оптимизаций под конкретные процессоры применяется автоматически)
Всегда думал, что Clean Code - это не про скорость вот этой конкретной программы, а про то, как ее сопровождать, расширять, изменять в течение ее жизненного цикла, когда меняются люди, которые этим заменяются, т.е. про ее изучение кода, скорость его модификации, скорость исправления ошибок и их локализации.
И вот с этой точки зрения написать новую программу зачастую много дороже, чем просто пойти и проапгрейдить сервак, которой что-то слишком медленно исполняет.
А железостроители весьма неплохо увеличивали производительность своих поделок, поэтому якобы перечеркивание 12 лет прогресса - это на самом деле фундамент под удешевление сопровождения софта в течение десятилетий.
Clean Code обеспечивает гибкость, приспосабливаемость, подход Кейси дает доминирование в текущих условиях. А потом прилетает метеорит Чиксулуб и погибшим динозавром интересуются только палеонтологи (читай, борцы с legacy).
Для бизнес логики в нетребовательных приложениях - чистый код.
Для системного программирования и огромных, сложных софтин типа игровых движков - максимальная производительность. От чистого кода там будет мало потому-что ничего не поделать.
И то и то используется и практикуется.
ммм, то-то я смотрю игры у нас пиздец какие производительные, не лагают никогда и у всех все идет в +100500 фпс в разрешение 16к, ага.
А если серьезно, то у нас два главных движка это Анриал и Юнити и оба используют ООП.
@@dmitriyivanich1088 не играй во всякое говно просто)
@@dmitriyivanich1088не знаю как анрил, но в юнити конечно такое ооп царское, просто залюбуешься. Весь апи это статика в статике под статикой и статикой погоняет.
Ах, ну да, там же наследование есть от MonoBehavior и полиморфизм на Update() и некоторые другие ивенты, ну это, конечно, да, всё меняет )
@@dmitriyivanich1088 И в обоих лютый говокод и никакого CleanCod-а, тонны багов и отсутствие хорошей производительности. И таких проектов большинство, компании даже могут и не знать об этом, спасибо техлидам и менеджерам, т.е где как повезёт)
@@dmitriyivanich1088 Вспоминаю, как в конце 90х - начале 2000х играл в анрил турнамент (ещё тот, первый) на первом пне на 150 мегагерцах и 16 мегабайтах оперы, и первой вуду 3дфх. Сейчас гигагерцы и гигабайты, это вроде в дохера раз больше, а всё что по сути изменилось - текстуры покрасивше да полигонов побольше. Как-то не пропорционально
Их дебаты можно было бы свести к другому аналогичному вопросу: "На чём бы вы хотели писать программу: на условно Питоне или на ассемблере? А почему? Ведь на ассемблере же быстрее работать будет..."
Такое ощущение, что люди забыли историю развития программирования и откатились лет на 10-20 назад ко временам, когда ещё не сделали популярные нынче "простые языки", которые изначально и сделали, чтобы было более удобно для людей в ущерб производительности. Странно почему не откатились ещё дальше ко временам, когда чуть ли ни самостоятельно ОС нужно было писать каждый раз для каждого железа. А что? Ведь тогда всё ещё быстрее работать будет, ведь не будет лишних функций.
А потом в телефоне приложение с напоминалкой сжирает 500МБ памяти и батарею сажает :) Утрирую, конечно, но так и есть.
А потом у нас и приложений нет в маркетах ещё))) Да у нас везде проблемы!
И 499 из них - это не код)
Супер видео!
На самом деле, я давно уже на практике заметил насколько субъективно понятие КлинКод. Поработав в 4 разных компаниях, с 4мя лидами - увидел 4 типа этого самого 'клина'. И попробуй им доказать, что их КлинКод недостаточно клин)
Как по мне, самое главное в сегодняшней разработке, чтобы в команде были четкие, закрепленные подходы к разработке. Но на их описание нужно потратить уйму времени
никто не будет их читать
@@guai9632 понятно, что никто не хочет работать, но это уже задача компании/управленцев донести важность
@@guai9632 они должны быть написаны в самом коде. Если они есть их видно сразу
Не жалею, что открыл это видео с кликбейтным заголовком! Спасибо автору за обзор!
Тут просто нужно понимать где и что использовать. Это два противоположных подхода для противоположных задач.
1) Clean Code - очень удобен на огромных проектах, со сложной GUI и множеством различных данных. Т.е. в общих чертах - это организация процесса получения и обработки данных. И тут не важна скорость т.к. это только подготовительный этап, либо не нагруженный из-за того что одет ожидания данных от пользователя.
2) Второй подход - очень удобен именно в обработке информации, а так как объемы вычислений не соизмеримые с первым подходом, то и скорость по этому растёт.
То что используется как примеру - это как "из пушки по воробьям" - абсолютно бесполезно, но только если воробьев не много, а вот если их миллионы - тут уже совсем другое дело.
Исходя из этого получаем то, что нужно использовать оба подхода и каждый в своей стихии.
ОС запускается быстрее чем VS, делаем выводы
ну на самом деле не правда) В случае с виндовс, компьютер не совсем выключается)
@@fineuarealittlepogchamp гибернацию можно выключить (разницы по загрузке я не ощутил). Если не брать виндовс, то линуксятина грузится за секунды
"Кейси мало на что повлиял" - оно, конечно да, с т.з. общемировой практики, Но в конкретно взятых проектах, например в embedded разработке, останется меньше вопросов тогда, когда ты хочешь создать быстрый, отзывчивый код. Спасибо за видео!
Разносим каждую фигуру иерархии в отдельную библиотеку, написанную не то что отдельным программистом, а отдельной конторой. А теперь расскажите мне про свитч
Хоть кто то понимает для чего нужна вся эта абстрактная лабуда
А можно подробнее? Из вашего сообщения даже не понятно за свитч вы или нет
@@ВладимирЧескидов У него мысль что пример не корректен Перечисленные концепции создавались для огромных проектов офисы браузеры иде смм А сейчас эти принципы начали на серьезных щах внедрять в проекты уровня хелоу ворд
@@ВладимирЧескидов Попробую на пальцах объяснить, упрощённо.
Код не пишет 1 человек. Работа делится на несколько человек или несколько команд, каждая пилит свой кусок максимально изолированно от остальных, чтобы не мешать друг другу, не вносить свои изменения в код другой команды.
А свич требует в любой ситуации взаимодействия с объектом проверять его тип и выбирать соответствующее действие, таким образом все команды будут стукаться лбами в каждом свиче, добавляя туда свои типы объектов. Помните письмо Дяди Фёдора, которое дописывали то кот, то пёс? Вот примерно так, только в тысячу раз хуже и с матами))
Байто- и такто*бы не осознают реальности разработки ПО. Им кажется, что можно всё ускорить в стопицот раз, написав весь код линейно, без этих ваших абстрактных фабрик и визиторов, но они не понимают, что именно благодаря всем этим штукам и получилось написать столь огромную хреновину в довольно ограниченное время, распределив работу на большое количество человек.
Дядя Боб всё верно написал! Оптимизация не должна наступать на читаемость, потому что потеря читаемости в дальнейшем приведёт к падению оптимизации. Оптимизацию должны выполнять компиляторы, на уровне asm нет никакого полиморфизма, только jmp.
я пишу код для алготрейдинга, который должен отреагировать на изменение данных и уложиться в минимально возможное время. Цель не выходить из 1мс. Вот тут и приходит необходимость задуматься и над структурами данных, типах данных, циклах и кол-ве операций процессоров, кол-ве ядер, размещении данных данных в памяти, кеше и прочем. Но за 15 лет работы до этого, в этом не было необходимости и я не занимался профайлингом на уровне микро/наносекунд как разработчик.
Всё зависит от задачи, и производительность - один из пунктов ТЗ. Большинство софта вообще крутится не на пользовательских ПК, и является довольно сложным, чтобы писать его на ифах/свичах. Часто там вообще не важна скорость, главное - возможность без проблем нанять новую команду для поддержки этого монстра, и чтобы они не повесились, добавляя какой-нибудь мелкий функционал))
оба правы. Clean code хорош, на примерах фигур, но посмотрите на все эти визиторы и фабрики в исходниках хромиума, когда нужно держать в уме по 10 модулей, чтобы понять как оно там работает и что править/менять. функциональное программирование имеет меньшую когнитивную нагрузку, имхо
проблема функциональщины в том, что код пишется буквально задом наперёд. Да, оно работает, и иногда работает хорошо, но очень уж специфично для восприятия здоровым человеком, не обременённым учёной степенью по математике))
@@0imax "буквально задом наперед" - это далеко не всегда. в некоторых функциональных языках можно определять переменные после выражения (например блок where), можно создавать лямбды частично применив функции и тогда применение функции к аргументу будет идти "справа налево" или использовать правоассоциативные операторы композиции, но все это опционально и никто не запрещает использовать левоассоциативные операторы и префиксное описание переменных (блоком let). Я бы не сказал, что это сложнее чем держать в голове что оператор () или + могут быть виртуальными или перегруженными
@@vatne4eg Скобки, плюсы и другие операторы перегружают в весьма специфических случаях) Ну и не все пишут на С++, где разрешены такие извращения (на самом деле иногда полезные).
На самом деле спор ни о чем. Там где нужна производительность - пишут производительный код, но в современном мире большинство программ работают с I/O нагрузками, и плевать сколько тактов процессора тратит программа, если потом сидит и ждет ответ от сервера/базы данных/чтения файла/действия пользователя и кучи чего еще.
Хорошо, что человек из комментариев пришел и развалил двух гениев и их спор, а то сцепились ни о чем
Для бекенда производительность очень важна, которая напрямую влияет на расходы кол-ва серверов и их поддержку и кол-во пользователей которые смогут использовать один сервер в локации. Для любого софта который работает с графикой и большими вычислениями, перечислять можно долго.
@@fein7068 да, интересно какая там производительность у Бэка на джаваскрипте или питоне) С графикой согласен, но там и используют производительный код, я ж пишу, где что надо, там то и используют.
как хорошо жить в мире, в котором задержки не суммируются, а накладываются :D
@@fein7068 хочу глянуть на этот производительный бекенд на джаваскрипте или питоне) А для графики и математики, да производительность нужна, но я об этом и говорю, где надо, там пишут производительный код, где не надо - лучше писать чистый)
Единственный, чьи ролики я не ускоряю во время просмотра:
Изобретение правил ради только лишь их соблюдения, а не решения конкретной проблемы - это один из главных признаков "погромиста". И главное отличие "погромиста" от "программиста".
Одна из самых грамотных мыслей в комментариях, и как обычно, в самом низу по количеству "лайков".
Людям часто не нужно "решение проблемы", им нужно подтверждение своей правоты. Причём это справедливо как для поставщика услуг, так и для потребителя.
Правила эти появились не на ровном месте, и не для слепого их соблюдения. Если писать большой софт, намеренно игнорируя все практики клин кода, получится абсолютно неподдерживаемое нечто, где внесение мизерных изменений будет стоить несоизмеримо много человеко-часов.
@@0imax Эти "правила" являются набором догматов, не подкрепленных ничем, кроме субъективных впечатлений и _личного_ опыта. По сути, это религия, то есть полная противоположность научному подходу. Какой-то персонаж решил, что функция не должна быть длиннее 20 строк, к примеру. Или что цикломатическая сложность должна быть не более чем сколько-то там. И всё, толпа овец побежала исполнять. Потому что это же великий (Подставить имя тут) так сказал, посмотрите, он миллиард заработал в 20 лет, плохого не посоветует. Даже и не думая, зачем и почему, ради мнимой простоты чтения и поддержки. Даже не задумываясь о том, что десять функций отладить сложнее, чем одну, просто потому что человеческий мозг - не стековая машина, и он не приспособлен к хранению контекстов. А ведь мы программу пишем, а не духов вызываем. Это самый простой пример.
@@0imax С остальными "правилами" точно так же. Ни одно из них не является непротиворечивым, работающим независимо от иных условий. Практически любое из них легко довести до маразма, написав код, который будет идеально соответствовать всем этим указаниям, но при этом будет невероятно усложненным и совершенно неподдерживаемым. Если бы эти "правила" были чем-то научно обоснованным, а не набором догматов, то их невозможно было бы довести до подобных предельных случаев. К примеру, возьмем наследование. Вы можете сказать, что это всё придирки, что нужно ограничить количество уровней абстракции разумной глубиной и все возрадуются. Скажем, 3 уровня. На что вам пять программистов скажет, что должно быть четыре или два. Ещё пять скажут, что наследования быть вообще не должно и нужны лишь интерфейсы. А потом подойдет школьник и заявит, что классический полиморфизм вообще не нужен, что это ерунда для старых пердунов, а примеси - это истинный путь в следующий век. И никто из них не сможет предоставить четкие и формализованные, фальсифицируемые критерии, почему именно _ОН_ прав. Которые у всех сойдутся, и с которыми все придут к одному и тому же выводу. Потому что субъективная херня всё это. Конструкт в голове, способ самовыразиться и собрать бабла с тех, кто готов покупать книжки с этой писаниной.
@@alexanderd.7818 Аксиома Эскобара говорит, что любые крайности - плохи. Не нужно воспринимать книгу как абсолютную истину, и не будет ни проблем, ни срачей по поводу))
По собственному многолетнему опыту могу сказать, что оба подхода релеванты в зависимости от задачи, инструментов и прочих факторов при написании софта. Клин код хорош в случаях, когда производительность не важна. В крупных проектах так же часто приходилось искать компромиссные решения: удобство в понимании кода против производительности в отдельных местах. Самое сложное в данном вопросе, понимать когда можно себе позволить четкую сегрегацию по клин коду, а когда нужно придержать коней и выдать максимальную производительность. Многие этого не умеют :)
Это конечно все очень круто и интерестно, но когда плюсы за 10 часов?
а че не за час? И после сразу отклик на сеньора плюсов.
Так гайд на сами плюсы, вдобавок, его надо учить, а не посмотрел=понял. Все остальное прилагаемое и можно учить, делая свой проект, к примеру.
После войны пчёл
@@aririi6016человек культуры
@@aririi6016 слишком сырно
OCP - это не про наследование, а про расширяемость базового класса без необходимости его изменения. Это можно достичь разными путями.
KISS - не про имена переменных, а про общее стремление к простоте системы. Сложную систему сложно поддерживать, больше шансов, что в ней что-то пойдёт не так и есть скрытые проблемы. Это базовый инжереный принцип, что в механике, что в электронике, что в программировании.
Ещё можно было бы упомянуть YAGNI - в целом про овер-инжиниринг, преждевременную оптимизацию и желание написать супер-абстрактный код на все случаи жизни.
Про вред наследования(ну и полиморфизма) писали ещё в GoF 30 лет назад. И дело даже не производительности.
То, что абстракция бьёт по производительности - это common sense, те же споры C++ vs C я видел и 20 лет назад. Даже у Страуструп писал о то, что полиморфизм - это -25% от производительности. К слову, Clean Code - это больше про Java(ну и отчасти C#), где ООП по полной программе и свои особенности. То, что это сильно бьёт по производительности в примере про вычисление площади - ничего удивительного, по сравнению с простой арифметической операцией оверхед на виртуальный вызов слишком большой.
То, что инкапсуляция - миф, это правда. Во многих ситуациях приходится лезть в исходники, чтобы понять, как лучше работать с этим кодом.
Чувак набросил знатно, конечно. Оценивать парадигму по скорости вычисления площадей фигур - это полная глупость. Очевидно, что любая абстракция - это оверхед. В реальной большой системе этот оверхед на фоне всей логики уже не так заметен. В Java/C#/Python/V8/Golang есть ещё сборка мусора, например. Давайте хейтить их за это.
Если посмотреть на бенчмарки языков, то C++ лидирует по всем показателям, он в разы быстрее перемалывает числа. Однако, если сравнивать веб-фрейморки, то почему-то в топе фреймворки на Rust/C/Java/JS. Единственное исключение - это возврат простого plain text в ответе. Почему же язык такой быстрый, он так быстро вычисляет площади фигур, а фреймворки на нём медленные? Потому что высоко-производительный код - это сложный код. Сложность кода накладывается на сложность системы, в итоге получается монстр, который нереально трудно поддерживать. Этот монстр ещё и сложно написать.
Несомненно, код на Rust или C будет быстрее кода на C#/Java. Помню лет 15 назад были срачи на тему C++ vs C#, в относительно сложных системах действительно C# процентов на 20-30 медленнее(по-крайней мере на тот момент, сейчас разница уже меньше). С ростом сложности системы разница становится всё менее заметной.
В реальной жизни бОльшую роль играют алгоритмы и понимание разработчиком особенностей выбранного языка/рантайма/фреймворка. Я лично видел примеры, когда разработчик умудряется создать экспоненциальную сложность там, где можно было бы сделать константную. Разработчик должен понимать, как выделяется и освобождается память в его программе (я говорю и про ненужные выделения, про копирования, про работу GC), понимать вычислительную сложность своего кода.
1. GoF писали "наследование вредно, давайте не будем его использовать"? Можете скинуть цитату?
2. "Инкапсуляция - миф" - это как? Вы утверждаете, что невозможно писать классы и интерфейсы, которыми можно пользоваться, "не заглядывая под капот"?
3. Если глупость - рассматривать пример из книги Боба, то что должен был сделать Кейси, чтобы обсудить с Бобом проблемы clean code? Достать код, к которому Боб не имеет никакого отношения?
4. Далеко не всегда код на C++ будет быстрее чем на Java или C#. Зависит от задачи. Зависит от качества кода. От затраченного на код времени. Среднее по больнице не имеет смысла для принятия решений.
С производительностью ****** везде, один веб чего только стоит с зоопарком фреймворков, смотришь профилирование и ужасаешься всему тому *****, что вылетает там
По моему личному мнению, ты можешь использовать фреймворк в том случае, если у тебя достаточно навыков написать такой же если у тебя будет достаточно времени
@@BIackFox11ничего себе, так, получается, все возвращаемся на plain js и jquery?
@@MrrrMrrrMrrr а может ну нахер этот JS, а? WebAssembly!
@@MrrrMrrrMrrr таки звучит как прекрасная идея! Может перестанем прелоадер загружать, используя скрипт на 0.5мб.
@@MrrrMrrrMrrr Все правильно написал @BlackFox11. В свое время фреймворки и появились благодаря тому, что надоело реализовывать все время одни и те же части приложения. Ты знаешь как, знаешь зачем и почему, но писать снова и снова... Собрали в "одну кучу" и получили фреймворк (грубо говоря).
Понимание того как оно работает под капотом дает понимание что и где использовать в своем проекте и как это повлияет на скорость работы.
Сейчас некоторые умеют только во фреймворки как в "отдельный язык программирования".
Не умеешь написать свой имея 100500 часов в запасе (т.е. не обладаешь теоретическими знаниями и пониманием зачем его писать) - значит не достаточно практики - пиши на js и jquery пока не поймешь что что-то ты делаешь не так и не поймешь что тебе надо))
Одним предложением всё решается: воспроизводство железа проще и дешевле, чем воспроизводство программистов, и значит жертвовать железом выгоднее,чем человека-часами.
Я хоть аналитик и как Прогер где-то застрял в районе Джуна, думаю, что в плане удобства взаимодействия Clean code топ и там где производительность не является критичной, лучше использовать этот подход, но там где производительность критична, там уже надо оптимизировать даже если будет не клинкод. В общем всё зависит в первую очередь от задачи. Мы и правда сейчас живём в мире, где железо достаточно мощное и достаточно неплохо переваривает не самый оптимизированный код, но это также не означает, что можно говнокодить.
Самые тормозные штуки, которые видел, писали для небольшого количества данных, а потом данных стало много или назрузка увеличилась и все зависло. И без клинкода такие штуки улучшать (оптимизировать, масштабировать, переписывать без тестов) - это адище. Клинкод как раз направлен на то, чтобы этот процесс упростить. А есил у вас клинкод не упрощает - значит вы делаете что-то не так и не понятно для чего вы это делаете и так это применяете...
Был один проект с устаревшим кодом и решили ребята его переписать с нуля, понахватались где-то трендовых вещей: микросервисы, go и прочее. И давай писать, 1.5 года писали, ни хрена не смогли.
Так что если кошки вам не нравятся - значит не умеете готовить.
Неужели никто «Искусство программирования для Unix» не читал? Эта тема стара как Unix 😁 Эрик Раймонд в этой своей книге уже давно обо всём этом писал. И критика ооп и постулат о приоритете стоимости человеко-часов над стоимостью процессорных циклов. Да. Вот так и живём 🤷♂️
KISS - рулит, SOLID - сосёт))
@@che42cc его надо балансить с GRASP и здравым смыслом
А ещё там написано предпочитать текстовые протоколы бинарным в ущерб быстродействию, потому что отладку выполнять проще. И это правильно
Ага, вот только на собеседовании скажешь хоть слово против чистого кода и тебя посчитают нубом. И доказывай потом кадровику
Кроме проблемы молотка и гвоздей важно помнить о стандартизации. Как было сказано, клин кодом и его подходом пользуются миллионы. Это позволяет быстрее понимать и изменять проект. В то время как типичный Кейси может понаписать такого, что все будет работать в 20 раз быстрее, но он один будет понимать, что вообще происходит. Интересно было бы увидеть книгу в духе optimized code с паттернами написания оптимизированного, но гибкого и читаемого кода.
Только не говорите этому Кейси про микросервисы😂
Микросервисы решают именно организационную проблему. Когда очень хочется посадить несколько сотен разработчиков за один проект.
@@etodemerzel2627 а зачем нам сажать кучу разработчиков за один проект? чтобы ускорить его разработку и сохранить поддерживаемость. По моему Кейси попытался всем доказать что лучше качественно чем быстро и дешево😁
В начале 90ых, когда железо было, мягко говоря не очень производительное, писали мы лабы на бейсике, рисовали они себе круги, вычисляли массивы... Мой же пытливый ум, прочитав в журнале наука и жизнь про игру "жизнь", решил ее визуализировать. Правила простые, накидал за одну перемену. Однако смотреть на это было невозможно, каждый цикл прорисовывался с минуту. Организмы рисовались просто символами, никакой графики, но вывод функциями Бейсика принт. В итоге заморочился выводить символы, записывая их байты прям в видеопамять. Как же я охренел, увидев, насколько всё полетело. Пришлось даже задержку добавлять, чтобы можно было насладиться анимацией циклов жизни. Говнооптимизация, отрывает прогу от железонезависимости. Ни на чем, кроме тех хт это уже не будет работать, зато какой эффект.
А у нас в расте вообще нет ООП, зато свич один из самых мощных. Это к тому, что всё это давно не секрет, причем настолько, что задизайнено в основу языка.
Первое правило оптимизации: не оптимизируй. Молли просто молчит про это, оптимизируя код там, где он типа медленный. На практике расчёт площади может делаться 1 раз за запуск, и будет абсолютно насрать на его перф.
В чем проблема писать места не требующие производительности с использованием clean code, но если требуется, то оптимизировать только определенные места.
Нет проблем, все так и делают.
возможно, code style будет разный
@@CilezSayles смысл этого говноспора двух "титанов" я не уоловил
Эм... Я типо программист. Даже дипломную скоро сдаю. Вопрос: почему я об этом узнаю только сейчас? У нас в колледже даже по ООП прошлись мимолетом. Посоветуйте курсы по программированию. Есть что то по типу CS50?
@@adori.eterno программист))
Очень забавно слышать про "20 раз быстрее". На практике всё может быть куда веселее. Когда вместо простого массива значений, заводят для значений целый отдельный класс с интерфейсами, интерфейсы оных суют в хэш мэпу, а её суют в абстрактный класс, а сверху наворчивают наследование из нескольких классов... Производительность проседает в 10-20 ТЫСЯЧ раз. Реальный случай из практики.
Мне кажется, в клин коде нет призыва писать подобные вещи) И хоть они и существуют и приносят боль, к клин коду не имеют отношения.
Ну то, что несмотря на весь прогресс железа, программы становятся все монструозные и работают все медленнее - это факт. Мой свежий ноут грузится и грузит докер десктоп или идею с плагинами или вскод с плагинами, уже столько, что, извините, я успеваю сходить поссать за это время. Мой PC AT в середине девяностых грузился и грузил среду разработки с СУБД гораздо быстрее.
Ага. А когда я сажусь написать чего-то для своих ретромашин, мне почему-то больше нравится современная IDE с подсветкой синтаксиса и подсказками. Вы не захотите вернуться в вашу среду разработки середины 90-х.
@@rkurbatovэто ж не подсветки тормозят.
Запусти Eclipse, почувствуй "Разницу" :)
@@rkurbatov Подсветка синтаксиса была еще в Turbo Pascal/Turbo C++ на Досе и работала на ХТ-шках с 640Кб оперативы.
Бля, я бы посмотрел как бы этот Кейси разрабатывал и поддерживал проект из дохульярда строк, который одновременно пилят 20 разработчиков, а в общей сложности над ним работают 500 человек.
И ответ на вопрос "навернет ли твое изменение все к херам" буквально стоит миллионы.
А вы не заметили что раньше вам хватало 1 гб оперативки, а теперь уже 16гб мало. Это такой же принцип. Раньше больше парились по поводу оптимизаций и скорости, с развитием железа все меньше этим парятся, делают упор больше в сторону удобства разработки, поддержки. Правильно это или нет, это уже другой вопрос. Мне интересно что будет если АИ напишет очень скоростной и оптимизированый код, насколько сложно человеку будет поддерживать этот код. Если в будущем АИ сможет и сам писать и сам поддерживать, тогда АИ нет смысла придерживаться клин кода, он может использовать максимально оптимальную модель которая даст максимальную скорость и будет использовать минимальное количество ресурсов.
А вы не заметили что сейчас приложения имеют гораздо больше функций и гораздо более дружественные к пользователю? А весь этот такой естественный дополнительный функционал который вы не замечаетет тоже тянет ресурсы. Может потому 1Гб уже не хватает, а не только от отсутствия оптимизации?
@@dmaraptor Во-первых, это не совсем правда. Многие современные преложения/сервисы почти не отличаются функционалом от старых, но тем не менее едят в сотни раз больше ресурсов.
Во-вторых, то что у приложения больше функций, не значит, что оно должно есть в сотни раз больше ресурсов, когда пользователь не использует эти самые функции.
Мне кажется, тейк про перфоманс в мире, где питон является одним из самых популярных языков в мире и, в тоже время, одним из самых медленным, как минимум странно.
2 язык выбирается под задачи. Если нужна производительность - бери низкоуровневый функциональный язык. Нужны интерфейсы - ооп языки в помощь)
3 любые тесты по сравнению производительности надо перепроверять, так как уже не раз сталкивался с «экспертами» которые находят в версию компилятора или интерпретатора с багами с каким-то кейсом и потом показывают «объективные» результаты)
4если это большой проект, который пишут 10 лет, то без солида, дизайн паттернов и подходов из разряда «best practices» код изначально станет легаси.
У каждого сообщества есть свой Мурыч
с удовольствием просмотрел видос. Оба, Кейси и Боб имеют хорошие факты. Если первый, показывает что CLEAN CODE бывает что нагружает железо, а второй говорит что оно помагает не железу, а будущим людям которые будут работать в этом проекте, то тут невозможно сказать что всегда надо придерживаться одной методологии, ведь бывает что бизнесу нужна обычный продукт, которые будет работать (неважно быстро или медленно, а главное работало), а есть бизнес которой важен не то как "удобно" читать, а как БЫСТРО оно работает. Я считаю что надо найти баланс, если проект нуждается в производительности, а оптимизировать нечего - надо отказаться от принципов CLEAN, а если скорость неважна - то CLEAN лучше.
P.S. ВСЁ ЕЩЁ ЖДУ 10 ЧАСОВОЙ ТУТОРИАЛ ПО С++
Странно, что такой код называют "чистым" скорее бы подошло название "читабельный"
Надо смотреть ситуации когда работают большие команды программистов, которым приходится плотно взаимодействовать. Тогда на первый план выходит архитектура и интерфейсы и соответственно "клин код" или нечто подобное выходит на первое место иначе просто все развалится. Но при этом нужно понимать где есть узкие места , требующие оптимизации и вот там уже можно изголяться, чтобы достигнуть нужной производительности.
У челиков случился классический диалог слепого с глухим.
1. Подавляющее число оптимизаций в коде в виденном мной прикладном коде упрется в то, что запрос в БД своими миллисекундами перекроет оптимтзации прикладного кода.
2. Кроме этого вашего Мартина есть Фауллер, который про "полиморфизм vs switch" говорил, что многочисленные свитчи по одному enum'у, разбросанные по коду, замедляют внесение изменений. С чем согласен: не раз по просьбе аналитика, желающего добавить или убрать новое значение enum'а, составлял список использований этого enum'а в давнокоде.
То что чистый код тормозит всегда было известно. Еще в книге "Рефакторинг кода" об этом говорили - быстрый код преобразуется в чистый. Неудивительно, что код, который пишут железнячники сильно отличается от кода прикладных программистов, потому что первые что-то знают :-) Проблема быстрого кода в том, что при обрастании функционалом объем кода растет и поддерживать его будет нереально сложно. Скорее всего решение должно пойти в сторону компиляторов, которые должны преобразовывать чистый код в быстрый, т.е. преобразовывать интерфейсы в if/switch и тому подобные вещи :-)
Компиляторы не помогут. Распаковщик unrar для ZX Spectrum (автор AIG) изначально был сделан из C, скомпилированного ВРУЧНУЮ. Я оптимизировал его в 11 раз за счёт генерации кода разбора дерева на лету. Распаковщик JPEG для ZX Spectrum (автор >>RRA>>) изначально был сделан из ассемблерной программы для 68000, переведённой на Z80 ВРУЧНУЮ. Я оптимизировал его в 5 раз за счёт вылизывания трёх главных операций - выборка из битового потока, IDCT и пересчёт в экранный формат. Про 3D-движки даже говорить нечего, там всё прямо по регистрам раскладывается + используются вычисляемые переходы и патчи. Посмотрите игру Borsch.
Компиляторы с ИИ?
@@edranovdenis Не знаю, но конструкции на языке программирования наверное должны задавать не то, какой результирующий код ты хочешь получить, а какое внешнее поведение ты хочешь получить. Наверное для этого придется отказаться от каких-то базовых понятий, как таблица виртуальных методов - не факт что она всегда будет создаваться для заданного класса.
@@edranovdenis Ага, чтобы всё поведение программы зависило от GPT. Сегодня всё работает, а завтра оно решит, что вы расист и половину функций вам отключит.
то самое видео, которое не нужно ускорять в 1.5 раз
7:16 Скорее всего, "чистый код" сделан для того, чтобы люди поняли, как писать *ПОНЯТНЫЙ*, а не компактный код.
А еще, всем новичкам было бы неплохо прочитать эту книгу
Вся ценность этого видео в том, что нельзя просто взять и применить какие-то принципы и получить оптимальное для данной задачи решение. Всегда приходится думать.
Ну понятно, что ничего не понятно. Вроде бы хочется скачать что performance и clean code это противоположности, но там вылезает Кейси и говорит что его подход читабельней. Вопросик. А как будет вести себя Архитектура Кейси в Громадном проекте? Будет ли его код настолько же читабельным. Я не разбираюсь, но мне кажется что прогеры отошли в сторону Clean Code именно по этой причине, а перформанс остался для узких мест, и его как модуль можно вставить в Clean Code в места где это действительно важно, и вот тут как мне кажется Clean Code недоработан... Жаль что я не знаю ответа на свой вопрос.
Почему все умные комментарии внизу списка а умники по типу клинкод для мелких программ в топе
А где подтверждение, что Clean Code действительно делает код читабельным? Сплошной карго-культ. Никто не знает как на самом деле, но зато все верят.
Подход Casey не столько про производительность, сколько про делать логично с учётом архитектуры компьютера. Такой код будет иметь хорошую производительность без лишних телодвижений.
Классно что находятся критики, что могут измерить такое добро и предложить другой подход!
Благодарю за ролик!
Так вот почему броузер жрет гигабайты. или нет?
Пожалуй, даже не сам браузер. Достаточно посмотреть на диспетчер Хрома, чтобы увидеть страницы с потреблением памяти от 100 до 400 Мб (каждая). И добавить к этому client-side rendering всяких фронтов на модных фреймворках - и здравствуйте! - проц фоном потихоньку "что-то майнит", пока грузит страницу ютуба
Например,
Notion складывает в куки браузера по 4 гигабайта в фоновом режиме…
он жрет гигабайты, потому что ты открыл сотню вкладок)
ну вообще, оптимизация поскорости != оптимизации по используемой РАМ. вполне себе что быстрый код, может кушац больше оперативы чем медленный, но это не точно.
Именно так. Просто посмотри размеры и потребность в ресурсах компьютера MS Office 97, 2007 и самый последний. А по функционалу разница не велика. Причем большинству и функционала самой старой версии предостаточно.
И в том числе, но не только.
Сами по себе страницы в интернете стали весить больше, больше медиа, больше скриптов и тп.
С точки зрения работы ПО, 90% кода работают в редких случаях, допустим раз в день, месяц, год, а 10% кода программы отрабатывают постоянно в бесконечном цикле. Так, может тогда, на B-версии программы отпрофайлить наиболее нагруженные участки и переписать их без виртуальных функций, полиморфизма и подобного. - а 90% оставить в нормальном удобном виде.
Работая более 10 лет в ИТ на разных позициях, не могу не заметить одну грустную тенденцию: Если раньше на собеседованиях требовали понимание UML и умение им пользоваться, то сейчас на входе в каждый офис спрашивают про SOLID, паттерны и так далее. То есть, от умения проектировать и излагать решение мы перешли графомании-говнописанию, взяв за "стандарт" свод рекомендаций от чего страдает и индустрия и конечный пользователь. С легкой руки говнокурсов и solid-культистов у нас каждый второй джун может сшлепать абстрактную фабрику, но никто не сможет объяснить как это решает стоящую задачу и почему именно фабрика. Если говорить о вкате в IT и менторинге в IT, то clean code принципы должны быть на самом последнем месте, следом за паттернами. Потому как рекомендации должны отвечать на вопросы, появившиеся в процессе практики, в противном случае это превращается в очередной говнокульт аутистов.
Текущая ситуация просто замечательная: Бизнес тратит овер 9000 тонн нефти на SRE/Platform Engineers, потому как погроммисты не могут ни в бизнес, ни в архитектуру того, под что разрабатывают. Все это виснет-глючит, сыплет исключениями и срет логами дай этому нагрузку.
Думаю да проблема не в "чистом коде" и иже с ними, а в том что он не дополняет цепочку необходимых умений, а заменяет. Увы.
Я не буду рад как соискателю который только и умеет в чистый код, но и не буду рад тому кто думает и пишет так что из код можно носить как свитер.
Достаточно долго проработал на одном проекте, где бизнес требований помодульно было выше крыши. Спустя время начали расширять команду и когда поприходили молодые и в разговорах начало всплывать SOLID, DRY и т.п. начал комплексовать - неужели я так отстал... Почитал и понял что это давно ясная истина в обертке для любителей смузи или на скорую руку новых специалистов. То что приходит с практикой просто заменили "быстрой теорией" (а практику не прилагают).
@@hardcoreeptu Бизнес тратит овер 9000 тонн нефти...
Это потому что бизнес не хочет всех этих сложных схем. Ему нужно прямо сейчас пока Вася Пупкин не написал быстрее и не вышел на рынок.
Или просто не хотят, не могут услышать. Или зачастую некому предложить и обосновать подход к решению вопроса в котором стоит планирование и стратегия развития самого кода.
@@hardcoreeptu Также бизнес тратит огромные бабки на урегулирование отрасли все теми же методами, которые привели к такому поожению вещей, что сравнимо с тушением костра бензином. По типу: мы потратили человеко-тысячеления и миллиарды и придумали эджайл с микросервисами, лишь бы не увеличить ФОТ отдела разработки. Правда его все равно придется увеличить, наняв менеджеров, аналитиков и скрам-мастера, и поставив во главе бестолочь с гордым названием "архитектор" но это другое, вы не понимаете : ) По сути, это карго-культ. Но иначе не получается.
Патерны и есть clean code
Как же я надеюсь, что с развитием нейронок программисты хоть обложатся со всех сторон клинкодом, хоть маркером интерфейсы рисовать будут и потом будут двигать ноды, но в итоге нейронка, будучи прослойкой на пару с оптимизатором компилятора, будет ориентирована на оптимизацию того, что получилось, следуя принципу: сохрани функциональность такой, как хотел мясной, но бесконечно стремись к оптимизации. Вот только компании, которые это бы могли внедрить давно забили на своих пользователей и на их комфорт. Некоторое даже открыто говорят "все лягает, да? Так купите себе нормальное железо, мы то тут при чем?", а самим производителям железа это даже выгодно. Делать все более красивые цифры, которые фактически не привносят улучшений, по тому что ПО жрет все больше, не давая улучшений. Я последнее время открываю многие программы к старым версиям по той причине, что функционал либо не изменился, либо изменился незначительно, а жрать они стали заметно больше, так еще и стабильность уменьшилась. В целом скажу так: я надеюсь на оптимизацию, но не верю, что большие компании почешутся, пока под их ногами не будет гореть земля от критики оплёванных клиентов
А как контролировать, что там нейронка наоптимизирует и как это отлаживать, если что-то не работает?
@@АлександрОрлов-п9ч Так же, как сейчас все остальное делают с нейронками. Обратное распространение ошибки в случае, если код работает не так, как ожидалось. А про контроль... Ты же не проверяешь за компилятором, во что он превратил код? Вот и тут проверять никто не станет просто так. Если что-то не так, нужно лишь сопоставить с оригиналом кола и если там все работает, то дать нейронке обратную связь. Она скорректирует веса и даст новый ответ. Но что-то меня в нейронную базу понесло. В общем, я ожидаю то, что легкочитамый говнокод станет чем-то типа промпта для такой нейронки, а в ответ она выдаст уже что-то адекватное. Далее может быть ещё несколько генераций, итерации проверок и тестов производительности. Лучшее будет выбрано и в дальнейший тест на соответствие хотелкам человека
О! Наконец-то кто то решился разобрать по фактам весь этот оверинженеринг, который пропагандируют с каждого утюга.... простой пример - любой учебный проект типа Hello World на чистом коде это 100500 разных абстракций погоняющих друг другом, черт ногу сломит понять где что и зачем... а надо то всего std::cout реализовать. а потом удивляемся что софт лагает, пишут то его те кто по таким учебникам учился.
не знаю как в других сферах, но в web всё лагает из-за фронта. И вот фронтеры как раз преисполнились, отреклись от богомерзкого клинкода, ооп и прочих ваших задростких штук.
А по итогу на 12-ом поколении intel ютюб безбожно лагает. И лагает не подгрузка видео или ещё чего-то, а именно фронт. Вот пока пишу этот комментарий, горю от киселя, вместо ввода.
На моём, хоть и не большом опыте, бэк в вебе тормозно работает либо совсем с большими данными, либо когда как раз избегают "оверинженеринг" и не переносят в какие-нибудь очереди то, что должно быть в них.
Кейси, кстати, крайне недооценён имхо, но это идёт на поправку. Его сейчас в том числе достаточно известный ThePrimeagen пиарит. Сейчас вообще достаточно интересные события и персонажи из сферы программирования на ютубике пробиваются :)
Вот вроде видос ни о чем, просто про срач двух айтишников, но подача аргументов и примеров делают видео очень интересным. Хорошо преподнес тейки Кейси. Думаю можно было даже побольше показать примеров плохого/хорошего кода.
Кароч спс за видос, было очень интересно
в видео только один аргумент, и это скорость работы кода. Все остальное автор растекаться мыслью по древу.
Всё что я понял из видео, так это то что, если мы программируем что-то маленькое, то можно использовать клин код, чтобы сделать это быстрее, а если делаем что-то больше, например АААА игру, то нужно всё оптимизировать обычным старым кодом.
Тотал коммандер, новороченный по самое нехочу файл менеджер, с огромной библиотекой расширямый плагинов, занимает всего несколько мегабайт. Простое приложение ютуб на телефон, с мимимуи функций , жрет больше гигабайта. Что то определенно пошло не так в мире программироваания за эти годы )
Это точно не из-за следованию принципов clean code.
@@vifvrTtb0vmFtbyrM_Q Уверен что там точно вынесено все куда надо. Ну и не стоит забывать, на сколько я понял Кристиан писал его сам а не команда.
Тотал коммандер - единственная программа, которой я продолжаю пользоваться с тех пор как у меня появился первый компьютер. К слову, он вроде на паскале написан.
Ни разу я еще не видел, чтобы бутылочное горлышко какой-либо программы было в виртуальном вызове. Ну и самом собой, что какую-нибудь суперкритичную алгоритмику нужно писать не как программисту удобно, а как машине проще считать. Тут ребята оба правы и странно что они не сошлись на едином мнении.
Я ещё помню те времена, когда говорил, что преждевременная оптимизация -- источник всех бед :)
Все эти микрооптимизации хороши до первого сетевого запроса или неоптимальный выборки из базы, которые съедят всё, что вы наоптимизировали
Полная цитата говорит именно об этом: "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%."
@@sergei_sergeich и потом мы получаем игры, которые по графике хуже игр 2000 но требуют 4090. Да хули заморачиваться писать оптимизированный код, если можно быстро тяп ляп хуяк и в продакшн.
Правда в том, что писать оптимизированный код не сложно и не долго, но приходит с опытом.
Ты просто уже на автомате знаешь какие конструкции и алгоритмы быстрые и сразу их пишешь.
Программирование с опытом становится стенографией, где ты пишешь код на автомате.
Твоя цитата человека, которому похуй на код и его производительность. Ему надо нанять джунов, которые за два рубля напишут любой работающий код и он сможет продать это за сотни рублей.
@@sir.Geronisтормозные игры - плохой пример, потому что геймдев - это одно из исключений из правила о преждевременной оптимизации, т.к. о скорости работы нужно заботиться на всём процессе разработки. Ну а появляются такие тормозные игрули из-за того, что даже те самые 3% из цитаты не подвергаются анализу производительности, и лепится всё "как есть". С таким подходом писали тормозное г-но и без всякого клин кода.
@@0imax игры эьто очень хороший пример. Но если тебе не нравится. То давай возьмем офисные приложения. Которые весят десяток ГБ, требуют не один ГБ памяти, только для запуска, а для полноценной работы требуются еще несколько ГБ. И в тоже время есть альтернативные офисные решения где в десятки раз меньше ресурсов требуется. А мобильные приложения, калькулятор 120МБ. Банковское приложение 500МБ. И тп.
Таких примеров милион. Просто надо открыть глаза и прекратить сыпать в них соль. А игры это просто самый наглядный пример, где слово оптимизация потом взята за аксиому.
А знаешь, из-за чего появляется по-настоящему фиговая производительность в больших проектах?
Из-за того что один программист наоптимизировал всё, влепил внутри одной функции, а другой вызвал эту оптимизированную под 1 задачу функцию в немного другой задаче, где половина этих операций совсем не нужна. От того, что люди пишут не очень чистый код, другие просто их не понимают полностью и ломают производительность ещё больше, чем если бы код был чистым.
На сколько помню, в самой книге данная тема была частично затронута как "преждевременная оптимизация", в ней говорилось примерно о том, что эффективнее писать clean code, а затем оптимизировать если нужно.
P.S. Как-то смотрел source код blender, подробно не изучал, но по первому впечатлению он довольно читаемый, особенно для C. При этом я не помню чтобы в самом blender интерфейс как-либо подтормаживал.
Плюс опять же какие-нибудь "такты процессора" это уже проблема компилятора как по мне.
"такты процессора" уже давно никто не считает кроме embedded разрабов.
Раньше уповали на то, что производительность железа каждый год увеличивается в 1.5-2 раза, так что это было не так важно. Сейчас хоть и другие времена, но всё равно время разработки обычно важнее производительности: хорошо платить программистам меньше за меньшее время работы и получать больше за частые нововведения.
На самом деле если ты разбираешься в том, как работает весь этот ООП на низком уровне, понимаешь какой код генерирует компилятор, с умом используешь все его фичи, собирать с проект с опцией -О3, то ты можешь писать производительный клинкод, работающий ничуть не хуже кода, ООП не использующего (а если ещё применять параллелизм и simd, так вообще всё будет летать). Проблема в том, что это верно только для языка C++, т.к. программы на нём компилятся непосредственно в машинный код CPU, и представлять себе, какой код будет сгенерирован из той или иной строки исходника при должном опыте сравнительно легко (в особых случаях можно дизассемблировать и проверить). А вот работа виртуальных машин Java, C# и пр. совершенно непрозрачна. Как там реальзовано ООП под капотом не ясно. Отсюда и лаги. Байткод - зло)
А можно не ебать себе мозг, не использовать ООП и писать используя процедурное программирование. Код получится проще, легче понимать что комп будет делать, производительность будет лучше сама собой и т.д. ООП это слишком высокоуровневая хрень. Использование его повсюду в проекте не даёт никаких плюсов, а одни только минусы.
@@etodemerzel2627с вами не соглашусь. ООП - это не какая-то мегавысокоуровневая хрень, а по сути синтаксическая надстройка над т.н. обычной процедурной парадигмой. Ведь что такое программа? Это данные, плюс код, обрабатывающий эти данные. В процедурном программировании данные - это переменные и структуры, а код - функции, работающие с ними. Назовите структуры классами, а функции - методами, либо фунуциями-членами - вот вам и ООП в первом приближении) Те же яйца, только в крутую))) А для ассемблера вообще без разницы. Программы получаются кривыми не от выбранной парадигмы, а от кривых рук программиста.
Наш Сеньер на старой работе всегда твердил сердито, что Чистый Код это хуита и инфоцыганство, все над ним посмеивались, мол бумер опять раскряхтелся, а тут вон оно как...