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

Чистый код - быстрый код.

SOLID - это когда код написан одним большим куском!😄

Просто не надо cleancode-ово писать на С++ и прочих языках низкого уровня. Берём какой-нибудь zero-cost abstractions-язык уровня Rust, и внезапно писать «чистый код» и приятнее, и эффективнее. «Прятанье» особенностей реализации, например, вообще основной способ развязывания компилятору рук, точно объясняя, что можно выкидывать подчистую и инлайнить.

"всё останется на своих местах" - это возможно немного наивно. Как по мне, это была первая ласточка. Именно оттого что в индустрии работают люди с мозгами, они не могли не заметить какие отвратительные тенденции развиваются в качестве мейнстрима кодинга. И когда кто то первый начал говорить о том, что король то голый, - плотину начало рвать. Я думаю мы на пороге возвращения программирования к здравомыслию. Плотину еще не прорвало. Этот геологический процесс займет некоторое время. Но как по мне это неизбежно. Ну вы только представьте, какое количество этапов интерпретации придется проделать последовательно нескольким вычислительным устройствам чтобы просто показать потребителю страничку. Похоже программистскому сообществу забыли сообщить, что закон Мура почил в бозе, и сейчас уже не нужно придумывать новые уровни бессмысленной загрузки, чтобы помочь производителям железа в создании спроса на всё более производительные устройства.

Я пока смотрел стоял на месте?) а мне кажется двигался вперед)

А я учу abs pascal 👍

А знаете, из-за чего появляется по-настоящему фиговая производительность в больших проектах? Из-за того что один программист наоптимизировал всё, влепил внутри одной функции, а другой вызвал эту оптимизированную под 1 задачу функцию в немного другой задаче, где половина этих операций совсем не нужна. От того, что люди пишут не очень чистый код, другие просто их не понимают полностью и ломают производительность ещё больше, чем если бы код был чистым.

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

Вообще, я знаю одного айтишника, который ушел в инженеры, потому что "в айти нет гостов". Как мне кажется, здесь нужен новый подход, т.к. представленные варианты здесь это лишь части целого. Оптимизация это хорошо. Но если после оптимизации ты это не сможешь менять, а другой не сможет прочитать то это тоже вызывает вопросы. Сам не айтишник, могу и ошибаться.

Программисты из 2000х хорошо знаю сколько занимает int в памяти языка Си, и по этому писать громоздкие структуры для манипуляции с данными, которые еле ворочаются создавать не любят, но тенденция такова - владельцы компаний редко обладают достаточным уровнем знаний что бы адекватно оценивать необходимость использования "чистого когда" и требуют это потому что так модно и делают все, а потом удивляются когда огромные сервера греются над простыми задачами :) Кстати эту тему можно продолжить фреймфорками, которые сжирают еще 90% производительности поскольку используют clean code в степени, безусловно ускоряют разработку, увеличиваются зависимость от внешних библиотек, и раздувают размер приложения от 100 кб до 4 гб

За проблемы с производительностью платит пользователь, разработчикам на них срать. Просто скажут купить железо пожирнее.

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

