Пікірлер

• 
  @AsomirL7 минут бұрын

  Надо пилить фичи и двигать таски, нафиг нужен этот ваш перформанс?

• 
  @TheMisterDog14 минут бұрын

  Бизнес как скажет так и будет

• 
  @Filkio42 минут бұрын

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

• 
  @dvl0per46 минут бұрын

  За все фичи повышения производительности не скажу, но вот преимущества switch/case/enum заканчиваются тогда, когда по результатам эксплуатации кода появляется очередной case, под который надо прописать свой enum и добавить в swich. Когда таких case накапливается уже пару десятков со своими под-case, сопровождение кода (исправление ошибок/добавление фич) превращается в АД.

• 
  @experienced-user49 минут бұрын

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

• 
  @CJRimshot10 сағат бұрын

  эмбеддеры на это смотрят со стороны и думают - "они начали о чём-то догадываться"

• 
  @romanmaschak505211 сағат бұрын

  Говнокод побеждает. Его пишут на порядок быстрее клин кода.

• 
  @slaviksemen491912 сағат бұрын

  - ты читал «Война и мир»? - Да - А что там? - Ну там сначала была война а потом Мир… - Спасибо, почитал😥

• 
  @defanji848414 сағат бұрын

  При написании чистой архитектуры, кода приложений надо понимать, что да, это будет медленнее, чем написать тоже самое, но, условно, в одном файле с обьектами для неявных ифов. Вопрос в том, что удобнее? Пример со свитчем очень хороший, потому что по итогу у тебя есть либо много классов, имеющих один метод но с поведением свойственным для конкретного монитора (пример из видео) или один большой свитч, который нужно делить. Имхо, выбор понятен. Надо понимать, что сначала мы пишем код, а потом оптимизируем

• 
  @welran14 сағат бұрын

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

• 
  @MrElectroFelix14 сағат бұрын

  А я вот буквально на днях купил эту книгу)) Ну что же, всё равно нужно прочитать)

• 
  @daspisch16 сағат бұрын

  Вначале видео я такой: почему я пропустил эту всю войну? А потом когда посмотрел видео: так этот умник узнал что если наговнокодить всё в одну мейн функцию будет работать быстрее. Ну и конечно, реклама скиллфпктори это сразу показывает всю профессиональность автора)

• 
  @wndtn14 сағат бұрын

  гениально, не останавливайся

• 
  @FerretNone16 сағат бұрын

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

• 
  @AntiPolarity17 сағат бұрын

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

• 
  @artsiomkazlouski512718 сағат бұрын

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

• 
  @SmenSHik18 сағат бұрын

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

• 
  @asdbanz31619 сағат бұрын

  Я бы сказал, что принципы клин кода полезны, но на более высоких уровнях. И чем позже, тем лучше.

• 
  @VitaliyIvanovv19 сағат бұрын

  Clean code рулит для простых «смертных». Производительность нужна там, где она нужна. Там и уровень разработчиков в разы выше, требования выше, и соответственно деньги другие. Согласен с выводом в этом ролике - все определяется деньгами. Никто не заплатит разработчику х11 за его ускоренный код, если заказчику это не принесет х300 денег.

• 
  @shinryokai19 сағат бұрын

  Гля, а я еще помню, как наши ребята оптимизировали стек 8086, чтобы успевать отслеживать заданное число целей на радаре :)

• 
  @tee-hee20 сағат бұрын

  Клин код - это не свод правил. Хороший программист, имхо, всегда балансирует между god object и soft code. Поэтому все эти архитектуры от лукавого, надо соблюдать дзен.

• 
  @-aris-an21 сағат бұрын

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

• 
  @woeroses21 сағат бұрын

  Поставьте себе скорость речи. Быстро тараторить и потом говорить нормально - очень некомфортно слушать. И скоростью в проигрывателе себе не поможешь т.к. различный темп речи в видео

