Чистый код vs такты процессора, Мартин vs Муратори vs Макконнелл
Vložit
- čas přidán 5. 05. 2024
- Мой курс «Хардкорная веб-разработка» - course.to.digital
Книжный клуб Ботаним!, где мы читаем хорошие ИТ-книги: botanim.to.digital/
Telegram - t.me/t0digital
Чистый код - это неэффективно и медленно?! Давайте разбираться!
Видео @wndtn - • Инцидент, Который Созд...
Оригинальное видео Casey Muratori - • "Clean" Code, Horrible...
/****************** about ******************/
Меня зовут Алексей Голобурдин, я программирую с 2004 года и на этом канале делюсь своим опытом. Я основатель и руководитель компаний:
- Диджитализируй digitalize.team, разрабатываем сложные IT системы для бизнеса;
- Salesbeat salesbeat.pro, комплексный модуль доставки для интернет магазинов.
Telegram канал - t.me/t0digital
ВК - digitalize.team
RuTube - rutube.ru/channel/24802975/ab...
Дзен - dzen.ru/id/6235d32cb64df01e6e...
Тем временем мой курс «Хардкорная веб-разработка» продолжается - course.to.digital
Идущий к Data Lake
тогда уж к Data River
@@4t0m1c3 Data Lake это не просто набор слов:) en.wikipedia.org/wiki/Data_lake
@@t0digital да я в курсе просто рофл
Лишь бы не к Data Swamp
идущий к реке увлекся it
Только что собирался это написать, ахххах
Мне этот код абсолютно понятен….
Я в своем познании настолько преисполнился
солид - это парень, который сухпайки в лесу пробует?
Именно, он тестировщик
Чел харош
Который Снейк
czcams.com/video/Mx76RGHbfms/video.html
Книги Мартина хороши, но если не пропускать их через свой критический анализ - то можно заболеть "чистым кодом головного мозга".
Мартин не пишет профессионально код уже лет 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, когда можете написать и на выбранном языке в десятки раз быстрее. Выложили кусочек кода в тг, дабы доказать что те кто думает о производительности, называют переменные буквами....
Я в коде ищу только одного: умиротворения и вот этой гармонии от слияния с бесконечно-вечным. На дворе благодать и мне этот Мураками абсолютно понятен, но ему не понять
Придумать нелепые примеры и победить их - замечательно) манипуляция называется "соломенное чучело". А по существу вопроса - речь в видео Муратори идет об увеличении производительности в десятки раз, а не на 10%.
В десятки раз можно оптимизировать производительность куска кода, заменив где-то локально один кусок кода на другой. Вот какой-то кусок из 300мс сервиса работает 10мс и вы его сжали до 0.05мс, увеличив производительность в 200 раз. Однако общее время сервиса уменьшилось с 300 до 290 мм всего, на 3%, а не в десятки раз.
Чтобы изменить в десятки раз производительность всей большой системы - нужны куда более радикальные подходы, которые уже не называют оптимизацией.
@@t0digital помнится, как один из модеров уменьшил время загрузки GTA 5 в среднем с 60 с до 10. 1 строкой кода. с точки зрения часовой игровой сессии - ускорение где то около процента, но оказалось что это очень сильно заметно.
@@t0digital У вас Подмена понятий, манипуляция. Даже ваш пример,эккзотический будет на физическом ядре хостера ,оторый ДЕЛИТ своё процессорное времяъ\циклы на работу с другими хостерами! Что вы юлите?!??
@@necroticuss6780 Современный серьезный веб-проект с мало-мальской нагрузкой не делит ядро CPU между кодом приложения и хранилищем - хранилище вынесено на отдельный сервер или кластер серверов с репликами. И понизь свой тон, не знаешь ни хера и споришь до усёру.
@@necroticuss6780 прододжишь в том же русле - бан.
Мне этот спор абсолютно понятен...На мой взгляд можно сократить до фразы есть задачи упирающиеся в 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, где он пишет игру + движок загляните - это интересно.
Всё зависит от того чем занимаешься - если ты пишешь код базы данных, то к тебе совсем другие требования будут и если ты оптимизируешь только бутылочные горлышки, то получишь равномерно медленный код, который больше негде оптимизировать. Поэтому есть случаи когда производительность должна быть заложена в архитектуру.
Или например сервис высоконагруженный пишешь - там уже не до питона, сразу надо нормальный язык использовать и думать о производительности всегда.
Вспомнилось:
Я печатаю со скоростью 1000 знаков в минуту. Такая фигня получается!
😂 все так
0:03 «критика чистого кода» как «Критика чистого разума» И. Канта.
Крайности рассматриваем. А хотелось бы разумного, более взвешенного обзора. Да и без примеров, по дороге с облаками про код говорить - простое увеличение энтропии вселенной, которая и без того велика.
Нет, крайности не рассматриваем. Более того, в видео явно говорится о том, что крайности и догматизм это плохо. Касательно примеров - если вы не можете говорить о разработке без примеров кода, то пока что вам рановато смотреть такие видео.
Алексей, спасибо! Когда слушал, как раз, хотел написать про золотую середину.
Формат видоса "что-то обкашлять" отличный! Подача, как всегда, на высоте.
сейчас вспомнил какие неоптимизированные игры пошли, там важен каждый процент
) это не только из-за чистого кода, это из-за кучи аспектов архитектуры процессора ядра и тд, из-за simd операций, из-за миллионов способов отразить треугольник, из-за 505 способов обнаружить столкновение кубиков друг с другом и тд
@@user-bc9tu6om8b Тодд Говард: Если у вас тормозит Starfield, то давно пора обновить ПК!
Сегодня смотрел видео Виндертона, обдумывал что да как.
Пришел к выводу, что clean code сейчас не про эффективность, а про то, чтобы все программисты открывая код, писали в одном стиле, скажем так.
И не было проблем в дальнейшем изменении или обновлении кода
не совсем. клинкод не защитит от проблем. да и в одном стиле писать всем это недостижимая мечта. а вот что сделает клинкод так это сократит количество человекочасов на освоение и поддержку кодбазы. если простыми словами то клинкод это меньшее зло, и индустрия с удовольствием его приняла чтобы банально срезать косты. точно так же когда-то придумали высокоуровневые языки чтобы было проще. и точно так же придумали низкоуровневые языки чтобы не писать ассемлер. и точно так же ассемблер придумали чтобы не писать код на целой коробке перфокарт которые весят 5 кило.
Чистый код - это инструмент инженера (ножичек по ролику) для управления сложностью решаемых кодом проблем. Вокруг него выстроены целые комбайны (кодогенераторы, IDE, верификаторы), работая с которыми, если не придерживаться стиля СОЛИД, получим чудо-чудное монолитно-падучее ... с которым уже никакие такты и оптимизации не справлялись, ибо падало, и очень оптимально, и нередко тянула за собой и базы, что выливалось в человеко-часы любви и дзена.
это вывод виндертона, а твой вывод где?
Спасибо вам за видео!
Спасибо за разбор!
Рад видеть, благодарен за вашу обратную связь, когда только начинал учиться)
Рад сообщить, что сейчас уже 3 места работы сменил, слава Богу)
ура-ура! Ты молодец!
Три места работы сменил? Что-то ненормальное
@@PlayGameToday job hopping, единстывенный способ в рф, поднять свой уровень дохода и сменить спектр задач на более сложные и интересные. нет ничего ненормального, просто такая сейчас тенденция.
интересно где ты этот футаж нашел)
ps с видосом полностью согласен, по поводу веба ваще много тупо задержка сети съедает)
Вроде бы поинт был в том, что "чистый код" не только медленнее, что понятно, но его и читать на самом деле сложнее, и он тратит больше времени программистов.
t.me/t0digital/848 привел там пример кода, нарушающего clean code. Искренне пожелаем успехов разбираться с таким кодом всем противникам clean code.
@@t0digital это код плохой потому что он не клинкод, или потому что он плохо написан?
@@MrBeltalowda он плохо написан - противоречит многим принципам клин кода.
100ms там, 100ms здесь... а потом удивляются, почему всё подтормаживает....
Да...
Гораздо чаще эти "оптимизаторы" удивляются, почему зарплату им не повышают)
Ибо они вместо бизнес-фич занимались преждевременной оптимизацией куска кода, который вообще не работает в проде 😏
@@user-fh6xg9pn3y Дональд Кнут еще тыщу лет назад сказал, что преждевременная оптимизация зло. И что всего 4% кода выполняются более 50% времени работы системы, эти 4% являются целью потенциальной оптимизации в уже работающем приложении, а не остальные 96%
@@user-fh6xg9pn3yкак-то рефакторили проект, в котором до этого внедрялись бизнес фичи без оптимизаций. Вкладка в браузере выжирала несколько гигов, нарушение целостности данных, сабмиты форм могли висеть с десяток секунд. Зато "спринты" успешные были😂
@@t0digital Именно так)
Да и вообще, бездумный подход в чём угодно осложняет жизнь)
Я один на заставке к видосику прочитал, как "Чистый код против тракторов процессора" и подумал причем тут тракторы и решил посмотреть видос?)
Куда в программировании без тракторов!
@@t0digital Предпочитаю велосипеды :)
Я в своих тактах настолько преисполнился, что мне этот клинкод абсолютно понятен...
Надеюсь, Алексей в итоге не пересек случайно границу, пока сто триллионов миллиардов лет шло
А вообще упущен момент, что добавление абстракций может именно усложнять, а не облегчать читаемость кода, потому что больше в голове смыслов надо прогружать, чтобы разобраться, что здесь происходит.
Ну или как минимум подготовить базу паттернов в голове заранее, что является усложнением в моменте, которое подразумевает пользоваться плодами упрощения позднее
делать все с нормальной архитектурой
а проблемные участки переписывать под циклы процессора
точно
Есть конкретный пример когда "правильный" кодстайл привел к проблемам с производительностью - Ceph.
интересно, есть какие-то ссылки об этом?
Это сонная лощина?
По зову сердца ❤
Куплинов, спасибо большое за обзор темы!
Желательно, чтобы любой комментирующий в ЭТОЙ теме указывал в каком проекте он работает:
1) размер команды
2) количество внешних интеграций
3) количество строк кода ( да-да-да! )
4) количество бизнес-сущностей в системе
5) срок жизни проекта
6) сколько работает в проекте
7) сколько работает в отрасли
Вот тогда можно отделить кровавый ынтырпрайз от плевел и узнать мнение разработчиков участвующих в РЕАЛЬНО больших проектах.
Мартин, если что, столуется в MS у которого опыта в кровавых ынтырпрайзах явно достаточно, чтобы продвигать его идеи ;)
p.s. это как спор perl vs python: первый ещё называют write only ЯП
Относительно примера с хлебушком: если пилка (клин код) режет хлеб в 15 раз хуже, то ствол дерева быстрее пилка резать не будет.
Не совсем понял, как будто смысл здесь одинаков и слева и справа после запятой, но напрашивается противопоставление. Имелось в виду, что клинкод лучше простыни кода в больших проектах?
19:10 Так проблема в том, что не известно для каких задач какие инструменты подходят и более эффективны. Кто-то например считает, что на Python нельзя писать ПО с повышенным требованием к правильности работы, а нужно использовать Ada или Rust.
Кейси как раз и заявил, что надёжно и понятно можно писать не используя паттерны клинкода и это ещё будет быстро.
офигеть картинка крутаяя!!! а счего снималось, если не секрет?
Спасибооо! Dji Osmo pocket 3
@@t0digital а звук?)
Тоже на него. В комплекте creator combo идет беспроводной микро dji, он же и отдельно продается. Звук не как с пушки Rode ntg3 дома, но тоже сносно вроде:)
Справедливости ради, ориентироваться на питон и типовые веб-серверы в данном споре немного странно. Страннее было бы только bash-скрипты приводить в пример.
Насколько я понял, они всё-таки спорили не про то, что clean code не имеет области применения, а про то, что область применения clean code ограничена, при этом в книгах дяди Боба эти ограничения не упомянуты.
И про то, что производительность и читаемость кода не всегда противопоставляются друг другу, а производительный код может быть читабельным и сопровождабельным, но при этом он не будет соответствовать clean code'у. А вот код, соответствующий clean code'у, производительным быть не может.
В общем в видео всё сказано правильно, только к обсуждаемому спору прямого отношения не имеет.
Да, Python всего лишь (по ряду рейтингов, TIOBE, например) самый популярный язык программирования в мире на сегодня, ориентироваться на него действительно странно.
@@t0digital В данном споре да. Проблема очевидно не в популярности, а в том, что если речь зашла о производительности, то питон тут не показателен, просто потому что питон сам по себе медленный.
Есть, конечно, ещё числодробилки, но и в них всё, что пишется на питоне к производительности не критично.
В общем опять вроде всё правда, но к теме никак не относится.
Python медленный, но тем не менее на нём пишут много кода, судя по рейтингу - так почему не говорить о его производительности, чистом коде на питоне и тд? Не понял твою мысль.
@@t0digital Потому что на питоне пишут код, для которого производительность как правило не критична, или не очень значима.
Рассматривать спор о производительности подхода к программированию, используя ориентир, для которого производительность почти не важна, не имеет смысла.
Этим можно только доказать, что производительность кода не всегда важна, но кто вообще с этим спорил?
Изначальный спор - клин код говно, потому что он в 15 раз медленнее. Я оспариваю это заявление. Применим ли клин код к питону? Конечно. Если верить этому утверждению, пайтон разрабы должны перестать писать клин код, потому что он в 15 раз медленнее. Но а) это не так б) клин код не замедляет производительность всегда, в общем случае, по умолчанию, потому что клин код это гораздо больше чем SOLID, названа переменная e (не клин код) или employee_index (клин код) - разницы в производительности никакой не будет. Однако i у тебя ни один вменяемый код-ревьюер не пропустит на ревью, что на питоне, что на чем угодно, потому что это ВАЖНО!
красавчик-октавиус на заставке, еее))
ну кстати, иногда понимание внутренней реализации python, позволяет оптимизировать код не прибегая к переписыванию на rust или c. tuple вместо list когда не нужно изменять коллекцию, слоты в дата-классах чтобы немного память по экономить. в общем просто нужно хорошо знать свой инструмент.
конечно
Из питона не особо чего выжмешь даже подобными методами. Хотя мне не так давно пеняли за использование append и break, мол, плохо сказывается на производительности. Хотя нагрузки у нас где-то околонулевые.
@@redneck_prm5429ну по поводу коллекций, на мой взгляд тут просто здравый смысл. А про слоты... если в какой-то класс их руками класть, выглядит скажем так себе. а в dataclass просто один аргумент в декораторе указать. красиво, да и лишнюю динамику уберёт. мы всё-таки как правило в большинстве случаев не добавляем в объект поля динамически, а работаем с фиксированным их количеством.
Использовать list без append - это как и зачем? Не нужны добавления данных в структуру - юзай tuple, это понятно, но у tuple и нет append. А чем плох break с точки зрения производительности?
@@t0digital Ну там можно было обойтись без листа, код просто стал чуточку страшнее. Про break я тож не понял, но нашему сеньёру видимо довелось покушать питонского хайлоада, где на такие штуки действительно заморачивались. Поэтому поверил на слово.
О, гений виндертон опять смог перевести англоязычное видео 😂?
Это всё сферические рассуждения про производительность базы данных 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 и микросервисы головного мозга. Надо всегда с умом подходить к задаче и не наворачивать лишних сущностей где в них нет необходимости.
Ещё тейк помимо оптимизации только с профайлером - копать в сторону синтаксических анализаторов и перестройку ast дерева, вне зависимости от языка, чтобы всякие солиды автоматом раскладывались до if/else, а для проверки корректности есть тесты, которыми мы уже обмазались 😊
И да, эти вопросы точно для сурьёзных дядек со степенями в компуктер саенсах)))
Читая "чистый код" я тоже порой офигевал от его советов, но потом понял, что это лишь рекомендация, типа делай функцию 10 строк. Вроде норм совет и простой, а попробуй в проекте огромном сделать все функции в 10 строк, да там хренота полная ж будет :)
У меня тоже есть проект где каждый клиент жрет довольно много ресурсов цпу и озу, тоже думал может где нить его улучшить, оптимизировать и т.д., но мне куда проще и думаю даже дешевле было просто купить 6 ядерный сервер с 24гб озу :) И все нормуль работает, нет никаких тормозов
Погоня за "сферическим конём в вакууме" задача всегда не достижимая, всегда и везде будет что улучшить, но стоит ли?)) В итоге просто балансирую в своих проектах экономя своё время в первую очередь ибо оно конечно
Насчет тактов процессора. Если взять на чистом си написать небольшую программу, откомпилировать. А затем дизасемблировать и посмотреть что сделал компилятор в ходе оптимизации. То можно очнь сильно удивиться. А если посмотреть на ключи компилятора, то можно увидеть ключ с разными уровнями оптимизации. И для того чтобы считать такты процессора нужно, как минимум, знать что и как компилятор оптимизирует.
У него сайты по 15 секунд грузятся. Всё в программировании упирается в алгоритмы, если есть возможность оптимизировать код ( даже SQL и не только индексы ), то это делать нужно.
Товарищи программисты, в глаза не долбитесь, пожалуйста.
У кого у него сайты по 15 сек грузятся?
В фреймворках надо замарачиватся над производительностью, и забивать на чистоту.
И еще сейчас мобильные игры и приложения наверно на чистом коде пишут, и это приходится каждые пару лет обновнять железо.
А для вэба, да, большая проблема это бд. Но тут можно маштабироватся, а вот клиент не маштабируешь
Доброго времени, ждемс обзорчик Linux на Macbook M1
Тоже по ходу идёт к реке)
Стива Макконела тож читал, крутой мужик и книгу использую как настольную, часто к ней обращаюсь порой
«Совершенный код» Макконнелла - пушечка!
Облаял это видео. Ай лав зыс ченнэл.
А операции ввода вывода почему медленно идут? Не потому что, тот кто их писал использовал клин код?)
нет, потому что операции с сетью и диском всегда медленнее, чем с RAM и тем более регистрами процессора
@@t0digital Я как пользователь ПК на это смотрю отрицательно. Мне буквально сказали что я купил новый процессор, не чтобы получить высокую производительность, а чтобы разработчикам было комфортнее.
Думаю если клиентам тоже сказать что без солида они смогут сэкономить в 15 раз на железе, они тоже захотят чтобы разработчики от него отказались.
Тем более что доказать эффективность солида сложно, а вот его влияние на понижение произдводительности - легко.
@@92Darkmind оч громкие, неподкрепленные ничем заявления, притягивающие за уши все что можно и нельзя. Муратори говорил о чистом коде, а не о солид, начнём с этого. Чистый код не про солид, в чистом коде нет даже упоминания солид и всех его прицинпов
@@92Darkmind работодателю этих программистов тогда придется сказать, чтобы потратил в 15 раз больше денег на разработку продукта
идущий на съемки боевика 90х с Жан-Клодом ван Даммом
С Жан КоДом
Картинка классная но лучше не трясти вправо влево(
😂 тогда ходить не удобно..
вот фик знает как блохеры ходят и снимают)))
@@t0digital стабилизатор используют
Это видео с DJI osmo pocket 3, трехосевого стабилизатора
идущий в it
Напоминает место возле нашей дачи
привет всем! следил за этой темой и тут этот ролик. в тему!
А куда он пропал?
я тут!
@@t0digital оу здравствуйте, хотел спросить почему у вас стало так мало роликов выходить в последнее время?
@@gapchannelAi
Так уж вышло, буду исправлять!
@@t0digital спасибо, что ответили на вопрос. Будем ждать))
Короче, вывод простой: не занимайтесь "фигней" )
я настолько преисполнился
Очень здравые мысли от Алексейя, как всегда.
П.С. Ура! Новый видос!
Да вроде ж очевидные вещи
Эх, Ваши бы слова, да одному из моих заказчиков в уши. Требовал high perfomace там где это абсолютно не нужно, и вечно пытался пропихнуть свой алгоритм решения, который как раз и есть самый тормознутый участок.
Надо было объяснять на цифрах.
Эстетика видоса прикольная
По факту всё разложил! Полностью согласен с автором видео. Слишком много шума из-за этого не очень грамотного и всё максимизирующего Муратори. На самом деле шумность комьюнити по этому поводу лишь подтверждает общую деградацию программистов в среднем по палате.
-Микросервисы позволяют писать требовательные модули на компилируемых языках с оптимизациями
- нет смысла оптимизировать время выполнения кода😂
Вроде год назад обсуждали на хабре эту тему. Истина же всегда где-то посередине. Иногда действительно кажется вводят абстракции ради абстракции.
Вам не кажется)
все программисты разбились на два лагеря:
первые не видят проблем в написании красивого кода, и считают, что быстро - это не всегда нужно. это фронтендеры.
вторые считают, что красивый код - это круто, но в реальном мире неприменимо, поэтому хотелось бы, но ответственность не позволяет. это разработчики серверов, баз данных, low latency систем и другие люди, бьющиеся за такты процессоров.
и первые, и вторые упускают из вида специфику программного обеспечения друг друга. фронтендеры действительно большую часть времени ждут ответ от серверов, от других процессов, от жесткого диска в конце концов. поэтому им производительность конкретно их приложений не так важна. а бэкендеры наоборот не понимают, как можно писать красивый, но медленный код, потому что у них время задержки в 1 секунду означает, что начнет расти очередь запросов, поэтому сервер может начать отвечать 500.
поэтому тут спор несколько странный и зависит скорее от компетенций специалистов, принимающих решения о том или ином архитектурном решении
Закон Парето эмпирический, и в реальности цифры 80/20 могут очень широко гулять, да и далеко не все подчиняется этому принципу. Душить закончил, за видео спасибо!
Да, малое число факторов оказывает большее значение, чем большое число тривиальных факторов. Работает не везде - пропасть нельзя перепрыгнуть на 99%, например.
Тема интересная, но меня слегка укачало, пришлось только слушать.
Считать такты чужого проца не щадя своих,не оптимально однако😅
факт:)
Послушай что говоришь: "производительность в 17 раз хуже", "не 100мс, а 90мс, 10% всего".
Тайм код, пожалуйста, про 17 раз хуже
Думал, на превью Лепс
Извиняюсь, но каким образом виндертон все ещё рукопожатен?
видео не о виндертоне
@@t0digitalну по самому видео вопросов никаких, все мысли верные)
А за что он должен был стать нерукопожатным? Не припоминаю ничего такого
@@lizenox Он скамил людей несколько лет назад, есть разоблачения на ютубе.
@@lizenox за скам, за выдачу чужого кода за свой и так далее.
в оригинальном видео рапортовали о 10х увеличении перформанса на стороне приложения, в примере автора - 10%.
Таким образом, в данном примере, после оптимизаций и БД и приложения получилось бы из 300мс -> 25мс, где база с 200 уменьшилась до 15, а приложенька со 100 до 10. Изменения получаются практически равнозначными
За табличку влияния одних свойств на других - большой респект
В оригинальном видео Муратори было ускорение и в 17 раз, и в 24 раза. Ссылка на него есть в описании под видео. Но есть огромная разница между оптимизацией куска кода и ускорением работы всей системы. Во всей системе за бОльшую часть работающего кода вы даже не отвечаете - это фреймворк. В большинстве практических сценариев не получится в 17-24 раза укорить такой оптимизацией кода всю систему, а оптимизировав один её кусок как раз с 10мс работы этого куска получится 0.5мс, сам кусок оптимизировался в 20 раз, но в масштабах сервиса - почти незаметно.
@@t0digital абсолютно согласен. Но дело в том, что и на каждый код в базу ходит на каждый чих.
С одним я согласен - оптимизировать надо ботлнеки, а вот их поиск - тема отдельная. Что для нас, что в индустрии в целом, performance engineering.
Так что предлагаю оставить-таки за скоупом этот анализ и принимать оба кейса (что с бд, что с конкретным куском апп-кода) как уже найденную и подтвержденную неэффективность
ПыСы: критика - не значит, что мне не понравилось или полностью не согласен. Я бы даже назвал это не критикой и дискуссией на тему:)
я могу подождать 10-15 секунд пока у меня прогрузится пчта, но каждый день я надеюсь, что когда-нибудь мне придется ждать меньше 5. Как было лет 10 назад.
странно, у меня грузится меньше 5
Мои пять копеек: рекомендации по оптимизации, это понятно и наглядно - вот пример "плохого" кода, а вот "хорошего" - и в хорошем и в кеш все попадает и инструкции оптимальные используются и даже можно тест запустить и все будет очевидно. А вот со всякими СОЛИД, все гораздо сложнее. Ценность этих рекомендации понятна только на большом проекте и, очевидно, нельзя накидать небольшой пример, который демонстрирует большой проект (это и звучит абсурдно). Поэтому предъявлять претензии к примерам из книжек по СОЛИД изначально несуразно.
Только сегодня перечитывал SOLID. Классные аналогии, отличная речь, огромный словарный запас. Одно удовольствие слушать) Like!
спасибооо!
Самая главная профессия будущего в it: оптимизатор существуещего кода. Правда бить будут сильно и ногами 😂
Так бидь будут тех, кто написал, а того, кого позвали править
@@arsolitt так и не понял, кого "не" )
База!👍
Код надо писать для человека, только этот человек - ваш заказчик, тот кто заплатил за него, а не тот кто будет его читать / ковырять / расширять и прочее. Если код не готов в срок,(к примеру, у заказчика была маркетинговая акция к 1 сентября, и 2 сентября она уже смысла не имеет) он не стоит ничего
Ну да. Если до тебя в проекте упарывались оптимизациями на пустом месте, то новую функциональность, которую можно было бы выпустить к 1 сентября, можно не успеть толком выпустить и к августу следующего года. Но работать будет (если будет) очень быстро. Скорее всего!
@@t0digital так чтобы новую выпустить, надо сначала старую допилить вовремя, а там кот (зато чистый)😃
@@deltaedu9862 с чистым кодом нет проблем, проблемы есть с преждевременно "оптимизированным" кодом
Это че за код такой? Лендинг что ли? Нормальный проект за 1 день не устареет.
Нео идет к реке...теперь я видел все...
подождите, виндертон ожил? после разгромного разоблачения? не прошло и 5 лет, наверное подтянул знания.. или нет?
Не знаю. Видео не о нем
@@t0digital понимаю, что не о нем. Вопросы заданы с иронией) Виндертона давно разоблачали как профана, который умудрился неплохо заработать, как аудиторию так и денег, на продаже образа крутого разработчика. После разоблачения, он кажется забросил свой канал, сейчас вижу что снова выкладывает ролики.
Я в своем познании настолько преисполнился, что я как будто бы уже
сто триллионов миллиардов лет проживаю на триллионах и
триллионах таких же планет, как эта Земля, мне этот мир абсолютно
понятен, и я здесь ищу только одного - покоя, умиротворения и
вот этой гармонии, от слияния с бесконечно вечным, от созерцания
великого фрактального подобия и от вот этого замечательного всеединства
существа, бесконечно вечного, куда ни посмотри, хоть вглубь - бесконечно
малое, хоть ввысь - бесконечное большое, понимаешь? А ты мне опять со
своим вот этим, иди суетись дальше, это твоё распределение, это
твой путь и твой горизонт познания и ощущения твоей природы, он
несоизмеримо мелок по сравнению с моим, понимаешь?
По теме все и так очевидно а вот зачем солнечные очки в пасмурную погоду?
фотохромные линзы с диоптриями
@@t0digital почитал, не знал что они темнеют и в облачную погоду из-за ультрафиолета.
Приятно осознавать что человек многого достигший в программировании периодически возвращается к земле.. и делится своими наблюдениями ❤
А чего такого многого в программировании он достиг?
@@Amigun_yo
предположу что он выучил много букаф и цифер, а особенно повеведие нуля и единички.. то есть как они живут в нутри компуктера.. ну там ещё монитор и пару кондёров, резистор и видеокарта .. в которой танчики стреляют пиу пиу, вот вроде бы и всё..
@@ataki2023 погоди-погоди, ты на чьей стороне?)
@@Amigun_yo я по середине 🤣
czcams.com/video/kpog6Beq6oE/video.htmlfeature=shared
Коллега какое-то время меня упрекал за то, что я разделяю методы на более маленькие, говорил, что я убиваю так производительность, потому что он читал, что вызов методы сжирает целый ТАКТ! Трагедия великая, убедить я коллегу смог в обратном далеко не сразу, пришлось его заставить прочитать книжку, только после этого он перестал меня в подобном упрекать.
Книга не Мартина, две книжки от O'REILLY, Head First Паттерны проектирования и Head First Java для чайников.
Иногда он пишет мне с различными вопросами по паттернам, а когда я ему привожу некий пример улучшения слышу: "Я если честно книге больше верю". Интересно, что будет, если он прочтёт книги Мартина, наверное вообще мне писать перестанет :))
@electrikkk Вероятно, не знает. Мы с ним работаем с Java и тут о работе компилятора почти ничего не знаем, так как используем готовые системы для сборки. Хотя очевидно разобраться стоит, спасибо за мыслю!
@electrikkk Верю. Я просто не уверен, что это так в Java. По запросу "PGO Java" гугл выдает очень скудный объем информации
Тема интересная, я думаю что на проблему надо бы обратить внимание разработчикам компиляторов и интерпретаторов и на этом уровне провести оптимизацию под нужны "чистого кода". Насколько я понял сама проблема в том, что происходит напластение абстракций над абстракциями плюс наследования и прочие задачи полиморфизма.
не совсем, там проблемы в другом, современные процессоры абсолютное ... - набор оптимизаций создающих собственные бутылочные горлышки для обхода существующих ... и чтобы код "работал", не обязательно быстро, нужно учитывать взаимное влияние всех наворотов интел или интел, кэша и объема доступной памяти, оптимизации доставки патчей иногента-виндоус, и сутенеров-создателей тормознейших серверных инфраструктур. нет, не говорю, что компиляторы не стоит развивать, просто они не могут решить проблему нехватки кэша, смены сервера, и т.д. Компиляторы только могут попытаться эффективнее использовать доступные в кэшах данные, выбирая из предложенных встроенных в компилятор оптимизаций. но ролик был про питошку, он вообще не совсем компилятор, и ему бы больше подошел даже не ява-процессор (древние АРМ), а еще более древние ЛИСП-процессора.
Уволили, а отметить изменения нельзя, получается это контору уволить надо за такой подход
даже неатишник т.е. я проникся. ибо общий принцип понятен
"Вся отрасль веб разработки..." "Там циклы процессора никто не считает". Дак стойте. Веб-разработка же давно уже просочилась в натив: с этим замечательным electron и реакт нейтивом и иже с ними. Вот атом хейтили, vscode хейтят, и вот собственно "за что?", а за производительность
Так вот, не надо всё это экстраполировать на всё. Вот вы правильно сказали, большая часть задержки в веб сервисах из-за ожиданий ввода-вывода. А вот тейк про "бутылочное горлышко" не всегда применимо и часто повторяете "такты процессора"-"такты процессора", но ведь в обсуждении не о тактах процессора шла речь (они-то лишь показатели измерения, а не причина). Вот пример приведённый виндертоном: вычисление площади фигур. Тут-то проблема не в тактах процессора, а в излишней загромождённости для реализации интерфейсов и в излишней модульности: ("чистый код") функции вычисления разбросаны по программе и в объектах лишние чтения виртуальной таблицы, что очень плохо сказывается на производительность с точки зрения кеша; ("быстрый" код) когда-как можно запихнуть все формулы в одну функцию (в памяти относительно недалеко будет весь код находиться, что с большей вероятностью попадёт в одну страницу кеша) и понадобится всего лишь пара переменных в куче, что даже количество обращений в сам кеш значительно уменьшит
В итоге получаем не _[(подгрузка в кеш объекта), чтение vtable из кеша, прыжок, (подгрузка в кеш функции), вычисление площади]_ за каждый запрос (это если обращений в вычислении площади не сортированы по типам фигур), а _[(подгрузка в кеш переменной), условный прыжок, вычисление],_ и если эти параметры фигур находятся недалеко друг от друга (особенно если хранятся как массив), то и подгрузка в кеш переменной будет произходить очень редко (только по выходу из страницы следующая подгрузится). И вы наверное знаете что подгрузка из оперативной памяти в кеш в данном случае самая долгая операция, что в десятки раз замедляет тривиальное вычисление площади
Так-что дробите по модулям в разумных размерах, без фанатизма на атомарные операции
> Так вот, не надо всё это экстраполировать на всё
Мы этим и не занимаемся 17:55
Нужно ли дробить ради того, чтобы дробить? Нет, не нужно - нужно включать голову, это по дефолту. Нужно ли не использовать полиморфизм, потому что это в рамках всей системы даст замедление на 0.00005%? Нет, не нужно. Нужно ли писать код для человека, а не компьютера? Нужно. Нужно ли писать понятный читаемый код? Нужно. Нужно ли заниматься преждевременной оптимизацией (вот тут мы не будем использовать ООП, потому что это неэффективно)? Нет, не нужно.
и это мы еще не трогали геймдев....
VSCode разве медленный? У меня даже на 10-летних компах очень быстро работал. А вот что тормозило, это софт от JetBrains на Java.
Отлично разобрал.
спасибо!
Зачем очки, если пасмурно?
Фотохромные линзы с диоптриями
Оптимизация под процессоры не так уж страшна. На таких языках, как Ада и Delphi, можно использовать пользовательские перечисления, и эти перечисления использовать как индекс массива. В более примитивных языках программирования, где массивы только цифрами нумеруются, там да, там то же самое выглядит как низкоуровневые заморочки
переписываем всё на Ада! Завтра после обеда:)
@@t0digital Переписывание постоянно происходит, ведь куда-то улетучились Win32 exe с GDI, а стали веб-сервера
win32 exe вроде живы пыхтят-работают, не переписали их на ада)
@@t0digital Я продолжал начатое другим разработчиком переписывание с PHP на C++, именно из-за проблем с производительностью. Стало получше, но не настолько, как хотелось. Упёрлись в то, что у прошлого разработчика был юникс головного мозга, и он сервер ортодоксально сделал по архитектуре accept-fork, а через fork-нутые процессы сложно, почти невозможно, разделять подключения к БД, и на каждое подключение к веб было нужно новое свежее подключение к БД, которое долгое, и это всё отравляло. А вот PHP-то подключения разделял. Переделать C++ сервер с процессов на потоки было сложно, там подразумевалось, что каждый процесс живёт в отдельной виртуальной памяти, модифицирует всё что ни попадя. Новый адский сервер я сразу делал как надо, многопоточный, а не многопроцессный.
На текущей работе задолбались с Питоном. Коллеги новую версию одного из серверов написали на Delphi. Ещё один новый, в смысле, не имеющий аналогов, сервер уже на Delphi изначально делал. Постоянно что-то кипит, заменяется, есть окно возможностей улучшить стек
Да там тесты у Муратори такие, что он очень простую функцию обернул в два класса и говорит, что в 15 раз перфоманс упал. Вот если бы он попробовал 2 больших проекта написать в двух разных стилях, он бы тогда понял, что влияние абстракций будет уже не таким значительным. Я вангую, что там максимум 50% можно наскрести с оверхеда, но никак не 1500%. Наверное, у господина Муратори много свободного времени, пусть напишет более приближенный к реальной жизни бенчмарк, тогда и поговорим)
да даже 50% в общем случае не наскрести - если реальное приложение с базой и пачкой SQL-запросов
Однозначно согласен с вами, Алексей, проблемы нужно искать не в чистом декомпозированном коде, а в непроизводительных внешних сервисах. А упоминания термина bottleneck мне очень понравилось!
Ах да! Соскучился по вам! Возвращайтесь сюды почаще, пожалуйста
@@fatoldhikki4837 Да, есть! Криворукие программисты. Да и не забывайте, что вы пишете не на чистом (истинном) машинном коде, а на приятненькой обёртке, которая сделана для нас, чтобы наши программистские ручонки не дрожали, вводя инструкции, или того хуже, байты! Любой язык программирования вносит свою лепту в производительность. И если вы допускаете это, то допускать можно. Хотя нет, нужно! Нужно допускать другие подходы к программированию, облегчающие написание, как, например, подходы, описанные в книжках дядюшкой Бобом.
Преждевременная СОЛИДезация - корень зла
В принципе странно лезть в темы оптимизации с точки зрения питона. Если используется питон или, например, жаба, то энивей лучше клинкодить, чем упарываться в производительность. А вот если делаешь какой-нибудь анриал энджин на плюсах, то лучше уж нечитаемые сорцы, чем вот это вот все.
В недрах ms сделали кеш с поддержкой redis протокола. Анонсировали, что написан на шарпах.
Выкатили его в опенсорс.
Работает ОЧЕНЬ быстро.
Но исходники... практически один сплошной unsafe. Развитие и поддержка такого кода очень и очень дорогая.
@@andrewbondaryuk так могут себе позволить. Они создали конкурентное преимущество ценой дополнительных вложений в разработку и поддержку, бизнес примерно так обычно и работает.
Адекватность рулит
Все вы говорите о поддерживаемости, читаемости кода и т.п. Но это важно только для человека. Если ваш код не пишет человек - тогда чистый код не так важен(вобще насрать).
p.s. пишу уже полтора месяца исключительно нейронкой. Главное - качественное покрытие тестами. Переписать заново то, что покрыто тестами занимает минимальное количество времени и усилий.
Тогда пусть нейронка сразу асм пишет. Эффективненько и пофик на читаемость.
@@t0digital Вы просто не умеете читать!
То, что вы не умеете читать asm ещё не означает, что код написанный на asm нечитаемый.
Зачем вы пытаетесь меня задеть, друг мой)? Читаемость ASM и читаемость современного высокоуровневого ЯП - разные, будете спорить)?
@@t0digital Совершенно не хотел вас задеть или обидеть чем-то. Просто для некоторых код, написанный на asm читать легче чем на современных высокоуровневых ЯП. Кто-то вообще знает только asm. Кстати нейронка очень неплохо пишет на asm.
@@t0digital Вы меня совсем не поняли. Мой посыл в том, что эпоха "пишем ручками" уходит. Приходит новая. Декларируем требования и проверяем результат. Мне было по-началу очень непривычно... И после многих лет следования принципам чистого кода я оказался не готов к такому подходу к работе. Я привык, что все о чем писал дядя Боб очень полезно и очень помогает. Но начав писать нейронкой я внезапно осознал что все это не важно. Важен лишь результат и скорость его достижения. В итоге ты пишешь тесты (той же нейронкой). Затем пишешь фичи (опять нейронкой). Потом просто запускаешь итеративный авто-дебаг. Нейронка сама ловит ошибки, сама вносит исправления в исходники. Ты лишь отслеживаешь показатели производительности и корректируешь промпт. Все. За день, два у тебя готовая, протестированная фича.
Самое же важное - что обратную связь ты получаешь так же быстро. И тут Agile начинает играть совершенно другими красками. Выходит очень гибкий продукт. Готовый к любым изменениям/переделкам и прочее.
Автор передёргивает. Весь спич был про то, что на оптимизацию совсем внимания не обращают. Разнца в производительности в 15 раз это много. А так получается и диски быстрые и памяти полно и процессор в n раз быстрее, а SQL запрос по времени одинаково выполняется...
> Весь спич был про то, что на оптимизацию совсем внимания не обращают.
Это вы передергиваете. Автор говорит о том, что не обязательно писать всё на ASM с оглядкой на такты процессора 15:39
@@t0digital Теперь-то да, потому, как лет 15 уже на это не смотрят и какой продукт ни возьми, он не оптимизирован изначально. Соответственно, приложуху уже нет смысла вылизывать.
@@user-ge7lt5nm8x жизнь боль ага
видео в 2 словах: "я работаю наотъебись, как и все здесь"
Если вы не пишете на ASM свою ОС для своего софта - то вы тоже работаете на отъебись
@@t0digital хорошо, что вы сами это понимаете, первый шаг сделан, браво!
@@user-re2rh3wt3k 🤦♂️
А почему все программисты любят эти ужасные очки хамелеоны? Это так по задротски. По теме видео - полностью согласен с автором.
Потому что мы задроты, ёпта!