Инцидент, Который Создал Шум Во Всей IT Сфере

Привет!

Научись создавать нейросети:
Скидка 50% по промокоду TONKA
+курс по софт скилам в подарок

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Упомянутое в видео:
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Подпишись сюда:

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Музыка:

SLYNK из фри библиотеки ютюба

00:00 Введение
01:10 Начало "конца"
02:01 Особенности чистого кода
04:25 Бонуска
05:23 Инцидент, который изменил вектор IT
08:20 Король пришел на защиту, но провалился
11:40 Нас с Вами просят решить судьбу ситуации

[wndtn]

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

[MrMirovingin]

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

[tonytaponi]

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

[sokolanov]

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

[kofiy]

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

[demo_life_player]

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

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

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

[ViktorYakunin]

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

[Manellig]

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

[rostickevo]

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

[AlexQuidditch]

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

[kniazew_daniil]

Вообще-то все зависит от конкретной задачи.
Если мы видим, что какой-то кусок кода выполняется раз в 2 часа и его выполнение занимает не 100 наносекунд, а 250 (из-за чистого кода), то ускорять нам ничего и не надо. Он прозрачен и в нем нет ошибок.

Если же код выполняется каждые раз, то тут уже не до красоты. Фигачим отдельный класс FastMaker в котором будут и свитчи и использование всяких AVX инструкций и вычисление на GPU и asm вставки.

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

[drgluck]

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

[petrpetrovski]

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

[OldHame]

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

[o.l.k.s.n]

Я когда смотрел оригинальное видео то не мог понять: он то ли троллит, то ли серьёзно. Дональд Кнут когда-то сказал: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: *premature optimization is the root of all evil*. Yet we should not pass up our opportunities in that critical 3%."

Именно эту ошибку Кейси по сути и сделал. Для начала он выдаёт за неоспоримый и ничем не подтверждённый факт, что "все современные приложения написанные по чистому коду вызывают пачками полиморфные функции миллионами в секунду и поэтому тормозят в десятки раз". И нам надо принимать это как истину не требующую каких либо подтверждений. Так он в буквальном смысле создал "чучело врага" и будет его громить. В качестве подтверждения своей теории, он не показывает проблему в реальных приложениях, а он берёт *абстрактный кусок полиморфного кода* и запускает его в цикле на миллион (1048576) итераций как бы подразумевая, что так в реальных приложениях всё и работает. Затем он делает оптимизацию этого кода и показывает, что оптимизированный работает в 10 раз быстрей и делает вывод: ваш clean code — фигня и *все приложения* тормозят в десятки раз. Таким образом делая одно допущение за другим он в итоге решает абстрактную проблему и оптимизирует не реально тормозящий код из реального приложения, а "нечто", что вероятно в реальных приложениях и не вызывается миллионы-миллионы раз в секунду, а потому и не является реальной проблемой. Это то самое зло от преждевременной оптимизации: мы имеем соптимизированную абстрактную проблему, а не реальную. У меня сразу была куча вопросов к его видео вроде: почему при наличии современных мощных профилировщиков никто в индустрии не говорит о тормозящем полиморфизме, а говорят в основном о других проблемах в производительности (память, кэш, i/o)?

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

[roman]

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

[stasuchuvadov]

Клинкод дает одну особенность, которую не дает подход кейси: расширяемость

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

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

[sidek]

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

[YmNIKYm]

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

[kittenlord]

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

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

И даже так, как по мне, комфорт программистов не стоит того, чтобы у конечного пользователя 30 секунд грузился ГУИ из-за 10 слоев абстракций