• 
  @LiveseyMD21 сағат бұрын

  Самое страшное, что я видел в продакшене это HTTP парсер на С++03 в 3000 строк, которой написан с goto назад и проверкой флагов и 7ю вложенными скоупами. Этот код невозможно ни читать, ни дебажить, ни покрыть тестами. Поиск проблемы либо добавление функционала в этом случае требует недель работы и столько же времени на, по сути, ручное тестирование. Наличие большого количества такого кода приводит либо к огромной неэффективности разработки (куча выброшенных денег и сожженного зря электричаства) и может привести к жуткой текучке кадров (год человек учится, ещё год работает, потом уходит). Так что с моей точки зрения, всё должно иметь пределы в обе стороны, но если уметь правильно изолирвать части системы, то можно заниматься их оптимизацией без переписывания всей системы целиком и годовым циклом тестирования, как это было 30 лет назад.

• 
  @pannor420622 сағат бұрын

  Компиляторы!

• 
  @evgeniyp197622 сағат бұрын

  2:15 по идее ж в мат -> мат утил и в физикс физикс утил а то там в матеифизткс и в физиксе мат сейчас

• 
  @Laertid22 сағат бұрын

  Кейси может говорить, что его подход к написанию кода лучше, и он даже может быть прав. Но в этом не будет толку для остального мира, пока этот подход не описан в столь же фундаментальной книге, как Clean Code, чтобы стать учебником для нового поколения. Я думаю, что именно возможности чистематичкой передачи этих знаний в массы ему и не хватило, чтобы оказать серьезное влияние.

• 
  @Tar2ga22 сағат бұрын

  инфоцыган вернулся

• 
  @xah747422 сағат бұрын

  Очень медленно говорит автор, пришлось выкручивать ускорение видео!

• 
  @satepan4ik23 сағат бұрын

  Как это в рекоменд попало не ясно, я вне ut ... Как зомячрк я ша кармака

• 
  @sergelex4403Күн бұрын

  Мне кажется, каждый клин-кодер остаётся им ровно до тех пор, пока не сталкивается с Ultra-Reliable RTOS задачей. Там не просто циклы процессора приходится считать, но и стабильность загрузки этих циклов и т.п. При этом, уже как 10 лет активно развиваются профильные автокомпиляторы, которые пишут по твоей программе абсолютно нечитаемый, но тот самый оптимизированный код. Посмотрим, куда это всё придёт ;)

• 
  @Vladimir-ui3ijКүн бұрын

  Clean Code - это бред, который устарел еще до выхода книги. На самом деле это сборник здравых идей, которым сто лет в обед, который автор объединил в единую парадигму, и вот эта парадигма - не работающий бред. Мало того, что она не продуктивна в плане производительности, так и не выполняет основную свою функцию. Если плодить бессчетное количество сущностей чтобы "чтоб было" или "так правильно" или "а вдруг мы захотим..." вообще ни разу не облегчает поддержку кода. Основные претензии, конечно, к полиморфизму - это узкоспециализированный концепт, который пихают куда ни попадя

• 
  @maxsalov9521Күн бұрын

  Именно циклы процессора и процессорное время стоит экономить, когда пишешь огромный проект. И не важно сколько часов уйдёт у программистов на его проектирование. Если код не читабельный, то это проблема языка, который это разрешает, что и позволяет работать быстрее. Концепция ЯП Rust меня вполне устраивает. Пусть разрабы ЯП управляют тем, как я пишу код, чем изучение 100500 вариантов того, как правильно это делать в зависимости от поставленной задачи.

• 
  @MrGish09Күн бұрын

  От куда вообще могло появиться обсуждение? Читаемость > производительность. А оптимизируем только то, что действительно необходимо. Вообще спор ни о чем.

• 
  @alexserb3845Күн бұрын

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

• 
  @user-mt5jk2ur7pКүн бұрын

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

• 
  @MiCola12Күн бұрын

  Ну блин. КлинКод он для ООП и для прикладных/корпоративных программ. А если вам нужны оптимизация производительности - какой тут нафиг КлинКод? Логично...

• 
  @PSIHoioGКүн бұрын

  Я вообще не программист, но мне было интересно.