Вопрос по-приколу. А Кейси вообще выключил отладочные флаги в компиляторе и включил оптимизацию? Ну или компилятор нормальный хоть использовал? А если серьёзно - большие сомнения в том, что он умеет правильно готовить. Это точно так же, как сегодня считают, что скрам себя не оправдал / мы-используем-"модифицированный-скрам" и т.д. А по-факту - скрам работает только тогда, когда все его пункты соблюдаются и соблюдаются исключительно так, как задумано. Нет ретро? Всё, не трындите, что скрам не работает. На ретро спрашиваете, что было плохо? Это не скрам, не нойте тогда, что скрам не работает. Команда "внезапно" завершила задачи раньше времени и вы срочно взяли ещё задач из бэклога (ну, чтобы хотя-бы начать сейчас) - это не скрам. Не нойте тогда. Примерно так же и с Clean code. Например, если простота для вас означает быстроту (быстро нафигачить) - это не Clean code. Над простотой нужно думать. Если родительский класс используется как инструмент, который предоставляет функции для удобства наследников - это не Clean code. Ну и так далее. А некоторые даже не знают, что такое volatile. И таки Rectangle/Circle, как и Vehicle/Car/Truck-has-6wheels - очень тупые примеры, это как не надо учить новичков ООП, а у остальных вызывает усмешку. И таки, неумение использовать алгоритмы, например, искать в ожидаемо больших списках с помощью if-else или switch-case внутри - не поможет и без Clean code. И таки, если в новом Diablo4 наг*внокодили так, что из-за цикла отрисовки игра может пропустить нажатие клавиш, (если её не удерживать нажатой, пока не начнётся хоть какая реакция), а плоское 2-мерное меню загружается несколько секунд, то явно тут не в Clean Code проблема, а в руках из ж*пы (может картинка менюшки в 2Гб 64битного цвета, а клавиатуру не слушают постоянно, а опрашивают раз после всей отрисовки, или передают всё на сервер по интернету и скачивают гигантского размера результаты, когда можно было сделать локально или оптимизировать размеры передачи. А вообще - стоит ещё посмотреть в сторону - сколько человек может удерживать в голове объектов. Кто-то может 5, кто-то аж 7. В завершение. Когда-то я по-дури думал, что напишу код на ассемблере лучше, чем это сделает компилятор на C++. Long-story-short: При выставленных оптимизациях, мой код получился аж на целых 2 байта короче, но по замерам скорости - медленнее. Потому что я плохо представлял как некоторые команды могут быть автоматически распараллелены. Что теперь? Должен ли я упорствовать в изучении особенностей машинного кода всех микропроцессоров, микроконтроллеров? Чтобы что? Чтобы написать такой же быстрый код, как делает компилятор с оптимизациями? И чтобы что? Сказать, что это всё баловство с Clean code, да и вообще, с языками выше ассемблера - отстой? Допустим. Кто ещё готов положить жизнь на гонку за знаниями по каждому выпускаемому микропроцессору и чтобы писать простенькие вещи за большое количество времени?

автор не понял Open-Closed Principle, но рассказывает про него...

Просто читаемый код сделать производительным проще, чем производительный - читаемым. Да и конфликты в гите реже и их решать проще, когда все разложено на массу мелких кусочков.

=D Как то давно, когда мне было интересно играть в игры, и даже было очень интересно что-то менять, мне достался код одного мода, для гта са мультиплеер (samp). И так сложилось, что сервер, на котором крутился этот мод, перестал работать, а программист, что его поддерживал, по какой-то причине стал не доступен. И зная меня, админы обратились ко мне. Я НЕ ПРОГРАММИСТ (от слова - ВООБЩЕ, да, конечно, я когда-то очень давно, учился, и в том числе меня сдавал и программирование калькулятора, и корветы, но если вы хоть, чуть чуть в теме, то поймете, когда еще были корветы, а когда samp). Но помочь, все равно было надо. Так или иначе я смог послать скомпилированный мод. Потом так или иначе дописал, то что чего в моей версии кода, еще не написал программист, а на сервере уже было. Втянулся. Начал городить свой огород в том моде. Делать новые функции и воплощать новые игровые механики. Но, со временем, нашелся хороший программист, с которым я потом смог скооперироваться. Но суть всего этого текста, о чистоте кода. =DDDD Программист (с которым я сдружился, и даже потом не раз пили пиво, хотя я из Питера, а он из Калининграда), ОЧЕНЬ СИЛЬНО ПРОСИЛ - НЕ ПИШИ БОЛЬШЕ НИЧЕГО! Дааааа... хорошее было время. ВСЕМ ДОБРА!

С вычислением площади в "оптимизированном" коде - хрень, которая посыпется сразу-же как только захотим добавить сложные фигуры. И, ведь, очевидно же что захотим. Например, добавить эллипс. Или сегмент круга/эллипса.

Клинкод для дешёвых программистов, туповатых таких. Но в менеджменте айти выведена ещё одна формула: дорогими программистами работать дешевле. И все эти дорогие программисты не нуждаются в этих ограничителях. Им даже Дейкстровые скобочки не нужны и go to для них это инструмент для упрощения кода и повышения производительности. А если кодер ткпой как дрова и с самомнением мол я в фейсбуке работаю, то да, клинкод и расширенный бюджет раза в два.

Все эти клинкодщики впухают когда пробуют написать какой-нибудь вычислительный шейдер.

Я знал! Я знал!! Только никому доказать не мог.

Био книга вонючая

ещё новые студии собирают более тяжелые приложения по весу нежели старые

А ещё сейчас не камельфо инджектить через сетеры. Это сейчас делают через конструкторы. Но и их писать не нужно. Ломбоком делаем или "AllFields" конструктор или "RequaredFields" (только final поля), а спринг уже давно умеет сам понимать что инжектить в конструктор без написания аннотаций (косяк с множеством бинов одного типа, но гугл в помощь). Итого: нету болерплейта + всё круто по бест практис.

Аннотацию Data нельзя юзать для Entity, потому что тот equals и hashCode что она генерит, включает поле id. А если у вас генерация оного на стороне БД или Hibernate могут всплыть проблемы c приколами кеша Hibernate и состояниями Entity. Да самого тупого CRUD и простых Entity всё работать будет, но на корпоративных проектах, где Java чаще и используется, или вам ввалят звиздюлей, или вы сами себе сделаете очень больно.

Excuse me! How old are you?

6:20 Comment be later. UPD: Excuse me! How old are you?

С точки зрения работы ПО, 90% кода работают в редких случаях, допустим раз в день, месяц, год, а 10% кода программы отрабатывают постоянно в бесконечном цикле. Так, может тогда, на B-версии программы отпрофайлить наиболее нагруженные участки и переписать их без виртуальных функций, полиморфизма и подобного. - а 90% оставить в нормальном удобном виде.

Дядя Боб всё верно написал! Оптимизация не должна наступать на читаемость, потому что потеря читаемости в дальнейшем приведёт к падению оптимизации. Оптимизацию должны выполнять компиляторы, на уровне asm нет никакого полиморфизма, только jmp.

Ребята, вам вешают лапшу на уши. Программирование связано с математикой не косвенно, а напрямую, потому что компьютер - это дискретная система. Без дискретной математики ты никогда НЕ ПОЙМЕШЬ алгоритмы, ты сможешь применять их только как мартышка очки, потому что ты просто не понимаешь их. Теория графов тоже останется темным лесом, потому что это часть дискретной математики.

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

Не программист, но уже несколько лет твержу одну вещь. Что все коды написаны ведь людьми, что нельзя забывать НИ В КОЕМ СЛУЧАЕ. А раз это так, а также учитываем то, в каком мире мы живём. Где нас с пелёнок окружает враньё, и это длиться всю жизнь и эти масштабы невероятно катастрофически. То нужно понимать, что тот кто написал код, также и скрыл что то, для общих мас. Пример, который вас приведёт в недоумение, особенно тех, кто привык смотреть ролики ЮТ про железо, да про чТО УГОДНО, на самом деле и при этом, полагается на порядочность тех, кого смотрит-слушает. Так вот! Никакого развития железа по ПК мощности уже нет много лет!!! Те же процессоры XEON от INTEL, которым уже не меньше 10-15 лет, как минимум, ни чем не хуже по мощности, чем современные процессоры. Разница лишь в одном!! Код, который прописан в программах, играх и т.п. и т.д.!!! Да, да! Те ядра, которые требуют от Вас современные игры или программы, а ОСОБЕННО ОС)операционная система)это код, написанный человеком. Применяет то, что написано ранее и чуть выше и получается то, что умышленно, создаётся видимость того, что есть какой то прогресс или же вам к примеру нужно терабайты памяти для хранения данных или скачивания и установки игры! Опять же пример. На примере игр, лучше будет. Так вот! Выходила игра от крупных издателей, лет 10-15 назад, не больше, где помимо качественных текстур, было множество разных вещей, которое занимало место на диске. При этом, игры тех времён, помимо насыщенности игрового мира , имела куда более деталей ЗА ПРЕДЕЛАМИ КАРТЫ. ДА!!! За пределами карты, были ПОЛНОЦЕННЫЕ текстуры! При этом, вместимость всех этих файлом, занимала к примеру 30-40 гигабайт на диске. И это не забываем при том, что сама карта в игре, по масштабам не уступала современным якобы играм! Так вот, спустя время, выходит ЯКОБЫ современная игра, где всего лишь с помощью фильтра, улучшили детализацию, а также поиграли с освещением(кстати этой уловкой, больше всего грешат ЕА, они же electronic Arts). Но при этом, на карте куда меньше деталей, и что самое главное. за пределами карты, нет НИЧЕГО, эта местность пустая. И в лучшем случае, есть просто макеты. Но при этом, с просторов ЮТ и так званых лидеров "мнений", звучат фразы, мол то что игра имеет вместимость 100 гигабайт, это нормально, ведь она же современная. И в этом предложении, есть только ОДНО, ЕДИНСТВЕННОЕ слово, которое правдиво. И это слово, "СОВРЕМЕННАЯ". Потому что когда используют это слово, вы должны сразу понимать и ОСОЗНАВАТь что Вас(меня также) тупо пытаются обмануть! Не стесняясь!!! Не краснея!!! Без стыда и совести!!! В тупую! Так вот, как это всё, касается процессоров. Да всё очень просто. На самом деле,в се мы можем сидеть на двух ядерных процессорах и с двумя потоками если хотите и не парится что у НАС, что то будет не работать, глючить, зависать и т.п. и т.д.!!! Да, да! И всё делов "кирпичах", которые лежат в ОС, потом в программах, кому так понятнее то софте, в играх. т.д. Поэтому пожалуйста. ЛЮДИ, не забывайте то, в каком мире лжи , мы живём. И какие ценности у этого мира! P.s. Забыл!!! Дописываю, нажав на кнопку изменить комментарий!! Так вот!!!! Да, да! В конце ролика, вспомнилась приславутая компания ЕА!!! Так вот!!! Эта компания, ЕА, наверное самая первая. начала применять то, что её программисты, начали програмно уничтожать процессора и их производительность в играх, выпуская патчи, о которых ни где не упоминается, но пр этом к примеру ваш процессор работал максимум на 40-60 % нагрузки, а потом бац и в один день ваш процессор имеет уже нагрузки 90-100%. Да. да , это не шутки. Потом этим занялась компания ЮБИСОФТ. Потому что все они знают, что люди невнимательны, зачастую. Да и плюс знают то, что остануться безнаказанными До сих пор помню все эти моменты и главное когда и как это происходило!!!

