Сам удивлён. Тупые программисты следуют тупым правилам в тупых корпорациях, зарабатывающих тупо много денег и пилящих тупо огромные продукты. Хорошо, что есть нетупой Муратори, который всем расскажет, что все тупые. Спасибо ему. Как мы без него жили.
@@Macbaren-s2o А ему ответить нечего по факту. Я выше описал про убытки хостеров и корпораций от тупого псевдо-чистого кода. Автор после этогон что-то аргументировал? увы... ибо я описал по факту как обстоят дела.
Я в коде ищу только одного: умиротворения и вот этой гармонии от слияния с бесконечно-вечным. На дворе благодать и мне этот Мураками абсолютно понятен, но ему не понять
Книги Мартина хороши, но если не пропускать их через свой критический анализ - то можно заболеть "чистым кодом головного мозга". Мартин не пишет профессионально код уже лет 20, и сколько бы он не пытался говорить нам, что код 40 лет назад и код сейчас ничуть не поменялся. Но любой разраб в текущей энтерпрайз разработке скажет, что это не так... Поэтому и воспринимать его советы без критического анализа - просто нельзя. Интересно, а пользовался бы Алексей nvim если бы он не был такой отзывчивый? А ведь это всего лишь текстовый редактор, для него уж точно не важна скорость работы. Почему многие так сейчас становятся недовольны vscode, его отзывчивостью? Почему всех бесит когда тормозит чат приложение? Почему всех бесит когда тормозит браузер? Почему всех бесит когда тормозит камера на его телефоне? Кто бы что не говорил - отзывчивость/скорость работы - важна. Но важна ровно настолько, чтобы она не бесила пользователей :)
Я ж говорю в видео - есть РАЗНЫЙ софт. Для веб-сервисов такты процессора считать не надо, это всё сожрётся медленным интернетом как минимум, и ускорение работы веб-сайта это не про замену полиморфизма if'ами, это по влиянию на результат в реальной системе там на каком-то трехсотом месте будет, то есть это надо делать, выполнив 300 других направлений - внедрение кеша на разных уровнях, разбивка сервисов на более мелкие иногда, оптимизации фронтенда, ленивая загрузка, SSR и тд и тп.
@@fatoldhikki4837 чистый код недостижим, но это не значит, что на эти принципы можно забить. Успехов вам развивать в погоне за тактами процессора приложение, нарушающее LSP, то есть содержащее логические ошибки. Нарушающее OCP, когда в одном и том же коде начинают копиться конфликты. Нарушающее SRP, с GOD-объектами. Нарушающее DIP, когда, чтобы изменить приложение надо менять пол системы, плодя баги. Нарушающее принципы именования (привет I, j, av, bz нейминг). Нарушающее модульность - весь код одна простыня. Ус-пе-хов. И еще никогда не пишите ни на чем кроме ASM, потому что теряете такты, любая абстракция как правило не zero-cost. Лучше всего писать поверх железа без готовой ОС, разработав свою ОС под конкретную архитектуру CPU, все будет очень эффективно и заточено под твою задачу.
@@t0digital спор глухого со слепым) та же вакханалия, которая творится во фронт разработке с бандлами превышающими все лимиты - это разве не про эффективность и верхнеуровневое программирование? тут разговор не про ассемблер и не про то, что каждой задаче свой инструмент, а про адекватность в подходах. что и клинкодеры и производительности-дрочеры могут сильно упороться в какую то из крайностей и что из этого ничего хорошего не выходит
@@t0digital "крайности - плохо. Концовка видео об этом" - но при этом вы сами же бросаетесь в крайности. Когда говорят об архитектуре кода переводите стрелки на названия переменных... Говорите о каком то куске кода, когда все ваше приложение покрыто тоннами абстракций, избавившись от которых вы сможете его ускорить. Приплетаете зачем то ASM, когда можете написать и на выбранном языке в десятки раз быстрее. Выложили кусочек кода в тг, дабы доказать что те кто думает о производительности, называют переменные буквами....
Всё зависит от того чем занимаешься - если ты пишешь код базы данных, то к тебе совсем другие требования будут и если ты оптимизируешь только бутылочные горлышки, то получишь равномерно медленный код, который больше негде оптимизировать. Поэтому есть случаи когда производительность должна быть заложена в архитектуру. Или например сервис высоконагруженный пишешь - там уже не до питона, сразу надо нормальный язык использовать и думать о производительности всегда.
Алексей, спасибо! Когда слушал, как раз, хотел написать про золотую середину. Формат видоса "что-то обкашлять" отличный! Подача, как всегда, на высоте.
Мне этот спор абсолютно понятен...На мой взгляд можно сократить до фразы есть задачи упирающиеся в IO, а есть в CPU, ещё в gpu, тензорные процы и подобное. Однако, как по мне, панч Муратори в том что код, который написан без принципов clean code внезапно более производителен с точки зрения написания и чтения кода, но тут, ИМХО, вред слепого следования паттернам, головой надо думать)
Головой надо думать, да:) 17:39 и дальше об этом. Но если не следовать принципам clean code, значит можно именовать переменные j, i, a, d, можно писать функции на 5000 строк кода, делать GOD-объекты вместо грамотной декомпозиции, жестко простраивать зависимости от реализаций вместо DIP и тд. Быстрее ли написать такой говнокод? Да, конечно, но затем непременно будем иметь проблемы с его поддержкой, если проект долгоживущий и развивающийся.
@@t0digitalну это ведь подмена понятий с твоей стороны. Если не клинкод, значит обязательно функции на 5к строк и плохой нейминг. Кейси привёл отличный пример, когда уменьшается количество абстракций, при этом код всё ещё понятен. Будто ты сам никогда не дебажил какой-то код, где у тебя 33 абстракции и ты go to definition всё дальше и дальше вглубь воспалëнного сознания разработчика
Ну где подмена понятий-то? Clean code это далеко не только solid. Вы читали книгу саму? Там дай бог процентов 10 про solid. Не следовать конкретным 5 принципам (SOLID) из общего набора, скажем, 500 clean code принципов это значит не следовать clean code, но если не следовать другим 5 принципам из clean code, то это уже плохой пример неследования clean code. Чойта)?
Я смотрел оригинал Муратори, ссылка есть в описании. Он выдернул 5 постулатов клин кода (из сотен постулатов клин кода), назвал эти 5 постулатов клин кодом (а где остальные сотни?) и показал, что они ухудшают производительность и потому клин код говно. Так может остальные сотни постулатов увеличат производительность? Клин код как раз про понимаемость и расширяемость кода. Да, местами где-то производительность ниже, но не в 24 раза в рамках всей системы, потому что на if/else без абстракций всю систему не напишешь. Вся индустрия ушла от asm в более высокоуровневые языки именно поэтому. Управление сложностью, в том числе через грамотное использование абстракций. Муратори хайпожор.
@@t0digital Вы действительно не в теме. Муратори лишь указал на неэффективность клин кода в некоторых сферах разработки например геймедев, где циклы процессора действительно важны, а освобожденные ресурсы можно пустить на прожорливый рейтрейсинг. Причем тут asm? Если что Муратори это практикующий программист, не распространяющий бесполезную философию вроде Мартина и Макконела, у него есть канал Molly Rocket, где он пишет игру + движок загляните - это интересно.
@@t0digital Муратори... показал, что СС, во-первых, не имеет никакой доказательной базы, "поддерживаемость", "читаемость" -- личное мнение каждого отдельно взятого гуманитария, верующего в Мартина, во-вторых, показал, как без СС код становится более "читаем" и всё прочее. Таким образом, заключает Муратори, СС -- культ карго, в который верят исключительно гуманитарии, нет ни единого основания принимать его всегда и везде. рекомендую всё-таки читать первоисточники, прежде чем позориться на аудиторию из профессионалов.
@@КириллКирилловичутверждения Муратори про повышение читаемости при кодинге в его стиле точно так бездоказательны. Они строятся буквально ни на чем, поэтому предмет спора пуст. Все же думается, что большинству людей проще понимать абстракции, чем компиляторные команды
19:10 Так проблема в том, что не известно для каких задач какие инструменты подходят и более эффективны. Кто-то например считает, что на Python нельзя писать ПО с повышенным требованием к правильности работы, а нужно использовать Ada или Rust. Кейси как раз и заявил, что надёжно и понятно можно писать не используя паттерны клинкода и это ещё будет быстро.
Насчет тактов процессора. Если взять на чистом си написать небольшую программу, откомпилировать. А затем дизасемблировать и посмотреть что сделал компилятор в ходе оптимизации. То можно очнь сильно удивиться. А если посмотреть на ключи компилятора, то можно увидеть ключ с разными уровнями оптимизации. И для того чтобы считать такты процессора нужно, как минимум, знать что и как компилятор оптимизирует.
Почему многие так зацепились за "такты"? Помимо тактов есть еще немало нюансов, которые влияют на производительность. Например кэш - полный размер, размер кэш-линий, алгоритм работы. Отсюда ростут ноги оптимизации структур, циклов, небольших функций. Это помогает оценить "стоимость" локальных переходов и вызовов/возвратов. Так, например, в коде с короткими функциями переходы по if/switch не будут вываливаться из кэша и уод будет быстрым. Но если вместо этого вы превратите код в классы с виртуальными функциями, то процессору придется метаться кабанчиком по указателю на VTable, загружать по смещению адрес функции, заливать в стек состояние части регистров и аргументы функции, делать вызов, а потом возвращать все обратно взад. В этом случае увеличивается не только количество команд (тактов), но и количество cache miss-ов, которые приводят к куда бОльшим простоям CPU. Можно сказать, что это актуально только на "низкоуровневых" языках типа с/с++, но увы. Даже на с# базовые знания архитектуры помогают ускорить код, иногда даже в разы. В качестве примера можно взять Unity -- они добавляют все больше средств для эффективной работы с данными из новых версий c# и местами переписывают структуры (на C#, не на С++), чем заметно ускоряют движок даже при выполнении на VM
И, кстати, такты процессора уже давно почти никто не считает, так как это очень геморное и неблагодарное занятие из-за длинных конвейеров. Одна и та же команда в разных фазах луны может отработать быстрее или медленнее. Так что нужно рассматривать код и данные в целом.
) это не только из-за чистого кода, это из-за кучи аспектов архитектуры процессора ядра и тд, из-за simd операций, из-за миллионов способов отразить треугольник, из-за 505 способов обнаружить столкновение кубиков друг с другом и тд
Желательно, чтобы любой комментирующий в ЭТОЙ теме указывал в каком проекте он работает: 1) размер команды 2) количество внешних интеграций 3) количество строк кода ( да-да-да! ) 4) количество бизнес-сущностей в системе 5) срок жизни проекта 6) сколько работает в проекте 7) сколько работает в отрасли Вот тогда можно отделить кровавый ынтырпрайз от плевел и узнать мнение разработчиков участвующих в РЕАЛЬНО больших проектах. Мартин, если что, столуется в MS у которого опыта в кровавых ынтырпрайзах явно достаточно, чтобы продвигать его идеи ;) p.s. это как спор perl vs python: первый ещё называют write only ЯП
Крайности рассматриваем. А хотелось бы разумного, более взвешенного обзора. Да и без примеров, по дороге с облаками про код говорить - простое увеличение энтропии вселенной, которая и без того велика.
Нет, крайности не рассматриваем. Более того, в видео явно говорится о том, что крайности и догматизм это плохо. Касательно примеров - если вы не можете говорить о разработке без примеров кода, то пока что вам рановато смотреть такие видео.
По факту всё разложил! Полностью согласен с автором видео. Слишком много шума из-за этого не очень грамотного и всё максимизирующего Муратори. На самом деле шумность комьюнити по этому поводу лишь подтверждает общую деградацию программистов в среднем по палате.
Рост производительности процессоров пропорционален (в каком-то приближении) снижению производительности программных компонентов. У этого огромное множество причин. Потребитель платит за это своими деньгами покупая более дорогие комплектующие (которые на этом фоне еще и растут в цене). Всех все устраивает, когда все так работают. Можно представить себе ситуацию, когда на рынке появятся альтернативы, которые в какой-то мере решают эти проблемы, тогда рынок порешает и потребить проголосует своим кошельком. Мне кажется мы приближаемся к точке, где такой сценарий может сработать. Программист (какой-бы крутой он не был) слабо представляет детали реализации программных компонентов, которыми пользуется, жизни не хватит разобраться во всем в деталях. Он может даже не представлять на какие аспекты его работы может повлиять повышение производительности различных систем. Лично я хотел бы увидеть смещение парадигмы в сторону производительности, та и мне кажется сейчас это уже происходит.
Это всё сферические рассуждения про производительность базы данных vs кода на прикладном языке. Но я вот в своей практике неоднократно сталкивался с ситуациями, когда, например, БД отвечает за 100 мс, а вот руби после этого обрабатывает её ответ 2-3 секунды. Хотя руби выступает не более чем в роли какого-то шаблонизатора (это вот почти как в примере Кейси со смайликом). И даже с джавой (которая быстрее руби кратно сама по себе) я видел как достигли примерно аналогичной производительности наворотив микросервисов вместо прямых вызовов функций. Финал обоих случаев - код, который писали пару лет (и на который потратили уйму ресурсов), просто тупо снесли нафиг и заменили на вменяемый код с процедурами и циклами.
Я такого на своей практике не видел ни разу, настолько непрофессионального кода. И чтобы проблема его производительности была именно в излишних абстракциях - ну оч сомневаюсь. Говнокод, когда человек совсем не умеет кодить, это да, это может быть.
@@t0digital тонкость в том, что "профессионализм" - очень относительная вещь. Я понимаю, что вы не видели ни разу такого кода. Иначе вы бы не сняли такого видео. Но этот код буквально везде вокруг нас. Причём с точки зрения Мартина - это именно что высокопрофессиональный код. С точки зрения Муратори (да и моей тоже) - говнокод. И тот код, который описывал я - был написан именно по канонам SOLID. Буквально single responsibility principle домноженный на микросервисную архитектуру - это полная катастрофа. Собственно в исходном обсуждении (откуда вся эта тема и пошла) Муратори именно на примере веб-кода показывает, что следование принципам, проповедуемым Мартином приводит к тотальной просадке перформанса, которую не перекрыть никакой субъективной "читабельностью". Тем более что с моей точки зрения когда ты наворачиваешь тысячи функций вместо десятков ни о какой читабельности даже и речи быть не может. Это и есть говнокод в чистом виде! То есть просажены и читабельность и перформанс, но зато все смотрят друг на друга, улыбаются, и миллионы программистов в мучениях порождают ещё один говнопродукт, который будет потом выброшен в помойку. Но всем плевать пока бабки в отрасль текут рекой.
1. Я 20 лет в айти. Не видел такого кода, но он вокруг нас. Ну окей. 2. Вы уверены, что понимаете, что такое чистый код Мартина? Что такое чистый код Мартина, можете сказать? Вы читали книгу или судите по Муратори, который взял 5 пунктов, почему-то назвав их чистым кодом? 3. Нет, Муратори не показывает на примере веб-кода. Какой там веб-код, там пример с фигурами, при чём тут веб? Веб это: а) чаще всего не C/C++ б) фреймворк, чей код в бОльшей степени выполняется в рантайме, а не ваш код, на 1 строку вашего кода там могут сотни строк фреймворка выполняться, который вы не контролируете вообще в) это коммуникация с СУБД г) если это микросервисы, то это коммуникация с внешними сервисами. В любом случае это много IO. Ничего этого нет у Муратори. Его пример вообще не про веб. Читабельность не субъективна, читабельность можно измерить методом экспертной оценки - вполне себе объективно. Набирается экспертная группа и она сравнивает разные варианты кода и говорит, что вот это более читаемо, а вот это менее читаемо. Хотя полиморфизм vs if/else это в большей степени про расширяемость кода, а не читаемость. > Тем более что с моей точки зрения когда ты наворачиваешь тысячи функций вместо десятков ни о какой читабельности даже и речи быть не может. Это и есть говнокод в чистом виде! Простите, вы тотально неправы. Главная задача функций в улучшении читаемости кода. Вместо того, чтобы читать реализацию в 15 строк кода и думать, какую задачу эти 15 строк кода решают, вы читаете вызов понятно названной функции и не тратите время на изучение реализации, если вам это не нужно в текущий момент. Главная задача функций не в DRY, а в увеличении читаемости кода. Если функция будет вызвана всего в одном месте это не повод не создавать функцию. Я не буду дальше продолжать этот спор. Вы всё равно не прислушаетесь (почитайте про эффект Даннинга-Крюгера), а я просто зачем-то потеряю время. Успехов.
1. Я в айти 32 года (с 1992-го). И я начинал с написания многопоточного (по настоящему, параллельно исполняемому на разных процессорах в рамках одной вычислительной системы) кода на ассемблере. Надеюсь этого достаточно и к фалометрии мы более не вернёмся. 2. Разумеется я читал эту книгу. И не только Clean code, но также Perfect code и ещё много других подобного толка. И когда я читал некоторые из них, в определённых местах я смеялся в голос и дискутировал по поводу прочитанного с коллегами. Потому что прочитанное было наивно до смешного. Я прекрасно понимал что в реальных промышленных системах применение некоторых из этих правил очевидным образом приведёт к провалу проекта. Впрочем не все были со мной согласны. В конце концов кто-то же написал (точнее при ком-то был написан) тот код, который потом пришлось снести. ;-) 3. Это видео - только начало темы. Далее случилась публичная дискуссия между Кейси и Бобом тут: github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md , где Кейси в какой-то момент замечает, что "...while trying to edit this very file on github that if I type a paragraph that is too many lines long, it starts to get very slow and it's difficult to type!" (можно поискать по тексту и почитать что было далее). Github - это же веб-код? По-моему веб. По крайней мере если это не веб, то я не знаю что такое веб. По поводу функции в 15 строк кода vs сколько-то меньше (я так полагаю) это тоже очень старая (для меня) дискуссия. Главная ошибка, которую сторонники вашей позиции совершают, заключается в том, что вы не учитываете, что разбивая эту функцию в 15 строк кода на 5 или сколько-то больше функций вы добавите ещё 10 строк описаний самих функций. А если вы будете разбивать это всё на классы (как рекомендует Боб) - то ещё больше. 30-50-... строк сверху. И это всё НАДО будет прочитать. И не дай бог вам потом разнести эти классы по разным компонентам (суть "микросервисная архитектура")! Но чёрт бы с количество строк. Главная проблема в том, что вы из одной сущности (последовательно исполняемый кусок кода) лепите 5. А человек не в состоянии удерживать в голове слишком много таких сущностей. Поэтому как и показал Кейси в своём исходном видео вы в какой-то момент не заметите что вы пишете один и тот же код, причём код низкоэффективный и никому уже (включая вас!) непонятный. Я видел много таких проектов (легаси, ага), которые понаписавшие их бросают, потому что не в состоянии ни исправить их ни поддерживать и бегут как "профессионалы с опытом" строчить ещё один такой же кривущий проект с нуля. Это настоящая беда современной айти-индустрии, увы.
Это потому что SOLID и микросервисы головного мозга. Надо всегда с умом подходить к задаче и не наворачивать лишних сущностей где в них нет необходимости.
Сегодня смотрел видео Виндертона, обдумывал что да как. Пришел к выводу, что clean code сейчас не про эффективность, а про то, чтобы все программисты открывая код, писали в одном стиле, скажем так. И не было проблем в дальнейшем изменении или обновлении кода
не совсем. клинкод не защитит от проблем. да и в одном стиле писать всем это недостижимая мечта. а вот что сделает клинкод так это сократит количество человекочасов на освоение и поддержку кодбазы. если простыми словами то клинкод это меньшее зло, и индустрия с удовольствием его приняла чтобы банально срезать косты. точно так же когда-то придумали высокоуровневые языки чтобы было проще. и точно так же придумали низкоуровневые языки чтобы не писать ассемлер. и точно так же ассемблер придумали чтобы не писать код на целой коробке перфокарт которые весят 5 кило.
Чистый код - это инструмент инженера (ножичек по ролику) для управления сложностью решаемых кодом проблем. Вокруг него выстроены целые комбайны (кодогенераторы, IDE, верификаторы), работая с которыми, если не придерживаться стиля СОЛИД, получим чудо-чудное монолитно-падучее ... с которым уже никакие такты и оптимизации не справлялись, ибо падало, и очень оптимально, и нередко тянула за собой и базы, что выливалось в человеко-часы любви и дзена.
Чтобы программисты были легко взаимозаменяемы, можно было их увольнять/нанимать повышать конкуренцию на рынке труда и снижать им зарплату. По идее, программисты в своих корыстных интересах должны саботировать клинкод, если хотят себе высоких зарплат.
ну кстати, иногда понимание внутренней реализации python, позволяет оптимизировать код не прибегая к переписыванию на rust или c. tuple вместо list когда не нужно изменять коллекцию, слоты в дата-классах чтобы немного память по экономить. в общем просто нужно хорошо знать свой инструмент.
@@redneck_prm5429ну по поводу коллекций, на мой взгляд тут просто здравый смысл. А про слоты... если в какой-то класс их руками класть, выглядит скажем так себе. а в dataclass просто один аргумент в декораторе указать. красиво, да и лишнюю динамику уберёт. мы всё-таки как правило в большинстве случаев не добавляем в объект поля динамически, а работаем с фиксированным их количеством.
Использовать list без append - это как и зачем? Не нужны добавления данных в структуру - юзай tuple, это понятно, но у tuple и нет append. А чем плох break с точки зрения производительности?
Справедливости ради, ориентироваться на питон и типовые веб-серверы в данном споре немного странно. Страннее было бы только bash-скрипты приводить в пример. Насколько я понял, они всё-таки спорили не про то, что clean code не имеет области применения, а про то, что область применения clean code ограничена, при этом в книгах дяди Боба эти ограничения не упомянуты. И про то, что производительность и читаемость кода не всегда противопоставляются друг другу, а производительный код может быть читабельным и сопровождабельным, но при этом он не будет соответствовать clean code'у. А вот код, соответствующий clean code'у, производительным быть не может. В общем в видео всё сказано правильно, только к обсуждаемому спору прямого отношения не имеет.
Да, Python всего лишь (по ряду рейтингов, TIOBE, например) самый популярный язык программирования в мире на сегодня, ориентироваться на него действительно странно.
@@t0digital В данном споре да. Проблема очевидно не в популярности, а в том, что если речь зашла о производительности, то питон тут не показателен, просто потому что питон сам по себе медленный. Есть, конечно, ещё числодробилки, но и в них всё, что пишется на питоне к производительности не критично. В общем опять вроде всё правда, но к теме никак не относится.
Python медленный, но тем не менее на нём пишут много кода, судя по рейтингу - так почему не говорить о его производительности, чистом коде на питоне и тд? Не понял твою мысль.
@@t0digital Потому что на питоне пишут код, для которого производительность как правило не критична, или не очень значима. Рассматривать спор о производительности подхода к программированию, используя ориентир, для которого производительность почти не важна, не имеет смысла. Этим можно только доказать, что производительность кода не всегда важна, но кто вообще с этим спорил?
Изначальный спор - клин код говно, потому что он в 15 раз медленнее. Я оспариваю это заявление. Применим ли клин код к питону? Конечно. Если верить этому утверждению, пайтон разрабы должны перестать писать клин код, потому что он в 15 раз медленнее. Но а) это не так б) клин код не замедляет производительность всегда, в общем случае, по умолчанию, потому что клин код это гораздо больше чем SOLID, названа переменная e (не клин код) или employee_index (клин код) - разницы в производительности никакой не будет. Однако i у тебя ни один вменяемый код-ревьюер не пропустит на ревью, что на питоне, что на чем угодно, потому что это ВАЖНО!
Придумать нелепые примеры и победить их - замечательно) манипуляция называется "соломенное чучело". А по существу вопроса - речь в видео Муратори идет об увеличении производительности в десятки раз, а не на 10%.
В десятки раз можно оптимизировать производительность куска кода, заменив где-то локально один кусок кода на другой. Вот какой-то кусок из 300мс сервиса работает 10мс и вы его сжали до 0.05мс, увеличив производительность в 200 раз. Однако общее время сервиса уменьшилось с 300 до 290 мм всего, на 3%, а не в десятки раз. Чтобы изменить в десятки раз производительность всей большой системы - нужны куда более радикальные подходы, которые уже не называют оптимизацией.
@@t0digital помнится, как один из модеров уменьшил время загрузки GTA 5 в среднем с 60 с до 10. 1 строкой кода. с точки зрения часовой игровой сессии - ускорение где то около процента, но оказалось что это очень сильно заметно.
@@t0digital У вас Подмена понятий, манипуляция. Даже ваш пример,эккзотический будет на физическом ядре хостера ,оторый ДЕЛИТ своё процессорное времяъ\циклы на работу с другими хостерами! Что вы юлите?!??
@@necroticuss6780 Современный серьезный веб-проект с мало-мальской нагрузкой не делит ядро CPU между кодом приложения и хранилищем - хранилище вынесено на отдельный сервер или кластер серверов с репликами. И понизь свой тон, не знаешь ни хера и споришь до усёру.
Не совсем понял, как будто смысл здесь одинаков и слева и справа после запятой, но напрашивается противопоставление. Имелось в виду, что клинкод лучше простыни кода в больших проектах?
Ещё тейк помимо оптимизации только с профайлером - копать в сторону синтаксических анализаторов и перестройку ast дерева, вне зависимости от языка, чтобы всякие солиды автоматом раскладывались до if/else, а для проверки корректности есть тесты, которыми мы уже обмазались 😊
Я в своих тактах настолько преисполнился, что мне этот клинкод абсолютно понятен... Надеюсь, Алексей в итоге не пересек случайно границу, пока сто триллионов миллиардов лет шло А вообще упущен момент, что добавление абстракций может именно усложнять, а не облегчать читаемость кода, потому что больше в голове смыслов надо прогружать, чтобы разобраться, что здесь происходит. Ну или как минимум подготовить базу паттернов в голове заранее, что является усложнением в моменте, которое подразумевает пользоваться плодами упрощения позднее
Вроде бы поинт был в том, что "чистый код" не только медленнее, что понятно, но его и читать на самом деле сложнее, и он тратит больше времени программистов.
Посмотрел пример и он не делает никакой полезной работы, потому сложно сказать, что он написан производительно. Как пример не клин кода можно взять код dwm, можно рассмотреть читабельность файла на 3000 строк кода. Хотя наверное есть примеры и лучше. С радостью пишу коммент для хайпа и развития канала
Закон Парето эмпирический, и в реальности цифры 80/20 могут очень широко гулять, да и далеко не все подчиняется этому принципу. Душить закончил, за видео спасибо!
Да, малое число факторов оказывает большее значение, чем большое число тривиальных факторов. Работает не везде - пропасть нельзя перепрыгнуть на 99%, например.
@@PlayGameToday job hopping, единстывенный способ в рф, поднять свой уровень дохода и сменить спектр задач на более сложные и интересные. нет ничего ненормального, просто такая сейчас тенденция.
Читая "чистый код" я тоже порой офигевал от его советов, но потом понял, что это лишь рекомендация, типа делай функцию 10 строк. Вроде норм совет и простой, а попробуй в проекте огромном сделать все функции в 10 строк, да там хренота полная ж будет :) У меня тоже есть проект где каждый клиент жрет довольно много ресурсов цпу и озу, тоже думал может где нить его улучшить, оптимизировать и т.д., но мне куда проще и думаю даже дешевле было просто купить 6 ядерный сервер с 24гб озу :) И все нормуль работает, нет никаких тормозов Погоня за "сферическим конём в вакууме" задача всегда не достижимая, всегда и везде будет что улучшить, но стоит ли?)) В итоге просто балансирую в своих проектах экономя своё время в первую очередь ибо оно конечно
-Микросервисы позволяют писать требовательные модули на компилируемых языках с оптимизациями - нет смысла оптимизировать время выполнения кода😂 Вроде год назад обсуждали на хабре эту тему. Истина же всегда где-то посередине. Иногда действительно кажется вводят абстракции ради абстракции.
В фреймворках надо замарачиватся над производительностью, и забивать на чистоту. И еще сейчас мобильные игры и приложения наверно на чистом коде пишут, и это приходится каждые пару лет обновнять железо. А для вэба, да, большая проблема это бд. Но тут можно маштабироватся, а вот клиент не маштабируешь
в оригинальном видео рапортовали о 10х увеличении перформанса на стороне приложения, в примере автора - 10%. Таким образом, в данном примере, после оптимизаций и БД и приложения получилось бы из 300мс -> 25мс, где база с 200 уменьшилась до 15, а приложенька со 100 до 10. Изменения получаются практически равнозначными За табличку влияния одних свойств на других - большой респект
В оригинальном видео Муратори было ускорение и в 17 раз, и в 24 раза. Ссылка на него есть в описании под видео. Но есть огромная разница между оптимизацией куска кода и ускорением работы всей системы. Во всей системе за бОльшую часть работающего кода вы даже не отвечаете - это фреймворк. В большинстве практических сценариев не получится в 17-24 раза укорить такой оптимизацией кода всю систему, а оптимизировав один её кусок как раз с 10мс работы этого куска получится 0.5мс, сам кусок оптимизировался в 20 раз, но в масштабах сервиса - почти незаметно.
@@t0digital абсолютно согласен. Но дело в том, что и на каждый код в базу ходит на каждый чих. С одним я согласен - оптимизировать надо ботлнеки, а вот их поиск - тема отдельная. Что для нас, что в индустрии в целом, performance engineering. Так что предлагаю оставить-таки за скоупом этот анализ и принимать оба кейса (что с бд, что с конкретным куском апп-кода) как уже найденную и подтвержденную неэффективность
"Вся отрасль веб разработки..." "Там циклы процессора никто не считает". Дак стойте. Веб-разработка же давно уже просочилась в натив: с этим замечательным electron и реакт нейтивом и иже с ними. Вот атом хейтили, vscode хейтят, и вот собственно "за что?", а за производительность Так вот, не надо всё это экстраполировать на всё. Вот вы правильно сказали, большая часть задержки в веб сервисах из-за ожиданий ввода-вывода. А вот тейк про "бутылочное горлышко" не всегда применимо и часто повторяете "такты процессора"-"такты процессора", но ведь в обсуждении не о тактах процессора шла речь (они-то лишь показатели измерения, а не причина). Вот пример приведённый виндертоном: вычисление площади фигур. Тут-то проблема не в тактах процессора, а в излишней загромождённости для реализации интерфейсов и в излишней модульности: ("чистый код") функции вычисления разбросаны по программе и в объектах лишние чтения виртуальной таблицы, что очень плохо сказывается на производительность с точки зрения кеша; ("быстрый" код) когда-как можно запихнуть все формулы в одну функцию (в памяти относительно недалеко будет весь код находиться, что с большей вероятностью попадёт в одну страницу кеша) и понадобится всего лишь пара переменных в куче, что даже количество обращений в сам кеш значительно уменьшит В итоге получаем не _[(подгрузка в кеш объекта), чтение vtable из кеша, прыжок, (подгрузка в кеш функции), вычисление площади]_ за каждый запрос (это если обращений в вычислении площади не сортированы по типам фигур), а _[(подгрузка в кеш переменной), условный прыжок, вычисление],_ и если эти параметры фигур находятся недалеко друг от друга (особенно если хранятся как массив), то и подгрузка в кеш переменной будет произходить очень редко (только по выходу из страницы следующая подгрузится). И вы наверное знаете что подгрузка из оперативной памяти в кеш в данном случае самая долгая операция, что в десятки раз замедляет тривиальное вычисление площади Так-что дробите по модулям в разумных размерах, без фанатизма на атомарные операции
> Так вот, не надо всё это экстраполировать на всё Мы этим и не занимаемся 17:55 Нужно ли дробить ради того, чтобы дробить? Нет, не нужно - нужно включать голову, это по дефолту. Нужно ли не использовать полиморфизм, потому что это в рамках всей системы даст замедление на 0.00005%? Нет, не нужно. Нужно ли писать код для человека, а не компьютера? Нужно. Нужно ли писать понятный читаемый код? Нужно. Нужно ли заниматься преждевременной оптимизацией (вот тут мы не будем использовать ООП, потому что это неэффективно)? Нет, не нужно.
Мне кажется как пользователя вас больше волнует производительность приложения, чем скорость разработки. Иначе закрытие нативных клиентов evernote и переход ими на веб версию электрон, вы бы рассматривали как плюс, а не причину по которой перестали быть их клиентом
Мои пять копеек: рекомендации по оптимизации, это понятно и наглядно - вот пример "плохого" кода, а вот "хорошего" - и в хорошем и в кеш все попадает и инструкции оптимальные используются и даже можно тест запустить и все будет очевидно. А вот со всякими СОЛИД, все гораздо сложнее. Ценность этих рекомендации понятна только на большом проекте и, очевидно, нельзя накидать небольшой пример, который демонстрирует большой проект (это и звучит абсурдно). Поэтому предъявлять претензии к примерам из книжек по СОЛИД изначально несуразно.
03:59 цитата: "Ну вот например вся отрасль ВЕБ-разработки она совершенно про другое, там циклы процессора ни кто не считает..." Вот поэтому на вашем супермощном компьютере, со 128-ю гигами памяти, с видеокартой 4090 вы будете ловить лаги пока смотрите это видео. Ну а дальше лапшу вам вешают на уши.
Для начала. Кто такой Кейси Муратори. Это разработчик игровых движков и т.д. Человек который очень хорошо разбирается в написании производительного кода, который понимает сколько будут стоить те, или иные архитектурные решения в ПО. Теперь по поводу его видео про чистый код. Его посыл там был совсем в другом. Он привел пример написанный согласно принципам солида, и код написанный в лоб. И он говорит, вот смотрите, код под солидом очень запутанный, логика размазана по куче мест. А вот код написанный без этих выкрутасов. И его во первых очень легко читать и понимать, и самое главное вносить в него изменения. Но и при этом вы получили гораздо, гораздо более производительный код. И уже после этого завязалась их длительная переписка на гитхабе. В целом идея Муратори в том, что не усложняйте без надобности. Не нужно бездумно следовать всяким там принципам. И что производительность вашего приложения, это не менее важная его составляющая чем остальное.
Все вы говорите о поддерживаемости, читаемости кода и т.п. Но это важно только для человека. Если ваш код не пишет человек - тогда чистый код не так важен(вобще насрать). p.s. пишу уже полтора месяца исключительно нейронкой. Главное - качественное покрытие тестами. Переписать заново то, что покрыто тестами занимает минимальное количество времени и усилий.
@@t0digital Совершенно не хотел вас задеть или обидеть чем-то. Просто для некоторых код, написанный на asm читать легче чем на современных высокоуровневых ЯП. Кто-то вообще знает только asm. Кстати нейронка очень неплохо пишет на asm.
@@t0digital Вы меня совсем не поняли. Мой посыл в том, что эпоха "пишем ручками" уходит. Приходит новая. Декларируем требования и проверяем результат. Мне было по-началу очень непривычно... И после многих лет следования принципам чистого кода я оказался не готов к такому подходу к работе. Я привык, что все о чем писал дядя Боб очень полезно и очень помогает. Но начав писать нейронкой я внезапно осознал что все это не важно. Важен лишь результат и скорость его достижения. В итоге ты пишешь тесты (той же нейронкой). Затем пишешь фичи (опять нейронкой). Потом просто запускаешь итеративный авто-дебаг. Нейронка сама ловит ошибки, сама вносит исправления в исходники. Ты лишь отслеживаешь показатели производительности и корректируешь промпт. Все. За день, два у тебя готовая, протестированная фича. Самое же важное - что обратную связь ты получаешь так же быстро. И тут Agile начинает играть совершенно другими красками. Выходит очень гибкий продукт. Готовый к любым изменениям/переделкам и прочее.
@@t0digital Я как пользователь ПК на это смотрю отрицательно. Мне буквально сказали что я купил новый процессор, не чтобы получить высокую производительность, а чтобы разработчикам было комфортнее. Думаю если клиентам тоже сказать что без солида они смогут сэкономить в 15 раз на железе, они тоже захотят чтобы разработчики от него отказались. Тем более что доказать эффективность солида сложно, а вот его влияние на понижение произдводительности - легко.
@@92Darkmind оч громкие, неподкрепленные ничем заявления, притягивающие за уши все что можно и нельзя. Муратори говорил о чистом коде, а не о солид, начнём с этого. Чистый код не про солид, в чистом коде нет даже упоминания солид и всех его прицинпов
Гораздо чаще эти "оптимизаторы" удивляются, почему зарплату им не повышают) Ибо они вместо бизнес-фич занимались преждевременной оптимизацией куска кода, который вообще не работает в проде 😏
@@СергейРодин-ю3ъ Дональд Кнут еще тыщу лет назад сказал, что преждевременная оптимизация зло. И что всего 4% кода выполняются более 50% времени работы системы, эти 4% являются целью потенциальной оптимизации в уже работающем приложении, а не остальные 96%
@@СергейРодин-ю3ъкак-то рефакторили проект, в котором до этого внедрялись бизнес фичи без оптимизаций. Вкладка в браузере выжирала несколько гигов, нарушение целостности данных, сабмиты форм могли висеть с десяток секунд. Зато "спринты" успешные были😂
Эх, Ваши бы слова, да одному из моих заказчиков в уши. Требовал high perfomace там где это абсолютно не нужно, и вечно пытался пропихнуть свой алгоритм решения, который как раз и есть самый тормознутый участок.
В принципе странно лезть в темы оптимизации с точки зрения питона. Если используется питон или, например, жаба, то энивей лучше клинкодить, чем упарываться в производительность. А вот если делаешь какой-нибудь анриал энджин на плюсах, то лучше уж нечитаемые сорцы, чем вот это вот все.
В недрах ms сделали кеш с поддержкой redis протокола. Анонсировали, что написан на шарпах. Выкатили его в опенсорс. Работает ОЧЕНЬ быстро. Но исходники... практически один сплошной unsafe. Развитие и поддержка такого кода очень и очень дорогая.
@@andrewbondaryuk так могут себе позволить. Они создали конкурентное преимущество ценой дополнительных вложений в разработку и поддержку, бизнес примерно так обычно и работает.
Я в своем познании настолько преисполнился, что я как будто бы уже сто триллионов миллиардов лет проживаю на триллионах и триллионах таких же планет, как эта Земля, мне этот мир абсолютно понятен, и я здесь ищу только одного - покоя, умиротворения и вот этой гармонии, от слияния с бесконечно вечным, от созерцания великого фрактального подобия и от вот этого замечательного всеединства существа, бесконечно вечного, куда ни посмотри, хоть вглубь - бесконечно малое, хоть ввысь - бесконечное большое, понимаешь? А ты мне опять со своим вот этим, иди суетись дальше, это твоё распределение, это твой путь и твой горизонт познания и ощущения твоей природы, он несоизмеримо мелок по сравнению с моим, понимаешь?
все программисты разбились на два лагеря: первые не видят проблем в написании красивого кода, и считают, что быстро - это не всегда нужно. это фронтендеры. вторые считают, что красивый код - это круто, но в реальном мире неприменимо, поэтому хотелось бы, но ответственность не позволяет. это разработчики серверов, баз данных, low latency систем и другие люди, бьющиеся за такты процессоров. и первые, и вторые упускают из вида специфику программного обеспечения друг друга. фронтендеры действительно большую часть времени ждут ответ от серверов, от других процессов, от жесткого диска в конце концов. поэтому им производительность конкретно их приложений не так важна. а бэкендеры наоборот не понимают, как можно писать красивый, но медленный код, потому что у них время задержки в 1 секунду означает, что начнет расти очередь запросов, поэтому сервер может начать отвечать 500. поэтому тут спор несколько странный и зависит скорее от компетенций специалистов, принимающих решения о том или ином архитектурном решении
Оптимизация под процессоры не так уж страшна. На таких языках, как Ада и Delphi, можно использовать пользовательские перечисления, и эти перечисления использовать как индекс массива. В более примитивных языках программирования, где массивы только цифрами нумеруются, там да, там то же самое выглядит как низкоуровневые заморочки
@@t0digital Я продолжал начатое другим разработчиком переписывание с PHP на C++, именно из-за проблем с производительностью. Стало получше, но не настолько, как хотелось. Упёрлись в то, что у прошлого разработчика был юникс головного мозга, и он сервер ортодоксально сделал по архитектуре accept-fork, а через fork-нутые процессы сложно, почти невозможно, разделять подключения к БД, и на каждое подключение к веб было нужно новое свежее подключение к БД, которое долгое, и это всё отравляло. А вот PHP-то подключения разделял. Переделать C++ сервер с процессов на потоки было сложно, там подразумевалось, что каждый процесс живёт в отдельной виртуальной памяти, модифицирует всё что ни попадя. Новый адский сервер я сразу делал как надо, многопоточный, а не многопроцессный. На текущей работе задолбались с Питоном. Коллеги новую версию одного из серверов написали на Delphi. Ещё один новый, в смысле, не имеющий аналогов, сервер уже на Delphi изначально делал. Постоянно что-то кипит, заменяется, есть окно возможностей улучшить стек
@@t0digital Затянул с ответом ruclips.net/video/YST24EiPGnc/видео.html Но это не единственный доклад, в том числе есть Ceph анатомия катастрофы, там так же критикуются подходы "не в лоб" для задач системного программирования. Принципы типа "функция не должна быть больше одного экрана для читаемости" не работают, когда задача писать не расширяемый, а производительный код.
Вот интересно, в Mercedes или BMW каждую машину делают сначала абы как, лишь бы дизайн красивый был, и только в конце начинают перепроектировать двигатели и ходовые, сбрасывая по 50-60% лишнего веса и увеличивая мощность в десятки раз? Или они все же, имея опыт, заранее грамотно проектируют новые узлы так, чтобы не пришлось "оптимизировать" когда конвейер уже запущен? По хорошему оптимизация начинается на этапе проектирования.
я могу подождать 10-15 секунд пока у меня прогрузится пчта, но каждый день я надеюсь, что когда-нибудь мне придется ждать меньше 5. Как было лет 10 назад.
Он в целом о том и говорит, основной его аргумент в том, что люди часто используют SOLID потому что "так надо", как еслиб это была какая то догма. Т.е. люди сначала делают задел на будущее (а пихну как я сюда эту абстракцию, вдруг завтра понадобится), а потом начинают только писать что-то что делает реальную работу. И Маратори и говорит - что код должен быть понятным, в это не обязательно SOLID. Есть его интервью короткое: ruclips.net/video/DsAclZbP_Us/видео.html Там же ссылка на полное, интересно тоже посмотреть. Не сотвори себе кумира, как говорится :)
@@t0digital Я понимаю, что это не одно и то же, можете заменить в моем комменте SOLID на "некую догму". И он говорит о Clean Code и SOLID, например здесь ruclips.net/video/7YpFGkG-u1w/видео.html
в оригинальном видосе, который вызвал весь спор, ruclips.net/video/tD5NrevFtbU/видео.html, он называет Clean code какие-то рандомно выписанные принципы из всего массива того, что Мартин именует Clean Code
может быть это новость ... но "программа работает" - подразумевает что работает на ПРАВИЛЬНО. если программа выдает неверный результат - она не работает ...
Коллега какое-то время меня упрекал за то, что я разделяю методы на более маленькие, говорил, что я убиваю так производительность, потому что он читал, что вызов методы сжирает целый ТАКТ! Трагедия великая, убедить я коллегу смог в обратном далеко не сразу, пришлось его заставить прочитать книжку, только после этого он перестал меня в подобном упрекать. Книга не Мартина, две книжки от O'REILLY, Head First Паттерны проектирования и Head First Java для чайников. Иногда он пишет мне с различными вопросами по паттернам, а когда я ему привожу некий пример улучшения слышу: "Я если честно книге больше верю". Интересно, что будет, если он прочтёт книги Мартина, наверное вообще мне писать перестанет :))
@electrikkk Вероятно, не знает. Мы с ним работаем с Java и тут о работе компилятора почти ничего не знаем, так как используем готовые системы для сборки. Хотя очевидно разобраться стоит, спасибо за мыслю!
Ваш коллега был не совсем прав. )) При вызове простой функции оверхед может составлять 10-20 тактов. Скорее всего они имел в виду вызовы виртуальных функций, которые дороже обычных на 1-2 такта, при условии попадания в кэш. Чем больше у функции аргументов, тем больше времени уходит на вызов. Поэтому на с++ небольшие функции часто инлайнят.
Да там тесты у Муратори такие, что он очень простую функцию обернул в два класса и говорит, что в 15 раз перфоманс упал. Вот если бы он попробовал 2 больших проекта написать в двух разных стилях, он бы тогда понял, что влияние абстракций будет уже не таким значительным. Я вангую, что там максимум 50% можно наскрести с оверхеда, но никак не 1500%. Наверное, у господина Муратори много свободного времени, пусть напишет более приближенный к реальной жизни бенчмарк, тогда и поговорим)
Странная постановка вопроса. Если ты пишешь то, что никто и никогда не будет переписывать, то эффективность - единственная цель. Если ты пишешь код, который будут читать и развивать, то читаемость - первостепенная задача, а эффективность - вторая. Понятное дело, что работоспособность и отказоустойчивость кода - это более значемые его параметры.
В ИТ нет ничего более постоянного, чем изменения. Крайне редко что-то не будет дорабатываться и изменяться, даже если в момент написания кода кажется иначе. И, как верно пишет Макконнелл, писать хорошо и писать плохо - примерно идентично по трудозатратам. Под писать хорошо подразумевается писать расширяемый, поддерживаемый, читаемый, тестируемый, модульный код.
Однозначно согласен с вами, Алексей, проблемы нужно искать не в чистом декомпозированном коде, а в непроизводительных внешних сервисах. А упоминания термина bottleneck мне очень понравилось!
@@fatoldhikki4837 Да, есть! Криворукие программисты. Да и не забывайте, что вы пишете не на чистом (истинном) машинном коде, а на приятненькой обёртке, которая сделана для нас, чтобы наши программистские ручонки не дрожали, вводя инструкции, или того хуже, байты! Любой язык программирования вносит свою лепту в производительность. И если вы допускаете это, то допускать можно. Хотя нет, нужно! Нужно допускать другие подходы к программированию, облегчающие написание, как, например, подходы, описанные в книжках дядюшкой Бобом.
Ну вот давайте честно. В продакшене, в бизнесе, всем насрать на скорость ответа. Важно: Программисту - быстрее сделать. Бизнесу - быстрее получить и заработать. Пользователь - разницы не почувствует, если уж совсем трешкода там нет. Итог. Если речь не о секундах, а о миллисекундах, пользователю все равно.
Тем временем мой курс «Хардкорная веб-разработка» продолжается - course.to.digital
Иногда удивляюсь что такие как вы "программисты"?! и не поняли суть претензий Кейси?! суть в том что стандарты которые устоялись - дебильные!
Сам удивлён. Тупые программисты следуют тупым правилам в тупых корпорациях, зарабатывающих тупо много денег и пилящих тупо огромные продукты. Хорошо, что есть нетупой Муратори, который всем расскажет, что все тупые. Спасибо ему. Как мы без него жили.
@@Macbaren-s2o А ему ответить нечего по факту. Я выше описал про убытки хостеров и корпораций от тупого псевдо-чистого кода. Автор после этогон что-то аргументировал? увы... ибо я описал по факту как обстоят дела.
Идущий к Data Lake
тогда уж к Data River
@@4t0m1c3 Data Lake это не просто набор слов:) en.wikipedia.org/wiki/Data_lake
@@t0digital да я в курсе просто рофл
Лишь бы не к Data Swamp
идущий к реке увлекся it
Только что собирался это написать, ахххах
Мне этот код абсолютно понятен….
Я в своем познании настолько преисполнился
Я в коде ищу только одного: умиротворения и вот этой гармонии от слияния с бесконечно-вечным. На дворе благодать и мне этот Мураками абсолютно понятен, но ему не понять
Книги Мартина хороши, но если не пропускать их через свой критический анализ - то можно заболеть "чистым кодом головного мозга".
Мартин не пишет профессионально код уже лет 20, и сколько бы он не пытался говорить нам, что код 40 лет назад и код сейчас ничуть не поменялся.
Но любой разраб в текущей энтерпрайз разработке скажет, что это не так... Поэтому и воспринимать его советы без критического анализа - просто нельзя.
Интересно, а пользовался бы Алексей nvim если бы он не был такой отзывчивый? А ведь это всего лишь текстовый редактор, для него уж точно не важна скорость работы.
Почему многие так сейчас становятся недовольны vscode, его отзывчивостью?
Почему всех бесит когда тормозит чат приложение? Почему всех бесит когда тормозит браузер? Почему всех бесит когда тормозит камера на его телефоне? Кто бы что не говорил - отзывчивость/скорость работы - важна. Но важна ровно настолько, чтобы она не бесила пользователей :)
Я ж говорю в видео - есть РАЗНЫЙ софт. Для веб-сервисов такты процессора считать не надо, это всё сожрётся медленным интернетом как минимум, и ускорение работы веб-сайта это не про замену полиморфизма if'ами, это по влиянию на результат в реальной системе там на каком-то трехсотом месте будет, то есть это надо делать, выполнив 300 других направлений - внедрение кеша на разных уровнях, разбивка сервисов на более мелкие иногда, оптимизации фронтенда, ленивая загрузка, SSR и тд и тп.
@@fatoldhikki4837 чистый код недостижим, но это не значит, что на эти принципы можно забить. Успехов вам развивать в погоне за тактами процессора приложение, нарушающее LSP, то есть содержащее логические ошибки. Нарушающее OCP, когда в одном и том же коде начинают копиться конфликты. Нарушающее SRP, с GOD-объектами. Нарушающее DIP, когда, чтобы изменить приложение надо менять пол системы, плодя баги. Нарушающее принципы именования (привет I, j, av, bz нейминг). Нарушающее модульность - весь код одна простыня. Ус-пе-хов. И еще никогда не пишите ни на чем кроме ASM, потому что теряете такты, любая абстракция как правило не zero-cost. Лучше всего писать поверх железа без готовой ОС, разработав свою ОС под конкретную архитектуру CPU, все будет очень эффективно и заточено под твою задачу.
@@t0digital спор глухого со слепым) та же вакханалия, которая творится во фронт разработке с бандлами превышающими все лимиты - это разве не про эффективность и верхнеуровневое программирование? тут разговор не про ассемблер и не про то, что каждой задаче свой инструмент, а про адекватность в подходах. что и клинкодеры и производительности-дрочеры могут сильно упороться в какую то из крайностей и что из этого ничего хорошего не выходит
@@_test_test крайности - плохо. Концовка видео об этом.
@@t0digital "крайности - плохо. Концовка видео об этом" - но при этом вы сами же бросаетесь в крайности. Когда говорят об архитектуре кода переводите стрелки на названия переменных... Говорите о каком то куске кода, когда все ваше приложение покрыто тоннами абстракций, избавившись от которых вы сможете его ускорить. Приплетаете зачем то ASM, когда можете написать и на выбранном языке в десятки раз быстрее. Выложили кусочек кода в тг, дабы доказать что те кто думает о производительности, называют переменные буквами....
солид - это парень, который сухпайки в лесу пробует?
Именно, он тестировщик
Чел харош
Который Снейк
ruclips.net/video/Mx76RGHbfms/видео.html
Если так ответить на собеседовании то оффер обеспечен)
Всё зависит от того чем занимаешься - если ты пишешь код базы данных, то к тебе совсем другие требования будут и если ты оптимизируешь только бутылочные горлышки, то получишь равномерно медленный код, который больше негде оптимизировать. Поэтому есть случаи когда производительность должна быть заложена в архитектуру.
Или например сервис высоконагруженный пишешь - там уже не до питона, сразу надо нормальный язык использовать и думать о производительности всегда.
Алексей, спасибо! Когда слушал, как раз, хотел написать про золотую середину.
Формат видоса "что-то обкашлять" отличный! Подача, как всегда, на высоте.
Мне этот спор абсолютно понятен...На мой взгляд можно сократить до фразы есть задачи упирающиеся в IO, а есть в CPU, ещё в gpu, тензорные процы и подобное. Однако, как по мне, панч Муратори в том что код, который написан без принципов clean code внезапно более производителен с точки зрения написания и чтения кода, но тут, ИМХО, вред слепого следования паттернам, головой надо думать)
Головой надо думать, да:) 17:39 и дальше об этом.
Но если не следовать принципам clean code, значит можно именовать переменные j, i, a, d, можно писать функции на 5000 строк кода, делать GOD-объекты вместо грамотной декомпозиции, жестко простраивать зависимости от реализаций вместо DIP и тд. Быстрее ли написать такой говнокод? Да, конечно, но затем непременно будем иметь проблемы с его поддержкой, если проект долгоживущий и развивающийся.
Головой думать - вообще полезное занятие
Нет, программист - тот кто мериться тактами ЦПУ и квантами кликов на клаве. (с) IBM
@@t0digitalну это ведь подмена понятий с твоей стороны. Если не клинкод, значит обязательно функции на 5к строк и плохой нейминг.
Кейси привёл отличный пример, когда уменьшается количество абстракций, при этом код всё ещё понятен.
Будто ты сам никогда не дебажил какой-то код, где у тебя 33 абстракции и ты go to definition всё дальше и дальше вглубь воспалëнного сознания разработчика
Ну где подмена понятий-то? Clean code это далеко не только solid. Вы читали книгу саму? Там дай бог процентов 10 про solid. Не следовать конкретным 5 принципам (SOLID) из общего набора, скажем, 500 clean code принципов это значит не следовать clean code, но если не следовать другим 5 принципам из clean code, то это уже плохой пример неследования clean code. Чойта)?
Чувак ты не уловил фабулы их дискуссии. Там не про такты процессора, а про мусор из абстракций усложняющий исполнение кода и понимание кода
Я смотрел оригинал Муратори, ссылка есть в описании. Он выдернул 5 постулатов клин кода (из сотен постулатов клин кода), назвал эти 5 постулатов клин кодом (а где остальные сотни?) и показал, что они ухудшают производительность и потому клин код говно. Так может остальные сотни постулатов увеличат производительность?
Клин код как раз про понимаемость и расширяемость кода. Да, местами где-то производительность ниже, но не в 24 раза в рамках всей системы, потому что на if/else без абстракций всю систему не напишешь. Вся индустрия ушла от asm в более высокоуровневые языки именно поэтому. Управление сложностью, в том числе через грамотное использование абстракций. Муратори хайпожор.
@@t0digital Вы действительно не в теме. Муратори лишь указал на неэффективность клин кода в некоторых сферах разработки например геймедев, где циклы процессора действительно важны, а освобожденные ресурсы можно пустить на прожорливый рейтрейсинг. Причем тут asm? Если что Муратори это практикующий программист, не распространяющий бесполезную философию вроде Мартина и Макконела, у него есть канал Molly Rocket, где он пишет игру + движок загляните - это интересно.
@@t0digital Муратори... показал, что СС, во-первых, не имеет никакой доказательной базы, "поддерживаемость", "читаемость" -- личное мнение каждого отдельно взятого гуманитария, верующего в Мартина, во-вторых, показал, как без СС код становится более "читаем" и всё прочее.
Таким образом, заключает Муратори, СС -- культ карго, в который верят исключительно гуманитарии, нет ни единого основания принимать его всегда и везде.
рекомендую всё-таки читать первоисточники, прежде чем позориться на аудиторию из профессионалов.
@@КириллКирилловичутверждения Муратори про повышение читаемости при кодинге в его стиле точно так бездоказательны. Они строятся буквально ни на чем, поэтому предмет спора пуст. Все же думается, что большинству людей проще понимать абстракции, чем компиляторные команды
Куплинов, спасибо большое за обзор темы!
19:10 Так проблема в том, что не известно для каких задач какие инструменты подходят и более эффективны. Кто-то например считает, что на Python нельзя писать ПО с повышенным требованием к правильности работы, а нужно использовать Ada или Rust.
Кейси как раз и заявил, что надёжно и понятно можно писать не используя паттерны клинкода и это ещё будет быстро.
Насчет тактов процессора. Если взять на чистом си написать небольшую программу, откомпилировать. А затем дизасемблировать и посмотреть что сделал компилятор в ходе оптимизации. То можно очнь сильно удивиться. А если посмотреть на ключи компилятора, то можно увидеть ключ с разными уровнями оптимизации. И для того чтобы считать такты процессора нужно, как минимум, знать что и как компилятор оптимизирует.
Почему многие так зацепились за "такты"? Помимо тактов есть еще немало нюансов, которые влияют на производительность. Например кэш - полный размер, размер кэш-линий, алгоритм работы. Отсюда ростут ноги оптимизации структур, циклов, небольших функций. Это помогает оценить "стоимость" локальных переходов и вызовов/возвратов. Так, например, в коде с короткими функциями переходы по if/switch не будут вываливаться из кэша и уод будет быстрым. Но если вместо этого вы превратите код в классы с виртуальными функциями, то процессору придется метаться кабанчиком по указателю на VTable, загружать по смещению адрес функции, заливать в стек состояние части регистров и аргументы функции, делать вызов, а потом возвращать все обратно взад. В этом случае увеличивается не только количество команд (тактов), но и количество cache miss-ов, которые приводят к куда бОльшим простоям CPU.
Можно сказать, что это актуально только на "низкоуровневых" языках типа с/с++, но увы. Даже на с# базовые знания архитектуры помогают ускорить код, иногда даже в разы. В качестве примера можно взять Unity -- они добавляют все больше средств для эффективной работы с данными из новых версий c# и местами переписывают структуры (на C#, не на С++), чем заметно ускоряют движок даже при выполнении на VM
И, кстати, такты процессора уже давно почти никто не считает, так как это очень геморное и неблагодарное занятие из-за длинных конвейеров. Одна и та же команда в разных фазах луны может отработать быстрее или медленнее. Так что нужно рассматривать код и данные в целом.
сейчас вспомнил какие неоптимизированные игры пошли, там важен каждый процент
) это не только из-за чистого кода, это из-за кучи аспектов архитектуры процессора ядра и тд, из-за simd операций, из-за миллионов способов отразить треугольник, из-за 505 способов обнаружить столкновение кубиков друг с другом и тд
@@владимиркарпов-т4ъ Тодд Говард: Если у вас тормозит Starfield, то давно пора обновить ПК!
Вспомнилось:
Я печатаю со скоростью 1000 знаков в минуту. Такая фигня получается!
😂 все так
0:03 «критика чистого кода» как «Критика чистого разума» И. Канта.
Желательно, чтобы любой комментирующий в ЭТОЙ теме указывал в каком проекте он работает:
1) размер команды
2) количество внешних интеграций
3) количество строк кода ( да-да-да! )
4) количество бизнес-сущностей в системе
5) срок жизни проекта
6) сколько работает в проекте
7) сколько работает в отрасли
Вот тогда можно отделить кровавый ынтырпрайз от плевел и узнать мнение разработчиков участвующих в РЕАЛЬНО больших проектах.
Мартин, если что, столуется в MS у которого опыта в кровавых ынтырпрайзах явно достаточно, чтобы продвигать его идеи ;)
p.s. это как спор perl vs python: первый ещё называют write only ЯП
Спасибо за разбор!
Крайности рассматриваем. А хотелось бы разумного, более взвешенного обзора. Да и без примеров, по дороге с облаками про код говорить - простое увеличение энтропии вселенной, которая и без того велика.
Нет, крайности не рассматриваем. Более того, в видео явно говорится о том, что крайности и догматизм это плохо. Касательно примеров - если вы не можете говорить о разработке без примеров кода, то пока что вам рановато смотреть такие видео.
По факту всё разложил! Полностью согласен с автором видео. Слишком много шума из-за этого не очень грамотного и всё максимизирующего Муратори. На самом деле шумность комьюнити по этому поводу лишь подтверждает общую деградацию программистов в среднем по палате.
Рост производительности процессоров пропорционален (в каком-то приближении) снижению производительности программных компонентов. У этого огромное множество причин. Потребитель платит за это своими деньгами покупая более дорогие комплектующие (которые на этом фоне еще и растут в цене). Всех все устраивает, когда все так работают. Можно представить себе ситуацию, когда на рынке появятся альтернативы, которые в какой-то мере решают эти проблемы, тогда рынок порешает и потребить проголосует своим кошельком. Мне кажется мы приближаемся к точке, где такой сценарий может сработать. Программист (какой-бы крутой он не был) слабо представляет детали реализации программных компонентов, которыми пользуется, жизни не хватит разобраться во всем в деталях. Он может даже не представлять на какие аспекты его работы может повлиять повышение производительности различных систем. Лично я хотел бы увидеть смещение парадигмы в сторону производительности, та и мне кажется сейчас это уже происходит.
Это всё сферические рассуждения про производительность базы данных vs кода на прикладном языке. Но я вот в своей практике неоднократно сталкивался с ситуациями, когда, например, БД отвечает за 100 мс, а вот руби после этого обрабатывает её ответ 2-3 секунды. Хотя руби выступает не более чем в роли какого-то шаблонизатора (это вот почти как в примере Кейси со смайликом). И даже с джавой (которая быстрее руби кратно сама по себе) я видел как достигли примерно аналогичной производительности наворотив микросервисов вместо прямых вызовов функций.
Финал обоих случаев - код, который писали пару лет (и на который потратили уйму ресурсов), просто тупо снесли нафиг и заменили на вменяемый код с процедурами и циклами.
Я такого на своей практике не видел ни разу, настолько непрофессионального кода. И чтобы проблема его производительности была именно в излишних абстракциях - ну оч сомневаюсь. Говнокод, когда человек совсем не умеет кодить, это да, это может быть.
@@t0digital тонкость в том, что "профессионализм" - очень относительная вещь.
Я понимаю, что вы не видели ни разу такого кода. Иначе вы бы не сняли такого видео. Но этот код буквально везде вокруг нас. Причём с точки зрения Мартина - это именно что высокопрофессиональный код. С точки зрения Муратори (да и моей тоже) - говнокод. И тот код, который описывал я - был написан именно по канонам SOLID. Буквально single responsibility principle домноженный на микросервисную архитектуру - это полная катастрофа.
Собственно в исходном обсуждении (откуда вся эта тема и пошла) Муратори именно на примере веб-кода показывает, что следование принципам, проповедуемым Мартином приводит к тотальной просадке перформанса, которую не перекрыть никакой субъективной "читабельностью".
Тем более что с моей точки зрения когда ты наворачиваешь тысячи функций вместо десятков ни о какой читабельности даже и речи быть не может. Это и есть говнокод в чистом виде! То есть просажены и читабельность и перформанс, но зато все смотрят друг на друга, улыбаются, и миллионы программистов в мучениях порождают ещё один говнопродукт, который будет потом выброшен в помойку. Но всем плевать пока бабки в отрасль текут рекой.
1. Я 20 лет в айти. Не видел такого кода, но он вокруг нас. Ну окей.
2. Вы уверены, что понимаете, что такое чистый код Мартина? Что такое чистый код Мартина, можете сказать? Вы читали книгу или судите по Муратори, который взял 5 пунктов, почему-то назвав их чистым кодом?
3. Нет, Муратори не показывает на примере веб-кода. Какой там веб-код, там пример с фигурами, при чём тут веб? Веб это:
а) чаще всего не C/C++
б) фреймворк, чей код в бОльшей степени выполняется в рантайме, а не ваш код, на 1 строку вашего кода там могут сотни строк фреймворка выполняться, который вы не контролируете вообще
в) это коммуникация с СУБД
г) если это микросервисы, то это коммуникация с внешними сервисами. В любом случае это много IO.
Ничего этого нет у Муратори. Его пример вообще не про веб.
Читабельность не субъективна, читабельность можно измерить методом экспертной оценки - вполне себе объективно. Набирается экспертная группа и она сравнивает разные варианты кода и говорит, что вот это более читаемо, а вот это менее читаемо. Хотя полиморфизм vs if/else это в большей степени про расширяемость кода, а не читаемость.
> Тем более что с моей точки зрения когда ты наворачиваешь тысячи функций вместо десятков ни о какой читабельности даже и речи быть не может. Это и есть говнокод в чистом виде!
Простите, вы тотально неправы. Главная задача функций в улучшении читаемости кода. Вместо того, чтобы читать реализацию в 15 строк кода и думать, какую задачу эти 15 строк кода решают, вы читаете вызов понятно названной функции и не тратите время на изучение реализации, если вам это не нужно в текущий момент. Главная задача функций не в DRY, а в увеличении читаемости кода. Если функция будет вызвана всего в одном месте это не повод не создавать функцию.
Я не буду дальше продолжать этот спор. Вы всё равно не прислушаетесь (почитайте про эффект Даннинга-Крюгера), а я просто зачем-то потеряю время. Успехов.
1. Я в айти 32 года (с 1992-го). И я начинал с написания многопоточного (по настоящему, параллельно исполняемому на разных процессорах в рамках одной вычислительной системы) кода на ассемблере. Надеюсь этого достаточно и к фалометрии мы более не вернёмся.
2. Разумеется я читал эту книгу. И не только Clean code, но также Perfect code и ещё много других подобного толка. И когда я читал некоторые из них, в определённых местах я смеялся в голос и дискутировал по поводу прочитанного с коллегами. Потому что прочитанное было наивно до смешного. Я прекрасно понимал что в реальных промышленных системах применение некоторых из этих правил очевидным образом приведёт к провалу проекта. Впрочем не все были со мной согласны. В конце концов кто-то же написал (точнее при ком-то был написан) тот код, который потом пришлось снести. ;-)
3. Это видео - только начало темы. Далее случилась публичная дискуссия между Кейси и Бобом тут: github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md , где Кейси в какой-то момент замечает, что "...while trying to edit this very file on github that if I type a paragraph that is too many lines long, it starts to get very slow and it's difficult to type!" (можно поискать по тексту и почитать что было далее).
Github - это же веб-код? По-моему веб. По крайней мере если это не веб, то я не знаю что такое веб.
По поводу функции в 15 строк кода vs сколько-то меньше (я так полагаю) это тоже очень старая (для меня) дискуссия. Главная ошибка, которую сторонники вашей позиции совершают, заключается в том, что вы не учитываете, что разбивая эту функцию в 15 строк кода на 5 или сколько-то больше функций вы добавите ещё 10 строк описаний самих функций. А если вы будете разбивать это всё на классы (как рекомендует Боб) - то ещё больше. 30-50-... строк сверху. И это всё НАДО будет прочитать. И не дай бог вам потом разнести эти классы по разным компонентам (суть "микросервисная архитектура")!
Но чёрт бы с количество строк. Главная проблема в том, что вы из одной сущности (последовательно исполняемый кусок кода) лепите 5. А человек не в состоянии удерживать в голове слишком много таких сущностей. Поэтому как и показал Кейси в своём исходном видео вы в какой-то момент не заметите что вы пишете один и тот же код, причём код низкоэффективный и никому уже (включая вас!) непонятный.
Я видел много таких проектов (легаси, ага), которые понаписавшие их бросают, потому что не в состоянии ни исправить их ни поддерживать и бегут как "профессионалы с опытом" строчить ещё один такой же кривущий проект с нуля. Это настоящая беда современной айти-индустрии, увы.
Это потому что SOLID и микросервисы головного мозга. Надо всегда с умом подходить к задаче и не наворачивать лишних сущностей где в них нет необходимости.
Сегодня смотрел видео Виндертона, обдумывал что да как.
Пришел к выводу, что clean code сейчас не про эффективность, а про то, чтобы все программисты открывая код, писали в одном стиле, скажем так.
И не было проблем в дальнейшем изменении или обновлении кода
не совсем. клинкод не защитит от проблем. да и в одном стиле писать всем это недостижимая мечта. а вот что сделает клинкод так это сократит количество человекочасов на освоение и поддержку кодбазы. если простыми словами то клинкод это меньшее зло, и индустрия с удовольствием его приняла чтобы банально срезать косты. точно так же когда-то придумали высокоуровневые языки чтобы было проще. и точно так же придумали низкоуровневые языки чтобы не писать ассемлер. и точно так же ассемблер придумали чтобы не писать код на целой коробке перфокарт которые весят 5 кило.
Чистый код - это инструмент инженера (ножичек по ролику) для управления сложностью решаемых кодом проблем. Вокруг него выстроены целые комбайны (кодогенераторы, IDE, верификаторы), работая с которыми, если не придерживаться стиля СОЛИД, получим чудо-чудное монолитно-падучее ... с которым уже никакие такты и оптимизации не справлялись, ибо падало, и очень оптимально, и нередко тянула за собой и базы, что выливалось в человеко-часы любви и дзена.
это вывод виндертона, а твой вывод где?
Чтобы программисты были легко взаимозаменяемы, можно было их увольнять/нанимать повышать конкуренцию на рынке труда и снижать им зарплату. По идее, программисты в своих корыстных интересах должны саботировать клинкод, если хотят себе высоких зарплат.
ну кстати, иногда понимание внутренней реализации python, позволяет оптимизировать код не прибегая к переписыванию на rust или c. tuple вместо list когда не нужно изменять коллекцию, слоты в дата-классах чтобы немного память по экономить. в общем просто нужно хорошо знать свой инструмент.
конечно
@@redneck_prm5429ну по поводу коллекций, на мой взгляд тут просто здравый смысл. А про слоты... если в какой-то класс их руками класть, выглядит скажем так себе. а в dataclass просто один аргумент в декораторе указать. красиво, да и лишнюю динамику уберёт. мы всё-таки как правило в большинстве случаев не добавляем в объект поля динамически, а работаем с фиксированным их количеством.
Использовать list без append - это как и зачем? Не нужны добавления данных в структуру - юзай tuple, это понятно, но у tuple и нет append. А чем плох break с точки зрения производительности?
@@redneck_prm5429 охренеть, а как же добавлять элементы в массив и как выйти из цикла тогда? Бред какой-то.
Справедливости ради, ориентироваться на питон и типовые веб-серверы в данном споре немного странно. Страннее было бы только bash-скрипты приводить в пример.
Насколько я понял, они всё-таки спорили не про то, что clean code не имеет области применения, а про то, что область применения clean code ограничена, при этом в книгах дяди Боба эти ограничения не упомянуты.
И про то, что производительность и читаемость кода не всегда противопоставляются друг другу, а производительный код может быть читабельным и сопровождабельным, но при этом он не будет соответствовать clean code'у. А вот код, соответствующий clean code'у, производительным быть не может.
В общем в видео всё сказано правильно, только к обсуждаемому спору прямого отношения не имеет.
Да, Python всего лишь (по ряду рейтингов, TIOBE, например) самый популярный язык программирования в мире на сегодня, ориентироваться на него действительно странно.
@@t0digital В данном споре да. Проблема очевидно не в популярности, а в том, что если речь зашла о производительности, то питон тут не показателен, просто потому что питон сам по себе медленный.
Есть, конечно, ещё числодробилки, но и в них всё, что пишется на питоне к производительности не критично.
В общем опять вроде всё правда, но к теме никак не относится.
Python медленный, но тем не менее на нём пишут много кода, судя по рейтингу - так почему не говорить о его производительности, чистом коде на питоне и тд? Не понял твою мысль.
@@t0digital Потому что на питоне пишут код, для которого производительность как правило не критична, или не очень значима.
Рассматривать спор о производительности подхода к программированию, используя ориентир, для которого производительность почти не важна, не имеет смысла.
Этим можно только доказать, что производительность кода не всегда важна, но кто вообще с этим спорил?
Изначальный спор - клин код говно, потому что он в 15 раз медленнее. Я оспариваю это заявление. Применим ли клин код к питону? Конечно. Если верить этому утверждению, пайтон разрабы должны перестать писать клин код, потому что он в 15 раз медленнее. Но а) это не так б) клин код не замедляет производительность всегда, в общем случае, по умолчанию, потому что клин код это гораздо больше чем SOLID, названа переменная e (не клин код) или employee_index (клин код) - разницы в производительности никакой не будет. Однако i у тебя ни один вменяемый код-ревьюер не пропустит на ревью, что на питоне, что на чем угодно, потому что это ВАЖНО!
Придумать нелепые примеры и победить их - замечательно) манипуляция называется "соломенное чучело". А по существу вопроса - речь в видео Муратори идет об увеличении производительности в десятки раз, а не на 10%.
В десятки раз можно оптимизировать производительность куска кода, заменив где-то локально один кусок кода на другой. Вот какой-то кусок из 300мс сервиса работает 10мс и вы его сжали до 0.05мс, увеличив производительность в 200 раз. Однако общее время сервиса уменьшилось с 300 до 290 мм всего, на 3%, а не в десятки раз.
Чтобы изменить в десятки раз производительность всей большой системы - нужны куда более радикальные подходы, которые уже не называют оптимизацией.
@@t0digital помнится, как один из модеров уменьшил время загрузки GTA 5 в среднем с 60 с до 10. 1 строкой кода. с точки зрения часовой игровой сессии - ускорение где то около процента, но оказалось что это очень сильно заметно.
@@t0digital У вас Подмена понятий, манипуляция. Даже ваш пример,эккзотический будет на физическом ядре хостера ,оторый ДЕЛИТ своё процессорное времяъ\циклы на работу с другими хостерами! Что вы юлите?!??
@@necroticuss6780 Современный серьезный веб-проект с мало-мальской нагрузкой не делит ядро CPU между кодом приложения и хранилищем - хранилище вынесено на отдельный сервер или кластер серверов с репликами. И понизь свой тон, не знаешь ни хера и споришь до усёру.
@@necroticuss6780 прододжишь в том же русле - бан.
картинка видео и фон просто топ!
спасибооо!
Интересно, а если оптимизировать всё, то сколько электричества будет сэкономлено?
Спасибо вам за видео!
Относительно примера с хлебушком: если пилка (клин код) режет хлеб в 15 раз хуже, то ствол дерева быстрее пилка резать не будет.
Не совсем понял, как будто смысл здесь одинаков и слева и справа после запятой, но напрашивается противопоставление. Имелось в виду, что клинкод лучше простыни кода в больших проектах?
Классный фон! Это где находится? Что за местность?
Липецкая область
@@t0digital а что там? Какое-то экологическое поселение специально для удалёнщиков? Интернет и электричество там стабильное?
Ещё тейк помимо оптимизации только с профайлером - копать в сторону синтаксических анализаторов и перестройку ast дерева, вне зависимости от языка, чтобы всякие солиды автоматом раскладывались до if/else, а для проверки корректности есть тесты, которыми мы уже обмазались 😊
И да, эти вопросы точно для сурьёзных дядек со степенями в компуктер саенсах)))
Я в своих тактах настолько преисполнился, что мне этот клинкод абсолютно понятен...
Надеюсь, Алексей в итоге не пересек случайно границу, пока сто триллионов миллиардов лет шло
А вообще упущен момент, что добавление абстракций может именно усложнять, а не облегчать читаемость кода, потому что больше в голове смыслов надо прогружать, чтобы разобраться, что здесь происходит.
Ну или как минимум подготовить базу паттернов в голове заранее, что является усложнением в моменте, которое подразумевает пользоваться плодами упрощения позднее
Доброго времени, ждемс обзорчик Linux на Macbook M1
Вроде бы поинт был в том, что "чистый код" не только медленнее, что понятно, но его и читать на самом деле сложнее, и он тратит больше времени программистов.
t.me/t0digital/848 привел там пример кода, нарушающего clean code. Искренне пожелаем успехов разбираться с таким кодом всем противникам clean code.
@@t0digital это код плохой потому что он не клинкод, или потому что он плохо написан?
@@MrBeltalowda он плохо написан - противоречит многим принципам клин кода.
Посмотрел пример и он не делает никакой полезной работы, потому сложно сказать, что он написан производительно. Как пример не клин кода можно взять код dwm, можно рассмотреть читабельность файла на 3000 строк кода. Хотя наверное есть примеры и лучше.
С радостью пишу коммент для хайпа и развития канала
Преждевременная СОЛИДезация - корень зла
Это сонная лощина?
Закон Парето эмпирический, и в реальности цифры 80/20 могут очень широко гулять, да и далеко не все подчиняется этому принципу. Душить закончил, за видео спасибо!
Да, малое число факторов оказывает большее значение, чем большое число тривиальных факторов. Работает не везде - пропасть нельзя перепрыгнуть на 99%, например.
Рад видеть, благодарен за вашу обратную связь, когда только начинал учиться)
Рад сообщить, что сейчас уже 3 места работы сменил, слава Богу)
ура-ура! Ты молодец!
Три места работы сменил? Что-то ненормальное
@@PlayGameToday job hopping, единстывенный способ в рф, поднять свой уровень дохода и сменить спектр задач на более сложные и интересные. нет ничего ненормального, просто такая сейчас тенденция.
Читая "чистый код" я тоже порой офигевал от его советов, но потом понял, что это лишь рекомендация, типа делай функцию 10 строк. Вроде норм совет и простой, а попробуй в проекте огромном сделать все функции в 10 строк, да там хренота полная ж будет :)
У меня тоже есть проект где каждый клиент жрет довольно много ресурсов цпу и озу, тоже думал может где нить его улучшить, оптимизировать и т.д., но мне куда проще и думаю даже дешевле было просто купить 6 ядерный сервер с 24гб озу :) И все нормуль работает, нет никаких тормозов
Погоня за "сферическим конём в вакууме" задача всегда не достижимая, всегда и везде будет что улучшить, но стоит ли?)) В итоге просто балансирую в своих проектах экономя своё время в первую очередь ибо оно конечно
Стива Макконела тож читал, крутой мужик и книгу использую как настольную, часто к ней обращаюсь порой
«Совершенный код» Макконнелла - пушечка!
делать все с нормальной архитектурой
а проблемные участки переписывать под циклы процессора
точно
интересно где ты этот футаж нашел)
ps с видосом полностью согласен, по поводу веба ваще много тупо задержка сети съедает)
за картинку сразу лукс
Я один на заставке к видосику прочитал, как "Чистый код против тракторов процессора" и подумал причем тут тракторы и решил посмотреть видос?)
Куда в программировании без тракторов!
@@t0digital Предпочитаю велосипеды :)
-Микросервисы позволяют писать требовательные модули на компилируемых языках с оптимизациями
- нет смысла оптимизировать время выполнения кода😂
Вроде год назад обсуждали на хабре эту тему. Истина же всегда где-то посередине. Иногда действительно кажется вводят абстракции ради абстракции.
Вам не кажется)
В фреймворках надо замарачиватся над производительностью, и забивать на чистоту.
И еще сейчас мобильные игры и приложения наверно на чистом коде пишут, и это приходится каждые пару лет обновнять железо.
А для вэба, да, большая проблема это бд. Но тут можно маштабироватся, а вот клиент не маштабируешь
в оригинальном видео рапортовали о 10х увеличении перформанса на стороне приложения, в примере автора - 10%.
Таким образом, в данном примере, после оптимизаций и БД и приложения получилось бы из 300мс -> 25мс, где база с 200 уменьшилась до 15, а приложенька со 100 до 10. Изменения получаются практически равнозначными
За табличку влияния одних свойств на других - большой респект
В оригинальном видео Муратори было ускорение и в 17 раз, и в 24 раза. Ссылка на него есть в описании под видео. Но есть огромная разница между оптимизацией куска кода и ускорением работы всей системы. Во всей системе за бОльшую часть работающего кода вы даже не отвечаете - это фреймворк. В большинстве практических сценариев не получится в 17-24 раза укорить такой оптимизацией кода всю систему, а оптимизировав один её кусок как раз с 10мс работы этого куска получится 0.5мс, сам кусок оптимизировался в 20 раз, но в масштабах сервиса - почти незаметно.
@@t0digital абсолютно согласен. Но дело в том, что и на каждый код в базу ходит на каждый чих.
С одним я согласен - оптимизировать надо ботлнеки, а вот их поиск - тема отдельная. Что для нас, что в индустрии в целом, performance engineering.
Так что предлагаю оставить-таки за скоупом этот анализ и принимать оба кейса (что с бд, что с конкретным куском апп-кода) как уже найденную и подтвержденную неэффективность
ПыСы: критика - не значит, что мне не понравилось или полностью не согласен. Я бы даже назвал это не критикой и дискуссией на тему:)
"Вся отрасль веб разработки..." "Там циклы процессора никто не считает". Дак стойте. Веб-разработка же давно уже просочилась в натив: с этим замечательным electron и реакт нейтивом и иже с ними. Вот атом хейтили, vscode хейтят, и вот собственно "за что?", а за производительность
Так вот, не надо всё это экстраполировать на всё. Вот вы правильно сказали, большая часть задержки в веб сервисах из-за ожиданий ввода-вывода. А вот тейк про "бутылочное горлышко" не всегда применимо и часто повторяете "такты процессора"-"такты процессора", но ведь в обсуждении не о тактах процессора шла речь (они-то лишь показатели измерения, а не причина). Вот пример приведённый виндертоном: вычисление площади фигур. Тут-то проблема не в тактах процессора, а в излишней загромождённости для реализации интерфейсов и в излишней модульности: ("чистый код") функции вычисления разбросаны по программе и в объектах лишние чтения виртуальной таблицы, что очень плохо сказывается на производительность с точки зрения кеша; ("быстрый" код) когда-как можно запихнуть все формулы в одну функцию (в памяти относительно недалеко будет весь код находиться, что с большей вероятностью попадёт в одну страницу кеша) и понадобится всего лишь пара переменных в куче, что даже количество обращений в сам кеш значительно уменьшит
В итоге получаем не _[(подгрузка в кеш объекта), чтение vtable из кеша, прыжок, (подгрузка в кеш функции), вычисление площади]_ за каждый запрос (это если обращений в вычислении площади не сортированы по типам фигур), а _[(подгрузка в кеш переменной), условный прыжок, вычисление],_ и если эти параметры фигур находятся недалеко друг от друга (особенно если хранятся как массив), то и подгрузка в кеш переменной будет произходить очень редко (только по выходу из страницы следующая подгрузится). И вы наверное знаете что подгрузка из оперативной памяти в кеш в данном случае самая долгая операция, что в десятки раз замедляет тривиальное вычисление площади
Так-что дробите по модулям в разумных размерах, без фанатизма на атомарные операции
> Так вот, не надо всё это экстраполировать на всё
Мы этим и не занимаемся 17:55
Нужно ли дробить ради того, чтобы дробить? Нет, не нужно - нужно включать голову, это по дефолту. Нужно ли не использовать полиморфизм, потому что это в рамках всей системы даст замедление на 0.00005%? Нет, не нужно. Нужно ли писать код для человека, а не компьютера? Нужно. Нужно ли писать понятный читаемый код? Нужно. Нужно ли заниматься преждевременной оптимизацией (вот тут мы не будем использовать ООП, потому что это неэффективно)? Нет, не нужно.
и это мы еще не трогали геймдев....
VSCode разве медленный? У меня даже на 10-летних компах очень быстро работал. А вот что тормозило, это софт от JetBrains на Java.
Тоже по ходу идёт к реке)
Мне кажется как пользователя вас больше волнует производительность приложения, чем скорость разработки. Иначе закрытие нативных клиентов evernote и переход ими на веб версию электрон, вы бы рассматривали как плюс, а не причину по которой перестали быть их клиентом
Для ускорения работы приложения надо исправлять бутылочные горлышки, а не то, о чем говорит Муратори
красавчик-октавиус на заставке, еее))
Мои пять копеек: рекомендации по оптимизации, это понятно и наглядно - вот пример "плохого" кода, а вот "хорошего" - и в хорошем и в кеш все попадает и инструкции оптимальные используются и даже можно тест запустить и все будет очевидно. А вот со всякими СОЛИД, все гораздо сложнее. Ценность этих рекомендации понятна только на большом проекте и, очевидно, нельзя накидать небольшой пример, который демонстрирует большой проект (это и звучит абсурдно). Поэтому предъявлять претензии к примерам из книжек по СОЛИД изначально несуразно.
03:59 цитата: "Ну вот например вся отрасль ВЕБ-разработки она совершенно про другое, там циклы процессора ни кто не считает..."
Вот поэтому на вашем супермощном компьютере, со 128-ю гигами памяти, с видеокартой 4090 вы будете ловить лаги пока смотрите это видео.
Ну а дальше лапшу вам вешают на уши.
Чистый код менее производителен это факт. Но позволяет быстро расширять архитектуру.
Конечно
Ничего себе идущий к реке поумнел😂😂😂
Для начала. Кто такой Кейси Муратори. Это разработчик игровых движков и т.д. Человек который очень хорошо разбирается в написании производительного кода, который понимает сколько будут стоить те, или иные архитектурные решения в ПО.
Теперь по поводу его видео про чистый код. Его посыл там был совсем в другом. Он привел пример написанный согласно принципам солида, и код написанный в лоб. И он говорит, вот смотрите, код под солидом очень запутанный, логика размазана по куче мест. А вот код написанный без этих выкрутасов. И его во первых очень легко читать и понимать, и самое главное вносить в него изменения. Но и при этом вы получили гораздо, гораздо более производительный код.
И уже после этого завязалась их длительная переписка на гитхабе. В целом идея Муратори в том, что не усложняйте без надобности. Не нужно бездумно следовать всяким там принципам. И что производительность вашего приложения, это не менее важная его составляющая чем остальное.
Меня укачало :)
Все вы говорите о поддерживаемости, читаемости кода и т.п. Но это важно только для человека. Если ваш код не пишет человек - тогда чистый код не так важен(вобще насрать).
p.s. пишу уже полтора месяца исключительно нейронкой. Главное - качественное покрытие тестами. Переписать заново то, что покрыто тестами занимает минимальное количество времени и усилий.
Тогда пусть нейронка сразу асм пишет. Эффективненько и пофик на читаемость.
@@t0digital Вы просто не умеете читать!
То, что вы не умеете читать asm ещё не означает, что код написанный на asm нечитаемый.
Зачем вы пытаетесь меня задеть, друг мой)? Читаемость ASM и читаемость современного высокоуровневого ЯП - разные, будете спорить)?
@@t0digital Совершенно не хотел вас задеть или обидеть чем-то. Просто для некоторых код, написанный на asm читать легче чем на современных высокоуровневых ЯП. Кто-то вообще знает только asm. Кстати нейронка очень неплохо пишет на asm.
@@t0digital Вы меня совсем не поняли. Мой посыл в том, что эпоха "пишем ручками" уходит. Приходит новая. Декларируем требования и проверяем результат. Мне было по-началу очень непривычно... И после многих лет следования принципам чистого кода я оказался не готов к такому подходу к работе. Я привык, что все о чем писал дядя Боб очень полезно и очень помогает. Но начав писать нейронкой я внезапно осознал что все это не важно. Важен лишь результат и скорость его достижения. В итоге ты пишешь тесты (той же нейронкой). Затем пишешь фичи (опять нейронкой). Потом просто запускаешь итеративный авто-дебаг. Нейронка сама ловит ошибки, сама вносит исправления в исходники. Ты лишь отслеживаешь показатели производительности и корректируешь промпт. Все. За день, два у тебя готовая, протестированная фича.
Самое же важное - что обратную связь ты получаешь так же быстро. И тут Agile начинает играть совершенно другими красками. Выходит очень гибкий продукт. Готовый к любым изменениям/переделкам и прочее.
По зову сердца ❤
А операции ввода вывода почему медленно идут? Не потому что, тот кто их писал использовал клин код?)
нет, потому что операции с сетью и диском всегда медленнее, чем с RAM и тем более регистрами процессора
@@t0digital Я как пользователь ПК на это смотрю отрицательно. Мне буквально сказали что я купил новый процессор, не чтобы получить высокую производительность, а чтобы разработчикам было комфортнее.
Думаю если клиентам тоже сказать что без солида они смогут сэкономить в 15 раз на железе, они тоже захотят чтобы разработчики от него отказались.
Тем более что доказать эффективность солида сложно, а вот его влияние на понижение произдводительности - легко.
@@92Darkmind оч громкие, неподкрепленные ничем заявления, притягивающие за уши все что можно и нельзя. Муратори говорил о чистом коде, а не о солид, начнём с этого. Чистый код не про солид, в чистом коде нет даже упоминания солид и всех его прицинпов
@@92Darkmind работодателю этих программистов тогда придется сказать, чтобы потратил в 15 раз больше денег на разработку продукта
100ms там, 100ms здесь... а потом удивляются, почему всё подтормаживает....
Да...
Гораздо чаще эти "оптимизаторы" удивляются, почему зарплату им не повышают)
Ибо они вместо бизнес-фич занимались преждевременной оптимизацией куска кода, который вообще не работает в проде 😏
@@СергейРодин-ю3ъ Дональд Кнут еще тыщу лет назад сказал, что преждевременная оптимизация зло. И что всего 4% кода выполняются более 50% времени работы системы, эти 4% являются целью потенциальной оптимизации в уже работающем приложении, а не остальные 96%
@@СергейРодин-ю3ъкак-то рефакторили проект, в котором до этого внедрялись бизнес фичи без оптимизаций. Вкладка в браузере выжирала несколько гигов, нарушение целостности данных, сабмиты форм могли висеть с десяток секунд. Зато "спринты" успешные были😂
@@t0digital Именно так)
Да и вообще, бездумный подход в чём угодно осложняет жизнь)
Эх, Ваши бы слова, да одному из моих заказчиков в уши. Требовал high perfomace там где это абсолютно не нужно, и вечно пытался пропихнуть свой алгоритм решения, который как раз и есть самый тормознутый участок.
Надо было объяснять на цифрах.
В принципе странно лезть в темы оптимизации с точки зрения питона. Если используется питон или, например, жаба, то энивей лучше клинкодить, чем упарываться в производительность. А вот если делаешь какой-нибудь анриал энджин на плюсах, то лучше уж нечитаемые сорцы, чем вот это вот все.
В недрах ms сделали кеш с поддержкой redis протокола. Анонсировали, что написан на шарпах.
Выкатили его в опенсорс.
Работает ОЧЕНЬ быстро.
Но исходники... практически один сплошной unsafe. Развитие и поддержка такого кода очень и очень дорогая.
@@andrewbondaryuk так могут себе позволить. Они создали конкурентное преимущество ценой дополнительных вложений в разработку и поддержку, бизнес примерно так обычно и работает.
На Unity грамотное проектирование и оптимизации помогают значительно ускорить даже C# код.
Очень здравые мысли от Алексейя, как всегда.
П.С. Ура! Новый видос!
Только сегодня перечитывал SOLID. Классные аналогии, отличная речь, огромный словарный запас. Одно удовольствие слушать) Like!
спасибооо!
Я в своем познании настолько преисполнился, что я как будто бы уже
сто триллионов миллиардов лет проживаю на триллионах и
триллионах таких же планет, как эта Земля, мне этот мир абсолютно
понятен, и я здесь ищу только одного - покоя, умиротворения и
вот этой гармонии, от слияния с бесконечно вечным, от созерцания
великого фрактального подобия и от вот этого замечательного всеединства
существа, бесконечно вечного, куда ни посмотри, хоть вглубь - бесконечно
малое, хоть ввысь - бесконечное большое, понимаешь? А ты мне опять со
своим вот этим, иди суетись дальше, это твоё распределение, это
твой путь и твой горизонт познания и ощущения твоей природы, он
несоизмеримо мелок по сравнению с моим, понимаешь?
все программисты разбились на два лагеря:
первые не видят проблем в написании красивого кода, и считают, что быстро - это не всегда нужно. это фронтендеры.
вторые считают, что красивый код - это круто, но в реальном мире неприменимо, поэтому хотелось бы, но ответственность не позволяет. это разработчики серверов, баз данных, low latency систем и другие люди, бьющиеся за такты процессоров.
и первые, и вторые упускают из вида специфику программного обеспечения друг друга. фронтендеры действительно большую часть времени ждут ответ от серверов, от других процессов, от жесткого диска в конце концов. поэтому им производительность конкретно их приложений не так важна. а бэкендеры наоборот не понимают, как можно писать красивый, но медленный код, потому что у них время задержки в 1 секунду означает, что начнет расти очередь запросов, поэтому сервер может начать отвечать 500.
поэтому тут спор несколько странный и зависит скорее от компетенций специалистов, принимающих решения о том или ином архитектурном решении
Вас всегда приятно слушать
Картинка классная но лучше не трясти вправо влево(
😂 тогда ходить не удобно..
вот фик знает как блохеры ходят и снимают)))
@@t0digital стабилизатор используют
Это видео с DJI osmo pocket 3, трехосевого стабилизатора
База!👍
Оптимизация под процессоры не так уж страшна. На таких языках, как Ада и Delphi, можно использовать пользовательские перечисления, и эти перечисления использовать как индекс массива. В более примитивных языках программирования, где массивы только цифрами нумеруются, там да, там то же самое выглядит как низкоуровневые заморочки
переписываем всё на Ада! Завтра после обеда:)
@@t0digital Переписывание постоянно происходит, ведь куда-то улетучились Win32 exe с GDI, а стали веб-сервера
win32 exe вроде живы пыхтят-работают, не переписали их на ада)
@@t0digital Я продолжал начатое другим разработчиком переписывание с PHP на C++, именно из-за проблем с производительностью. Стало получше, но не настолько, как хотелось. Упёрлись в то, что у прошлого разработчика был юникс головного мозга, и он сервер ортодоксально сделал по архитектуре accept-fork, а через fork-нутые процессы сложно, почти невозможно, разделять подключения к БД, и на каждое подключение к веб было нужно новое свежее подключение к БД, которое долгое, и это всё отравляло. А вот PHP-то подключения разделял. Переделать C++ сервер с процессов на потоки было сложно, там подразумевалось, что каждый процесс живёт в отдельной виртуальной памяти, модифицирует всё что ни попадя. Новый адский сервер я сразу делал как надо, многопоточный, а не многопроцессный.
На текущей работе задолбались с Питоном. Коллеги новую версию одного из серверов написали на Delphi. Ещё один новый, в смысле, не имеющий аналогов, сервер уже на Delphi изначально делал. Постоянно что-то кипит, заменяется, есть окно возможностей улучшить стек
Напоминает место возле нашей дачи
О, гений виндертон опять смог перевести англоязычное видео 😂?
Эстетика видоса прикольная
А куда он пропал?
я тут!
@@t0digital оу здравствуйте, хотел спросить почему у вас стало так мало роликов выходить в последнее время?
@@gapchannelAi
Так уж вышло, буду исправлять!
@@t0digital спасибо, что ответили на вопрос. Будем ждать))
Есть конкретный пример когда "правильный" кодстайл привел к проблемам с производительностью - Ceph.
интересно, есть какие-то ссылки об этом?
@@t0digital
Затянул с ответом
ruclips.net/video/YST24EiPGnc/видео.html
Но это не единственный доклад, в том числе есть Ceph анатомия катастрофы, там так же критикуются подходы "не в лоб" для задач системного программирования. Принципы типа "функция не должна быть больше одного экрана для читаемости" не работают, когда задача писать не расширяемый, а производительный код.
идущий в it
Преждевременная оптимизация хуже преждевременной эякуляции.
@ Дональд Кнут
@@t0digital актуально 50 лет. Классики давно всё написали, а тут холивар из ничего.
Вот интересно, в Mercedes или BMW каждую машину делают сначала абы как, лишь бы дизайн красивый был, и только в конце начинают перепроектировать двигатели и ходовые, сбрасывая по 50-60% лишнего веса и увеличивая мощность в десятки раз?
Или они все же, имея опыт, заранее грамотно проектируют новые узлы так, чтобы не пришлось "оптимизировать" когда конвейер уже запущен?
По хорошему оптимизация начинается на этапе проектирования.
я могу подождать 10-15 секунд пока у меня прогрузится пчта, но каждый день я надеюсь, что когда-нибудь мне придется ждать меньше 5. Как было лет 10 назад.
странно, у меня грузится меньше 5
Он в целом о том и говорит, основной его аргумент в том, что люди часто используют SOLID потому что "так надо", как еслиб это была какая то догма. Т.е. люди сначала делают задел на будущее (а пихну как я сюда эту абстракцию, вдруг завтра понадобится), а потом начинают только писать что-то что делает реальную работу. И Маратори и говорит - что код должен быть понятным, в это не обязательно SOLID. Есть его интервью короткое: ruclips.net/video/DsAclZbP_Us/видео.html
Там же ссылка на полное, интересно тоже посмотреть.
Не сотвори себе кумира, как говорится :)
SOLID != чистый код. В чистом коде нет ни упоминания SOLID, ни всех принципов SOLID. Муратори говорит о чистом коде.
@@t0digital Я понимаю, что это не одно и то же, можете заменить в моем комменте SOLID на "некую догму". И он говорит о Clean Code и SOLID, например здесь ruclips.net/video/7YpFGkG-u1w/видео.html
в оригинальном видосе, который вызвал весь спор, ruclips.net/video/tD5NrevFtbU/видео.html, он называет Clean code какие-то рандомно выписанные принципы из всего массива того, что Мартин именует Clean Code
может быть это новость ...
но "программа работает" - подразумевает что работает на ПРАВИЛЬНО.
если программа выдает неверный результат - она не работает ...
Коллега какое-то время меня упрекал за то, что я разделяю методы на более маленькие, говорил, что я убиваю так производительность, потому что он читал, что вызов методы сжирает целый ТАКТ! Трагедия великая, убедить я коллегу смог в обратном далеко не сразу, пришлось его заставить прочитать книжку, только после этого он перестал меня в подобном упрекать.
Книга не Мартина, две книжки от O'REILLY, Head First Паттерны проектирования и Head First Java для чайников.
Иногда он пишет мне с различными вопросами по паттернам, а когда я ему привожу некий пример улучшения слышу: "Я если честно книге больше верю". Интересно, что будет, если он прочтёт книги Мартина, наверное вообще мне писать перестанет :))
@electrikkk Вероятно, не знает. Мы с ним работаем с Java и тут о работе компилятора почти ничего не знаем, так как используем готовые системы для сборки. Хотя очевидно разобраться стоит, спасибо за мыслю!
@electrikkk Верю. Я просто не уверен, что это так в Java. По запросу "PGO Java" гугл выдает очень скудный объем информации
Ваш коллега был не совсем прав. )) При вызове простой функции оверхед может составлять 10-20 тактов. Скорее всего они имел в виду вызовы виртуальных функций, которые дороже обычных на 1-2 такта, при условии попадания в кэш. Чем больше у функции аргументов, тем больше времени уходит на вызов. Поэтому на с++ небольшие функции часто инлайнят.
Облаял это видео. Ай лав зыс ченнэл.
А почему все программисты любят эти ужасные очки хамелеоны? Это так по задротски. По теме видео - полностью согласен с автором.
Потому что мы задроты, ёпта!
Да там тесты у Муратори такие, что он очень простую функцию обернул в два класса и говорит, что в 15 раз перфоманс упал. Вот если бы он попробовал 2 больших проекта написать в двух разных стилях, он бы тогда понял, что влияние абстракций будет уже не таким значительным. Я вангую, что там максимум 50% можно наскрести с оверхеда, но никак не 1500%. Наверное, у господина Муратори много свободного времени, пусть напишет более приближенный к реальной жизни бенчмарк, тогда и поговорим)
да даже 50% в общем случае не наскрести - если реальное приложение с базой и пачкой SQL-запросов
Странная постановка вопроса. Если ты пишешь то, что никто и никогда не будет переписывать, то эффективность - единственная цель. Если ты пишешь код, который будут читать и развивать, то читаемость - первостепенная задача, а эффективность - вторая. Понятное дело, что работоспособность и отказоустойчивость кода - это более значемые его параметры.
В ИТ нет ничего более постоянного, чем изменения. Крайне редко что-то не будет дорабатываться и изменяться, даже если в момент написания кода кажется иначе. И, как верно пишет Макконнелл, писать хорошо и писать плохо - примерно идентично по трудозатратам. Под писать хорошо подразумевается писать расширяемый, поддерживаемый, читаемый, тестируемый, модульный код.
Не очень понимаю, как можно вообще обращать внимание на виндертона после нескольких "разоблачений". Да и в целом одного Artanik'a хватило
Речь не о виндертоне
Однозначно согласен с вами, Алексей, проблемы нужно искать не в чистом декомпозированном коде, а в непроизводительных внешних сервисах. А упоминания термина bottleneck мне очень понравилось!
Ах да! Соскучился по вам! Возвращайтесь сюды почаще, пожалуйста
@@fatoldhikki4837 Да, есть! Криворукие программисты. Да и не забывайте, что вы пишете не на чистом (истинном) машинном коде, а на приятненькой обёртке, которая сделана для нас, чтобы наши программистские ручонки не дрожали, вводя инструкции, или того хуже, байты! Любой язык программирования вносит свою лепту в производительность. И если вы допускаете это, то допускать можно. Хотя нет, нужно! Нужно допускать другие подходы к программированию, облегчающие написание, как, например, подходы, описанные в книжках дядюшкой Бобом.
Отлично разобрал.
спасибо!
Короче, вывод простой: не занимайтесь "фигней" )
Самая главная профессия будущего в it: оптимизатор существуещего кода. Правда бить будут сильно и ногами 😂
Так бидь будут тех, кто написал, а того, кого позвали править
@@arsolitt так и не понял, кого "не" )
По теме все и так очевидно а вот зачем солнечные очки в пасмурную погоду?
фотохромные линзы с диоптриями
@@t0digital почитал, не знал что они темнеют и в облачную погоду из-за ультрафиолета.
Считать такты чужого проца не щадя своих,не оптимально однако😅
факт:)
я настолько преисполнился
Тема интересная, но меня слегка укачало, пришлось только слушать.
Ну вот давайте честно. В продакшене, в бизнесе, всем насрать на скорость ответа.
Важно:
Программисту - быстрее сделать.
Бизнесу - быстрее получить и заработать.
Пользователь - разницы не почувствует, если уж совсем трешкода там нет.
Итог. Если речь не о секундах, а о миллисекундах, пользователю все равно.
Работал над проектом, без кеша страница грузилась 30 секунд. Все было в SOLID и абстракция на абстракции зато :)
Зачем очки, если пасмурно?
Фотохромные линзы с диоптриями