• 
  @user-ib4pd3wh1zКүн бұрын

  Для некоторых тяжело найти, то что тебе интересно, поэтому, в том числе и я, встречается проблема, что для того чтобы это понять нужно много перепробовать, но некоторые области в ИТ требуют более углубленного изучения и пока ты переступишь этот входной порог и поймешь, что это твое, часто опускаются руки. Но благодаря таким видосам снова появляется мотивация учиться и не бросать это дело!

• 
  @user-zd7ye1jj2jКүн бұрын

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

• 
  @alexandervasilyev1537Күн бұрын

  Бездарный спор. Если взять любую бизнес-систему любой крупной организации, то узкое горлышко в производительности прочти всегда будет не в back-end-коде, а в скорости БД, в скорости сетевого взаимодействия между серверами, скорости ввода-вывода на дисковую подсистему и тому подобное. Те узкие горлышки, что нахзодятся в коде back-end'а, как правило, достаточно легко устраняются вовсе не избавлением от clean code принципов, а нахождением какой-то просто ошибки либо настройкой.

• 
  @user-uw8hy1lc4pКүн бұрын

  Вообще я за клинкод, кому какое дело на сколько быстро работает программа, когда процессоры с каждым годом становятся мощнее, ssd ускоряются, оперативки тоже и GPU, 15% не такая большая проблема, если прям нужно ускорить сильно программу, то конечно можно потом заняться оптимизацией и менять какие то участки кода на компоненты написаные на C и импортировать их в проект, так обычно в python делают

• 
  @camelCasedКүн бұрын

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

• 
  @plushkkkКүн бұрын

  привет, что у тебя за кейкапы?

• 
  @SerafimArtsКүн бұрын

  С каких пор OpenClose про наследование? Наследование вообще не очень хорошо. Опен-клоуз про открытость для расширения, что означает, буквально, что-то вроде: "Если у вас есть какой-то фектори, то шляпы, которые он возвращает должны быть дополняемы, а не захардкожены внутри". Т.е. не важно как это будет сделано, через метод `add(resolver)` например. А наследование - самый печальный способ расширения.

• 
  @CerberZer0S1gnaLКүн бұрын

  Джун: пишу от балды Мидл: пишу клинкод на солиде с драем и 25 фреймворками, пихаю аспекты, обкладываю юнит-тестами Сениор: пишу от балды Итог: код сениора работает, его в состоянии понять любая обезьяна, код мидла может понять только он сам, код джуна не может понять даже сам джун... Это я к чему? К тому, что как-то сообщество разделилось на "настоящих разрабов" и "чуваков пишущих приложеньки". Казалось бы... надо быть настоящим, но... Никому, вот вообще никому (кроме космоса, авиации и атомщиков), не нужен супероптимизированный, протещенный с краю до краю во всех корнеркейсах код, но через 10 лет. Всем нужно вчера и просто работающие для 95% случаев. Это плохо только для пушних усиков - плюралистов с подростковым максимализмом. А все остальные радуются, что кредитку можно оформить без посещения банка, в 2 клика. Вот такой мир и это не плохо. П.С. монолог пушных усиков через 20 лет в сфере...

• 
  @blackhammer5668Күн бұрын

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

• 
  @vadimwhite9661Күн бұрын

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

• 
  @gag6311Күн бұрын

  Видео "способы учить программирование", автор: пол часа затирает какой мотивационный спич не относящийся к теме видео. Мда

• 
  @alexr217Күн бұрын

  Тот кто выступает против clean code наверное никогда не работал на больших проектах написанных десятками и сотнями программистов. Там clean code нужен вообще без альтернатив. Иначе добро пожаловать в ад когда любое изменение может потянуть за собой десятки скрытых багов и месяцы дебага разработчиков в разных командах. Оптимизировать в более быстрый вариант без виртуальных функций, интерфейсов и тд можно только когда есть явное понимание что именно это приводит к проблемам с производительностью. На за 20 лет работы программистом мне это не приходилось делать ни разу. Обычно проблема кроется далеко не в уровнях абстракции или вызовах виртальных методов.

• 
  @ZlobuszКүн бұрын

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