Любой маломальски практикующий программист поймет эту проблему, сравнив высокоуровневый язык с ассемблером. Главное не злоупотреблять и использовать все по необходимости.

23 год - шмяндекс - это кто?

Свитчи вообще капец какие быстрые. Крч вывод - не бросаться в крайности 😅

Нужно судить не по корпоративному уровню траты времени сотрудников, а по общему времени ввыполнения программы на конце пользователей, а то получается так что время программиста стоит на несколько десятков порядков больше, чем общее время потраченное в конце. Нельзя экономить, можно экономить на ком-то или чём-то. Экономя тысячу человекочасов во время разработки, мы тратим дополнительный миллион заставляя пользователей ждать. А так-же получается экспотенциальный каскад, когда пользователем программы является сам программист, в случае ОС, сред разработки, компиляторов, т.д. т.п. Рано или поздно мы достигним ситуации когда сэкономленное время на написание кода в прошлом невилируется повышенным временем выполнения программ, и я уверен мы уже близки к этой точке.

Посмотрел видос и понял что да, это как рассуждать наполовину полон или пуст скатан, но я для себя clean code представляю как способ сведения этой разности в мнениях к минимуму. Вместо того чтобы говорить что стака наполовину полон или пуст лучше сказать "В стакане воды столько что уровень воды находится по середине": информации больше но под это подходит и то и другое мнение

что значит "базированный разработчик"? За видео спасибо, так клево еще никто не расписывал профессии в IT

Почему нельзя создать один язык (универсальный, которым можно заменить все языки программирования)? Вера не позволяет? Скорее всего он уже создан в Microsoft и он успешно им пользуется. Не зря же кроме Америки не кто не создал не операционной системы, не языка программирования (качественного. Все разпространеные языки программирования и операционные системы созданны именно американцами, в Microsoft), а если кто-то и создал что-то, то это как правило убожество посравнению с продукцией Microsoft. Возникает вопрос, почему такой плохой софт? Наверное все нации, кроме американцев, дебилы? Мало вероятно. Быстрее всего Microsoft пользуется универсальным языком программирования. Возможно, есть альтернатива, но в ней есть несколько минусов. Хотя и в универсальном языке есть недостатки, но они перекрываются возможностью создания языков и операционных систем на высоком уровне, не доступным другим способом. И кстати, может быть, автор заинтересован, чтобы не кто не интересовался универсальным языком программирования. Только не понятно, с выгодой для себя (что-то получая от Microsoft), или его используют в тёмную (внушили ему, что универсальный язык это плохо и он как попугай повторяет).

Вся ценность этого видео в том, что нельзя просто взять и применить какие-то принципы и получить оптимальное для данной задачи решение. Всегда приходится думать.

Clean Code вещь объективная, а не субъективная. Но её трудно измерить поскольку это величина со многими переменными, для которых часто отсутствуют простые критерии оценки их оптимальности. Тем не менее это не значит, что их не существует. Например, оценивая оптимальность стиля оформления кода программы, можно и нужно принимать во внимание психо-физические особенности зрения. В данном случае столкнулись две крайности, ни одна из которых, взятая отдельно, не может претендовать на право быть абсолютной истиной. Кейси прицепился к примеру, который показывал не то, как надо программировать расчет фигур, а как использовать некоторые принципы Clean Code. Он мог бы с таким же успехом написать его на чистом Си, и вполне возможно, получил бы еще более простой код, и мог бы заявить, что С++ не нужен (в чем лично я, наверно, готов был бы с ним согласиться). Эти принципы находятся на совершенно другом уровне абстракции, там где нет циклов процессора. Очевидно, что принципы CC были выработаны как результат опыта разработки больших программных систем с длительным сроком жизни, и их ценность возрастает по мере роста сложности разрабатываемого программного обеспечения. И это именно принципы, а не догмы, они не абсолютны. Они помогают принять решение относительно архитектуры ПО, но насколько правильным будет это решение в конечном итоге зависит от того, понимают ли разработчики, в чем смысл данного принципа, и какая цена его использования. Думаю, что Боб сдался только потому, что Кейси моложе и энергичнее, а Боб уже фактически на пенсии и многое забыл.

Вообще не понимаю, о чем спор. Если требуется производительность, то пишут на ассемблере. Если требуется низкая стоимость разработки, пишут спагетти-код (из примеров Кейси). Если требуется низкая стоимость владения кодом, то пишут с использованием ООП (из примеров Боба). То, что Кейси нашел несколько частных случаев и в качестве доказательства привел тесты в одной конкретной среде разработки, можно использовать только для оценки качества среды разработки

Кто знает, подскажите про восьмибитку :D А автор - лови подписку 👍

Все гораздо проще. Чтобы оценить книгу, надо обратить внимание на опыт работы автора программистом и какой код он написал. Страуструп рисовал фонты, а значит придумать нормальный язык программирования он не мог по поределению. В итоге мы имеем хрень, которая позволят многочисленными способами сделать одно и то же с максимальным количеством багов. Где работает Мартин Роберт и что из написанного используется до сих пор? Он бросил разработку ( а там платят больше) и занялся "разводом лохов" на языке уже кем то придуманном. Единственный подход, который я поддержу, это DRY. Все остальные абстракции, преждевременные архитектуры и прочие танцы с бубном ведут к кривому кодированию и багам. Любая абстракция необходима только если код начинает повторяться и чтобы этого избежать вводится абстракция. Если код не повторяется, никакие абстрации или архитектура не должны присутсвовать. Что касается виртуализации, легко проверяемый метод - циклический вызов виртуального и обычного метода с замеров времени. Виртуальный вызов в 2 раза дольше обычного + на виртуальном процессор может потерять предсказание переходов о опуститься к производительности одноядерной системы. Про многопоточность C++ и говорить не приходится, там вообще мрак.

Я выбираю клин код. Почему? Работал с кодом, где были свитчи на 200+ кейсов + повторяемость кода. Это просто очень тяжело поддерживать и увеличивается кол-во ошибок. Оптимизировать можно в других местах, например, просмотреть свои запросы к БД, чтобы возвращать 100 записей, а не миллион. А если порассуждать, то и со свичами не все так гладко. Если свичей будет много и код должен пойти к самому последнему, что тоже не так уж быстро (перебор всех вариантов). С другой стороны, полиморфизм это всего лишь вычисление адреса функции, который по большей части реализован на кристале процессора. Так что, не все так однозначно. На 3-х кейсах код будет быстрее, на 300 - не факт.

Мартин - чувак, который понимает что программирование - это про людей, а не про железяки. Вот и вся разница.

Я клин код никогда не понимал, на C# сталкивался с нюансами и меня реально бесило когда по "чистому коду" я должен был написать 20 строк кода, и мозг взорвать при этом, и все предлагали именно такое решение, но я нашел обходное решение в 3 строчки кода, да еще и на много быстрее... Абсолютно согласен про замедлениемкода в 20 раз, если посмотреть как внутри устроен тот же excell, то это просто пи.... к примеру у меня свой софт и он весь код генерит к примеру за 1 сек, а вот перевод всех этих данных в excell занимает уже 60 сек и так во всем софте написанном последнее время... Я стараюсь никогда не писать по идеалогии клин кода, всегда пишу более просто и быстро

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

Обычно слушаю на двойной, но тут показалось быстровато. Решил включить полуторную. Понял, что ошибся. (В смысле, потому что видео шло на одинарной, к удивлению) Отличная скорость подачи.

Тут глаза начинают слезиться 6:10, работа по найму + ЗП - это реально ловушка, попадая в неё выбраться (особенно если оброс обязательствами) очень непросто.