Признаки слабого программиста

[@ExtremeCode]

Братан, хорош, давай подпишись на наш Telegram канал, мы там байки и кулстори травим 🖤 t.me/extremecode

[@wanes101]

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

[@романсократов-р6д]

Автор видео тот ещё пирожок.

[@worker9249]

Патерн - патерн поведения

[@ger_Kringe]

Инкапсуляция == сокрытие ))

[@QwertyQwerty-jv8cu]

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

[@alexanderbelov6892]

😱😂👍 Я этот прикол знаю. Пришлось как-то везти монитор... на кресле с колесиками.

[@UNDAGROUNDCREEP]

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

[@ulanaitbay]

АХАХХАХАХАХАХ

[@levleynov3663]

Согласен,это одно и тоже :)

[@UNDAGROUNDCREEP]

@@levleynov3663 Все так, братец xd🥹

[@crawfish5220]

Тоже не смотрел, зашел чисто убедиться, что инкапсуляция это сокрытие, а тут такой полезный коммент

[@FelixX138]

ахахахаха

[@Антон-э1ы]

Ждём "ООП для недоразвитых"

[@paveldumavin5068]

для чайников что то надо показывать максимально просто но не проще )))

[@homo-ergaster]

Стесняюсь, спросить. А вы недоразвитый, что так этого ждете?

[@zdogadnytsya]

@@homo-ergaster я да я

[@BitQuestCrypto]

@@paveldumavin5068 Для прожённых самоваров*

[@igoryudnikov6198]

Оно и так для недоразвитых)

[@ДенисАньенко]

Если ты не знаешь паттерн PIDOR ты не программист

[@idizor309]

Ты допустил пару ошибок в слове SOLID

[@AlekseiKazantcev]

@@idizor309 А вот щас обидно было, жду чтоб остасал завтра прям на столе

[@АрсенШ-б6б]

Chixx это ты?

[@БорисКрасных-ц8н]

Я овладел.

[@Sergey-e8e]

ухты что то новенькое узнал Надо затащить на собес

[@TopToro]

Месяц назад пришел студент устраиваться и сказал, что инкапсуляция это когда данные и методы содержаться в одном компоненте, и объяснил почему это не сокрытие. Я чуть не расплакался=) На работу приняли.

[@smaramna]

Я так же объяснял На работу не взяли =)

[@billymon11]

@@smaramna Надо было объяснить что методы СОДЕРЖАТСЯ, а не "содержатЬся". Тогда может и взяли бы. Но это не точно.

[@smaramna]

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

[@billymon11]

@@smaramna Согласен. Поэтому и добавил "Но это не точно" :)

[@loeoeowoa]

@@billymon11 душноватый ты школяр

[@dudai525]

1) 3:36 2) 5:37 3) 6:48 4) 9:47

[@oliwwateatwonan1321]

Дишмон 4/4 , кто хуже?

[@dudai525]

@@oliwwateatwonan1321 чего блять, про что несет хуй пойми

[@AlekseiKazantcev]

@@oliwwateatwonan1321 Мне кажется 3

[@kryptamine]

Есть один тонкий момент, о котором ты не упомянул. Есть еще особый вид "программистов", которые только что познали силу и мощь паттернов и начинают хуярить эти паттерны, там где нужно и не нужно и потом получается тот самый "Overengeneered garbage code". Лишь хочу добавить, что паттерны тоже нужно применять с умом и понимать где они действительно нужны и главное какие из них.

[@undefined-n5v]

Справедливости ради вынужден сказать, что одна хорошая мысль в видео есть: непонимание ООП ведет к непониманию паттернов. Уверен многие кто в свое время заморочился изучением ООП открывал книжку про паттерны и такой "О, да я всегда так делал"

[@Alekseev95]

паттерны нахуй не нужны, если кодить умеешь, то умеешь, не умеешь - книжка с паттернами не поможет

[@АлексейДоровской-х2ъ]

@@Alekseev95 Внатуре. Код есть код! А всякие там понапридуманные абстрактные парадигмы-шмарадигмы - второстепенно.

[@Creekererer]

@@Alekseev95 чо? Тоесть ты когда с коллегами общаешься и тебе предлагаю реализовать абстрактную фабрику, ты такой: кококо нипонимаю на маслятском?

[@andreyisaev1774]

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

[@Nikolay_K1]

Ну как посмотреть … Лет 15-20 новый мощный компьютер через год становился ведром для новых игр , потому что сами программы быстро развивались , и компьютеры тоже . Но при этом , чтобы на старых компьютерах хоть-как то можно было играть , разработчики выжимали что могли .

[@testerjohnson7940]

>Не беспокоимся об экономии времени >Выпускаем идеально оптимизированную игру раз в 15 лет >"Ебоные погромисты погромируйте игры быстрее сука"

[@Gameplayer55055]

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

[@rightpowered]

Ну время шло и закон Мура лососнул тунца в итоге, теперь тренд на оптимизацию появился, т.к. графические процессоры развиваются медленее центральных и тот же ксеон на 1155 сокете так же хорошо работает с видяхами до 1660й включительно, а уж на 2011 сокете и вовсе по 3090. Другое дело, что люди берут домой ради энергоэффективности пользовательские процы за оверпрайс при тех же хар-ках что и серверные из недавнего времени, что успели значительно подешеветь. Так что от оптимизации никуда не деться, и говнокодеры в двойном плюсе: сначала тяпляп в продакшн, а потом оптимизэйшн в продакшене за новые бабки. И все счастливы.

[@andreyisaev1774]

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

[@-mrws-]

Похоже на девиз современного геймдева: "Ваше время стоит диких бабок - нахер оптимизацию!"

[@me_000_xXx]

"нахер античиты!!!"

[@luck3949]

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

[@revester8165]

Кстати да, я тоже это заметил. Дожились, ебать, что на $2000 ПК еле-еле выдает 100 FPS на УГ4 играх.

[@_CossaCShocK_]

@@luck3949Рефакторинг: ну да, ну да, пошел я нахер...

[@_CossaCShocK_]

@@luck3949 Каким хреном читаемость касается оптимизации использования ресурсов? Я так понимаю, тест-кейсами код не покрывается, особенно когда мы пытаемся добиться максимальный выхлоп с кода? Если разрабатывать , чтобы вывалить в релиз поскорее, а потом угандошиваться годами с допиливанием до работоспособного состояния, то как раз и получается гуано высшей пробы. Программист не работает где-то в вакууме, и его обязан курироваться прожект-менеджером и ебаться в мозг тестировщиком, ну или все 3 эпостасии должны в нем одновременно уживаться, ибо в противном случае результат проекта - кал.

[@andrewmandrew5608]

Спасибо, за подробный разбор! Теперь никогда не забуду, что инкапсуляция - это сокрытие!

[@sergiopuccini]

Видос - балабольство - признак слабого программиста.

[@serhii5321]

Собеседование - это X-фактор, где умение или не умение петь мало влияют на мнение жюри (решение принято в первые 15 минут общения). Тебя по unit-тестированию "гоняют", а по факту в проекте лютый легаси окажется и никаких тестов :)

[@illiaostrovskyi5101]

инкапсуляция - это сокрытие)

[@TheVolkovAlexandr]

блин, жир из монитора потек!

[@error4ik614]

бан

[@me_000_xXx]

Инкапсюляция - это РАЗДЕЛЕНИЕ интерфейса от реализации. есть сокеты, я "кря" как они реализованы(никто в душе не "кря"), но с их интерфейом я могу работать и клипать, например, клиент-серверные аппликухи.

[@mayonnaizzee]

@@me_000_xXx ого ты что программист

[@night_h4nter]

Бан.

[@alexl7161]

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

[@tentacle8148]

Да

[@takiekakmi7532]

Да вы больны, сударь!)))

[@АлександрКарачёв-я3э]

Толкового ничего не сказал, видео из жанра - "как заезжать в хату на зоне".

[@j.d.3890]

как и все другие его видео)))

[@mikeistp5736]

Просто ты не целевая аудитория этого видоса/канала.

[@Aimilomim]

Дальше сингтона и фабрики так и не ушел.

[@alexlightweight]

Заходишь на собеседование в IT контору, а тебе hr полотенце кидает под ноги ))))))))))

[@ИванШвалев-к8р]

Cамая точная аналогия для собесов))

[@truman5652]

Ну такое. Спорные моменты, особенно на счет спросить о паттернах и узнать знает ли человек ООП. Рекомендуемые шаблоны решения часто возникающих задач это одно, а знание как реализуется ООП в тех или иных языках это другое. Сам по себе ООП не является овернжинирингом, а наоборот в виду своей философии позволяет в более легкой форме реализовать бизнес задачи. Но, в целом, спасибо за видос) Лайк за труды!

[@Raspredval1337]

и что это было? Аффтор просто потыкал в нас ссаными тряпками. Я и сам себя могу потыкать ссаной тряпкой, а вот привести пример, например, почему ооп ведет к оверинженирингу и какие паттерны используются 24/7 в большинстве проектов нет.

[@KaraMaslyatam]

Наследование: может быть настолько глубокое, что тебе надо полдня потратить, чтобы понять, как работает простейший объект и наследование ненужных конечному объекту данных. Инкапсуляция: private когда можно public, магические методы, не всегда нужные геттеры-сеттеры... Паттерны: смотри видео на канале "Паттер PIDOR".

[@ex-format]

@@KaraMaslyatam знакомый рассказывал. Попал на проэкт из времён 1.4 джавы... Под 40 наследований... 3 месяца только вникали что с этим делать

[@hendospirit889]

@@ex-format в данной ситуации подходит универсальный вывод - всё хорошо в меру)

[@LedoCool1]

>и какие паттерны используются 24/7 в большинстве проектов Все паттерны, которые ведут к уходу от ООП. Например, dependency injection.

[@inbuckswetrust7357]

@@LedoCool1 а инжектируешь то ты что ? :) какую сущность ?

[@mayonnaizzee]

Спасибо, теперь я еще больше считаю себя куском говна

[@ArcanumTeam]

+1

[@АлексейБарышев-д6ю]

Обрайщайся )

[@alexlightweight]

А я за 15 лет программирования (C#/Go) понял что сила не в GoF, SOLID, GRASP и т.д., а в простой вещи, называемой принцип KISS. Кстати мало кто знает что KISS не айтишный принцип, а пришел в IT из американской военной промышленности 70-х годов, там были те же проблемы проектирования, что сейчас у нас в IT. Суть моего спитча: любой простой гавнокод можно срефакторить до норм кода, а вот 10 этажную архитектуру с использованными +100500 паттернами, которая просто выводит на экран список пользователей, срефакторить очень тяжело и иногда просто невозможно на реально работающей системе => поддержка превращается в запуск шатла на марс.

[@alexanderbelov6892]

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

[@_-BIMBO-_]

Спасибо чувак! Но признаюсь. Я байтики и даже битики гоняю. и знаю такую хрень как BOOL. А еще я обожаю калькуляторы на смартфоне весом в 1ГБ это признак вундервафельного програмиста. В пиратской бухте Embedded и IOT неумение делать так " HREN &= ((1

[@destroy_swarm]

эмбеддер детектед )

[@_-BIMBO-_]

МИСТЕР! Имеешь что то против ембеддед?

[@destroy_swarm]

@@_-BIMBO-_ имею только за )

[@Dron008]

Как-то переживаю за HREN. Ты лучше его как константу объяви.

[@Evgeny_Ermakov]

Возможно вы имели ввиду поразрядное ИЛИ, а не логическое?

[@roman.tsvetkov]

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

[@MavelRoll]

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

[@TheVolkovAlexandr]

Поддерживаю. Особенно когда паттерны добавляют потому, что знают их, жертвуя этими принципами.

[@zkksch]

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

[@denedi8485]

@@zkksch паттерны нужны не только для того чтобы их использовать самому, а чтобы было легче объяснять свою идею другим людям. Вместо того чтобы описывать пол часа алгоритм, ты можешь просто сказать название паттерна и тебя должны понять. (Ну эт в теории.....)

[@alexpotap3985]

многие из старых паттернов уже признаны антипаттернами, solid да, норм тема

[@inbuckswetrust7357]

солид спорная шляпа очень спорная. это отрыжка рынка в IT по сути.

[@olegtsenilov3610]

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

[@olegtsenilov3610]

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

[@LYNCH1PC]

Признак слабого программиста - говорить про ООП, но не говорить про другие подходы

[@andreybiryulin7207]

полиморфизм это использование указателя на указатель функции, а не прямого указателя функции (то есть даёт возможность поменять указатель и тем самым поменять имплементацию в будущем, но фиксирует публичный контракт во время написания кода) указатель на указатель это Action,Func в C# interface в C# это именованный массив Action/Func в C# ООП живёт ещё в определенных нишах, а т.к. 90% программирования сейчас это backend HTTP service, которые по сути stateless, то там ООП не очень заходит, потому что суть ООП об изменяемом состоянии, которого в веб сервисах просто нет (REST по факту это набор функций с передаваемым состоянием в аргументах). В десктоп приложениях и там играх всяких на Unity ООП вполне себе подходит. Поэтому не очень согласен с тем что ООП очень жив, на подавляющем большинстве современного бэка ООП скорее вредно, чем полезно.

[@vomgame]

Из-за таких гениев мне самому хочется стать блогером по программированию

[@DecapitatedHamster]

Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[@250-p6i]

Охренеть! 2 наносекунды против каких-то там жалких бабок каких-то программистов и программисты выигрывают... 2 наносекунды, даже по минимуму, даже если монитор выключен, даже если всё выключено, только процессор работал, какой ни будь i5 9400, это: 0.000000002 * 65 джоулей энергии просто в тепло (тепловыденение процессора), даже для миллиона пользователей всего 100 раз в день это уже за 1 день: 130 джоулей. А если это происходит у миллиарда пользователей тысячу раз в день, скажем, код где-то в популярном браузере, то: 130000 джоулей энергии. 130 мегаджоулей! 130 мегаджоулей в тепло просто потому, что "их время стоит дохрена бабок". Да не стоит ваше время дохрена бабок, если вы сливаете почти 4 литра бензина каждый день в помойку просто потому что вам так проще понять чей то там код. И ведь это реально 2 наносекунды и всего лишь миллиард пользователей и всего 1000 раз в день, а тот или иной участок кода может выполняться далеко не 1000 раз в день, а миллионы раз в день у многих миллиардов, например, декомпрессия jpeg или разборка HTTP заголовка или сраный a+b в каком ни будь интерпретаторе JS.

[@ko_fes]

8:46 - 9:04 - не совсем верное высказывание: const объекты в js мутабельны (их можно изменять), но переопределять их нельзя

[@andor1904]

Ясно аффтору пять лет

[@arhitutorials]

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

[@BlizzardLight]

Надо думать, а не уметь. Уметь если не думаешь - это **обосраться без жопы**

[@mainframe8123]

Такой надменный тон у автора, сразу видно - молодой =)

[@theHaPK]

Ахаха... поддерживаю! Все рассмотренные вопросы нацелены на молодых (потому что опыта у них нет и непонятно что с них еще спросить можно)...

[@Petro_Bandera]

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

[@TopToro]

@@Petro_Bandera я думаю автор потому и не работает на аутсорсе с легаси проектами, так как к качеству кода относится адекватно

[@pacckat]

@@TopToro , слабак чтоль? ))

[@ИванШвалев-к8р]

@@pacckat немужык штоль?

[@dicloniusN35]

за 2 года прогрессировал: научился китайские порно мультики рисовать и забыл код

[@Kilosaw]

Дада, в принципе, все правда, а вот за аргумент против синглтона в качестве показывания навыков спасибо) 🙃👍🏽

[@lnvaIidUsername]

да лажа. У меня ~15 лет опыта на шарпе, я паттерны знаю как свои 5 пальцев, но на собеседовании на вопрос о паттернах всегда начинаю с синглтона и смотрю на реакцию.

[@andreykrasnov7851]

lnvaIidUsername И какая бывает реакция ?

[@samtux762]

Singleton и factory - два основных паттерна в ООП. Ну не при flyby же мне рассказывать (это экзотика и я не хочу смутить интервьюеров своим вычурным примером).

[@qwertymangames1800]

Автор 11 минут доказывал, что у него нормальная ориентация. Но проболтался что называет мужиков пирожками)))

[@maximmagadeev1414]

В сообществе C++ или Java принято рассматривать инкапсуляцию без сокрытия как неполноценную.

[@useit1]

Тыкнул паузу на "у чела 2 репозитория с разницей в полтора года и там одно и то же", ммм а давай прикинем что челик рвется к тебе на джуна и прикинь, он и шарит не выше джуна. Что у него должно быть в соседних репах, в одной хеловорлд, во второй колайдер? Если он пытается устроиться джуном, значит у него опыта скорей всего нет, либо самоучка, либо студик. В любом случае ему толком опыта неоткуда набраться и прогресс если есть, то только усилием самого персонажа, что автоматом накидывает ему плюсиков и выделяет из массы, то бишь он качал скилуху не получая за это денег, respect+ таким пацанам.

[@maktor7697]

Я из этого видео запомнил что инкапсуляция это не сокрытие))

[@vladbreez4036]

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

[@mechmaker9346]

"ООП - целостный набор парадигм" Чо? Почему тогда это ООП? Объектно ориентированное программирование... Где здесь парадигмы? Знание паттернов != Знание ООП. Это лишь топовая фича,которую стоило бы знать.

[@adeusexmachina]

объектно-ориентированное парадиграммирование :D

[@darellldark]

Вероятно, автор имел в виду, что ООП является парадигмой. Либо автор просто не знает, что такое парадигма в целом.

[@dadadodo123]

Какой же у вас божественный канал! Боже храни youtube рекомендации!

[@АрсенАхмедов-ю2я]

Нихуя не понял, но ооочень интересно. Вернусь пожалуй когда разберусь в HTML.

[@leosv0]

@КУБАНЕНКО КАВКАЗОИДОВИЧ ХУЙЛОСТАНЦЕВВАТНОПЕРДАКОВИЧ а кто нужен-то? И как ваше высказывание соотносится с вакансиями на НН?

[@decker08]

Использую инкапсуляцию для сокрытия. Чем меньше в твоей библиотеке открытых методов, тем проще её изменять.

[@edward.vstock]

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

[@ДенисЯчменёв-щ8з]

Вам бы поработать на одном серьёзном проекте лет 5 с кодом, который постоянно нужно расширять, но его трудно читать и понимать, а будучи оптимизированным под конкретную задачу его ещё и сложнее расширять... И желательно, что-бы ваш коллектив состоял минимум из 5 человек. Но если вам такое под силу, то у вас очень хорошая память и идеально поставленный процесс передачи данных и всё вечно на слуху. И скорее всего уже в состоянии возгорающегося уголька. Без обид, но автор прав.

[@igorkorgi]

Тоже в первые пол года своей карьеры думал что нужен "оптимальный баланс". Но сейчас, как тот кто работает в отрасли 10 лет могу сказать, что оптимизировать не нужно пока не появится необходимость, так как твоя оптимизация (даже в плане поиска "оптимального баланса") в итоге окажется нахрен никому не нужна в бОльшем проценте случаев. Например, ты думаешь такой: "Вот этот участок должен работать максимально быстро, так как это популярная фича и все ей пользуются". В итоге этой фичей раз в пол года пользуется баба Нюра, во время полного затемения, когда луна в Марсе. Или второй пример: ты думаешь что в метод будут приходить огромные массивы данных и оптимизируешь его, в итоге туда приходят массивы по 1-5 объектов. И таких примеров ещё можно навалить кучу. Получается что ты бессмысленно убил на эту оптимизацию кучу времени, ещё и наговнял в коде, так как обычно оптимизированный код очень хреновый с точки зрения чтения, исключения лишь подтверждают правило. Лучше писать код максимально просто и прямолинейно, принцип даже такой есть KISS, вот его надо в первую очередь использовать . А оптимизировать стоит уже готовый код, когда 100% известно что он используется постоянно, и когда оптимизация этого участка принесёт какую-то ощутимую экономическую пользу.

[@АТочкаС]

Отличное видео! Для начинающего - особо нужная инфа!! Спасибко!!!

[@TheXbxeh]

Да я байто-еб но я программирую промышленные контроллеры, с размером памяти 8 Мбайт)))

[@pejtepivo]

Я программировал компьютер с 16 килобайтами озу. А в 128 килобайтах я сделал игру с хорошей графикой и музыкой.

[@ВалерийКнязьков-л4ч]

@@pejtepivo, МК-52 105 шагов программы... Первый курс института, все счётные работы на нём. После него и РК86 выглядел просто шикарно.

[@Dron008]

Помню офигительные демки размером 4 килобайта. А сегодня коллега искал в старом Ruby функцию обрезания символов в начале строки, не нашёл. Но нашёл функцию обрезания в конце. Chomp или как-то так. (я не рубист, если что, давно когда-то писал немного). И ещё нашел функцию разворачивания строки. Так он додумался развернуть строку и обрезать в конце, а потом развернуть назад. Вот серьёзно, не анекдот, реальный случай! О том, какие вычислительные операции за этим стоят, он, конечно, не думал. говорит, а что , у нас компы быстрые (ему недавно подогнали макбук этого года). Пипец!

[@vladislavdudnikov26]

o_O шикарно живёте. Не знаю размер какой памяти, но, видимо, оперативной. Я прогал на контроллерах с 32, 64 килобайтами памяти. Да, байто-дрочерство там обязательно, но в пределах разумного. Я в своё время даже в циклах писал uint8_t, потому что знал, что массив размером поменьше будет. Но в реальности это нафиг не нужно, тем более когда меняешь программу, то такие вещи отслеживать очень сложно.

[@ИмяФамилия-о4т5р]

@@Dron008 Если не ошибаюсь, то строка в Ruby - объект. Тогда среди его свойств может быть что-то вроде "порядка символов", 0 - обычный, 1 - перевёрнутый. И тогда получается, что совершается не так уж и много лишних операций

[@МихаилКузнецов-э8в]

0:54 - яркий пример инкапсуляции! Всмысле, мы видим(хотя мы не должны видеть) абстрактную смутно знакомую комнату с вполне материальным диваном, на котором с абстракными сущностами на входе взаимодействует некий объект извне. На выходе из чёрного ящик... инкапсуляции мы имеем довольную рожу объекта и немного разжившимяся свойствами и методами наследников абстракций

[@Aricael]

автор, а где твой гитхаб?

[@liletl3083]

Я который только скачал visual studio и начал "программировать" и зашедший сюда: Неее поняяял, вы на каком языке разговарываете, сэр ?

[@lsankazarez6174]

Всрал 11 минут...

[@valsermistat9744]

Чисто для сведения: 0. ООП это "CALL DWORD PTR[@parentClass+EBX]". И как бы вы не изгалялись, как бы не называли это, будь то инкапсуляция, конструкторы, паттерны, ВСЁ РАВНО ЭТО БУДЕТ "CALL [nn]". 1. ООП не везде, а только там где шир-потреб. А шир-потреб это 90% того, что вас окружает. И окружает оно вас именно потому, что вы называете себя программистом, что может сделать каждый, что и делает каждый. В итоге весь ваш продукт как туалетная бумага, на один раз. Проходит год-другой, и ваш кодо-труд стирают. 2. const это не макрос(для вашего понимания define), как вы привели пример с "some text". От того, что ваш язык программирования оптимизировал это именно так, не значит, что это инстанция первого уровня. Вы используете виртуальные языки, каждый из которых, под каждое конечное устройство оптимизирует результат вашего набивания текста, кой вы называете кодом, да же если это и интерпретатор. Люди, которые называют себя кодерами, не на столько плоско мыслящие, и прежде чем утверждать, - что та, или иная фича может оптимизировать результат, НАВЕРНО БЛЯХА МУХА, изучили этот вопрос ? Если бы вы хотя бы один раз написали компилятор, самый простой, или на худой конец, прошлись бы дебаггерам по своему коду, то увидели бы много интересного. Оптимизатор в компиляторе, не может из воздуха брать алгоритмы, он должен на чём-нибудь базироваться. И один из алгоритмов, это "StepUpOverflow", смысл которого находить переменные внутри циклических областей кода, для того, что бы повысить приоритет использования под них регистров конечного устройства(ядра). Константа, в данном случае, помогает оптимизатору понять, что кто-то хочет максимально ускорить, ту или иную операцию. Это фича, которой пользуются очень много людей, именно это им даёт возможность писать быстрый код, не перепутайте с написанием кода быстро, поверьте, результат диаметрально противоположный. Поясню как это работает, допустим есть такой код: char someFunction(void) { char re=0; const char ax=GetData(0); do { const char bx=GetData(ax); do { const char cx=GetData(bx); do { const char dx=GetData(cx); re ^= dx ^ cx ^ ax; } while (cx ^ dx); } while (bx ^ cx); } while (ax ^ GetData(re)); return re; } Вот оптимизатор будет вытеснять регистры по вложенным циклам. Если конечное устройство имеет всего ТРИ регистра ядра, то, "re"=R0, "dx"=R1, "cx"=R2 и "ax"=[@Mem]. Константа даст оптимизатору понять, что кто-то хочет добиться МАКСИМАЛЬНОЙ скорости работы данного куска кода. Забудьте навсегда о своих скудных представлениях о программировании, особенно оценивая их через знания JAVA. 3. const не означает ReadOnly. В выше приведённом примере есть вот такое "const char bx=GetData(ax)", в реальности в "bx" будет произведена запись, мало того, можно ещё сделать вот так вот "((char *)(&bx))[0]++;", и представляете, константа вдруг увеличится на единичку, правда в последнем случае оптимизатор может не выпустить наружу(StepUpOverflow), эту переменную, но это уже другой вопрос, который вам ооооооочень далёк для понимания. Ну и последнее, самое главное, упоминать "интерпретатор", и рассказывать про константы и ООП, это как упоминать имя Бога всуе. Вы настолько далеки от программирования, что дальше уже некуда.

[@alex-rr5mt]

А когда мы уже увидем CODE (код) на этом данном канале?

[@kpanat]

собеседование особенно на программиста не проверка твоих знаний навыков и тем более не способностей а скорее работа абстрактной памяти на запоминание всяких терминов. К реальной работе это отношение не имеет. Можно блестяще пройти собеседование(на которых нет тестов) но совершенно не понимать в программировании. Это легко проходят всякие полиглоты и люди с хорошей абстрактной памятью. Но они как правило плохие программисты. Потому что для программирования нужен хороший интеллект. А это редко сочетается с хорошей памятью. Ты можешь какие-то вещи хорошо знать и постоянно этим пользоваться но при этом не знать как это называется. А спросят тебя по названию. А ты этого не знаешь. и вполне можешь ответить что не знаешь. И все решат в том числе и ты что это так. а потом когда ты придёшь и загугишь выяснится что это то, чем ты постоянно пользуешься! Так что собеседование это не реальные знания а терминология. У меня такое было и не раз. А потом они ещё сабаки каждый раз придумывают новые кудрявые названия старым вещам. Поэтому получается или ты хорошо проходишь собеседование, или ты хороший программист. Насчёт тестового задания.Его можно дать такое что мало кто с ним справится. Но это не значит что он не сможет там работать. Просто человеку всегда нужно время чтобы войти в курс дела. А по началу он может и не знать или не уметь. Но потом будет легко справляться даже с боле сложными задачами. Почему так происходит? А потому что технологий слишком много как и ЯП человек не в состоянии всё знать и уметь. Ты к примеру учил OpenGL а тебе дали задание по Qt которое ты учил полгода или год назад. И ты естественно забыл уже это... Но тебе не дают времени вспомнить. Работодатели вобще смотрят на кандидатов как буд-то они уже работают у них в компании... Но поначалу человек ничего не знает и не умеет или не помнит когда приходит на новую работу из того чего надо знать и у меть . Просто потому что в других компаниях другие требования, другие технологии и навыки, другие подходы. И чтобы это всё это узнать надо время. А они хотят сразу всё здесь и сейчас. А это в принципе невозможно даже если ты супер пупер.. За исключением ситуации когда ты здесь уже работал или в аналогичной компании... Потому что изучить это можно только работая в этой компании некоторое время. И так всегда, по другому не бывает... Поэтому стажёр это оч хорошая идея. Можно взять несколько с небольшой оплатой а скажем и через месяц уже выбрать лучшего. а так на собеседовании вы ничего не определите или определите неправильно. И сам кандидат может передумать так же. Это нормально если его что -то категорические не устраивает чего он не знал а потом выяснилось... тут ведь главное не спешить дать время и это не 5 минут.. а хотя бы пару недель... А собеседование сколько длится? час другой если дольше, то это уже плохо... Что вы можете узнать о человеке которого вы в первый раз в жизни видите за это время? Да ничего толком. Вот в этом и проблема... Вы кому-то отказали вы уверены что правильно? нет...А кого-то напротив взяли. Вы уверены что того человека взяли и вобще сможет ли он выполнять работу которую вам надо? Вряд ли... Но многие думают что могут и ошибаются! В этом и беда... Собеседование это не тот формат по которому можно отобрать хорошего программиста а плохих отсеять. Конечно в тривиальных случаях да. Но вам нужен более высокий уровень не так ли? Вот...

[@NoName-nj3zw]

Блять, уже не первое видео смотрю этого парня. Пишу комменты чуть реже чем никогда. Но тут надо сука... Я ржу каждый раз как конь, камеди клаб просто слезно отсасывает... Красава! И боевой дух поднимается и хочется учить еще больше и дольше все. Спасибо за канал. Пойду дальше набираться мудрости под дикий лошадиный ржачь. Как же это ахуенно.

[@daldlaushel5841]

Братан хорош! Давай контент! В кайф! Можно ещё?! Вообще красавчик!!

[@dmitriibannikovasx]

9:48 Я так и не понял, чем тебе не нравится увеличение производительности и твое "байтоебство"? Что в этом плохого? Я может быть тебя удивлю, но не у всех по 32 гига оперативы в компах, а некоторые вообще программируют микроконтроллеры, где каждый байт важен. Некоторые даже помещают строки-константы во флеш память принудительно, чтобы они не занимали оперативу. Делать код производительнее это наоборот, признак ну может не сильного программиста, но уж явно не новичка. Со всем остальным согласен, но здесь ты хуйню сморозил, или я не понял твой посыл. С другой стороны, мы код пишем, чтобы его исполняла программа, а не читал другой программист, в большинстве случаев. И да, у меня тоже взорвался пукан.

[@BlizzardLight]

*автор посылает вас нахуй * ЕГО ВТОРАЯ ЛИЧНОСТЬ ХОЧЕТ ШОКОЛАД И УБИВАТЬ

[@michkovskyi]

10:40 пора вьіходить из криокамерьі, хороший довод 5 лет назад. Сейчас можно узнать у azure сколько в деньгах стоит указанньій кусок кода на исполнении. Вцелом - очень хороший обзор.

[@SteelyGlow]

"Харэ байтоёбить, мне надо, чтоб твой калькулятор весил тридцатку и жрал двести мегов оперативы"

[@Многолицый-ф8е]

константа оптимизирует мозг программиста разве что)

[@ВаняЖуков-л8ь]

Мне вот стало интересно, а как по-твоему переводится инкапсуляция, гений?

[@agentsmith9708]

объединение свойств и методов в один объект. а сокрытие - это либо использование полей и методов с директивой private либо замыканий в JavaScript. но вообще если надо что-то скрыть без инкапсуляции никак

[@borisn879]

@@agentsmith9708 это узкий пример из конкретных ЯП. Инкапсуляция как реализация - это объединение свойств и методов. А инкапсуляция как цель - это сокрытие в смысле изоляции. В разных ЯП инкапсуляция может совмещать и сокрытие, и совмещение, или же что-то одно.

[@nikitazogas3676]

Принципы SOLID важнее паттернов. Если следуешь SOLID принципам, то очень сложно написать плохой код. А вот если бездумно применять паттерны, например пихать везде свои Facade и Adapter, то плохой (читай "нерасширяемый") код только и будешь писать. Паттерны хороши тогда, когда ты знаешь 80 и больше % паттернов, тогда ОК. Иначе, как правильно написано на refactoring.guru, "если из инструментов ты знаешь только молоток, то везде будешь видеть только гвозди".

[@dmitriyzhernoviy8781]

thumb down: reason : git push --force 😆 Working one year as SDEt for one small/medium s/w house in us. Probably 90% of a staff would fail passing this test. Even an internal wiki onbord docs suggest to use SourceTree as a git client. Not sure even if anyone aware that git has CLI. So if you happen to be our candidate. No worries 👍 you would pass

[@guxershmeg]

Джон Кармак сказал GoF чисто теоретическая книга, ее почти невозможно применять на практике, надо прислушиваться к людям, у которых есть несколько больших коммерчески успешных проектов. Если посмотреть в репозиторий андроида, там все написано не по GoF. А на тематических сайтах по CS написано, что паттерны нужны только на этапе рефакторинга, но не раньше, иначе получится какашка дизайн. Если в ситуации удобно использовать паттерн визитер, надо весь код выбрасывать, это написал один из авторов GoF. В Америке в вузах больше не учат паттерну обзервер, потому что студенты его не понимают и используют не правильно.

[@painpb5550]

Вижу новый видос ExtremeCode - ставлю лайк

[@zordq]

Спасибо за мотивацию, ещё бы проектов найти больше для практики, было бы вообще замечательно .)

[@MrSevenZZZ]

Ниагара просто какая-то. Приемный сын капитана очевидности и шнура решил заняться программированием: маты и очевидности и все это под километровой толщей воды. Так какие слабости я должен устранить?

[@VladimirGolev]

Нажать на ютубе "not interested", чтоб он больше не подсовывал видео с этого канала всюду..

[@VladimirGolev]

Точнее, у них новый пункт меню появился "don't recommend this channel". Рекомендую )) ps: правда только в ленте рекоммендаций. В самих видосах нет такого. Но надеюсь повлияет везде.

[@trikrapka]

пол видео как обычно бомбежка на сокрытие, то есть инкапсуляцию 👍

[@MrOverlord243]

Неплохо поплавал, столько воды, ууух!

[@jerondiovis6128]

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

[@_CossaCShocK_]

Ну да, раскажите про байтоебство в геймдеве)))

[@ЖеняФедотов-в7о]

Или в программировании микроконтроллеров, особенно Attiny и подобных.

[@HardLOLMaster]

@@ЖеняФедотов-в7о сударь, да вы как разраб слабы. Видеоролик то не о контроллерах и не о том как экономить память. Он об ошибках начинающих разработчиков в большом мире энтерпрайза

[@ВладБобров-й1ф]

Что такое безумие? Это пересматривать ваши видосы снова и снова, в надежде, что в них появятся очередные ах*енные шутки.

[@klxqz]

Пафаса дофига, а смысла ноль)

[@agentsmith9708]

вот такие обычно доходят до высоких должностей, хотя бестолочи в технической части. а "байтоёбы" так и дальше красноглазят и байтоёбят и ездят на общественном транспорте

[@lunedefroid8817]

Ну всё, экстримкод обосрался. 10:20 На самом это хреновая оптимизация. Для максимальной скорости работы со счётчиком в цикле, его размер должен совпадать с машинным словом. А если он будет в 1 байтом, то это только ухудшит скорость. Это при компиляции без оптимизации. С оптимизацией он вообще переменную не создаст, а в регистре будет хранить, там вообще не важно. А что касается оптимизации кода - оптимизация должна быть алгоритмическая. C++ со второй оптимизацией и так вам всё максимально упростит, а вот асимптотическую сложность алгоритма он вам не улучшит. Это и сложности по памяти касается.

[@squidwardfromua]

10:54 Судя по Киберпанку, оптимизировать не нужно никогда, ибо всегда есть железо помощнее.

[@romiussss]

Просто посмотри на ассемблерный код с использованием const и без. Вот несколько примеров. godbolt.org/z/PkAXxU godbolt.org/z/3DgybT Модификатор const позволяет компилятору проводить оптимизацию! 1. Константы будут записаны в read only memory, доступ к которой осущиствляется быстрее 2. Условия где используются константы пропускаются, так как их результат зарание известен компилятору 3. Присвоение констант позволяет пропустить предворительное считывание с регистра, так как эта часть памяти не меняется и там лежит ровно то что изначально туда положили! Вот еще статья об этом habr.com/ru/post/453262/

[@damik_max]

Инкапсуляция это сокрытие, я вам это от всей души говорю, это сокрытие, просто 100%. Я в этом уверен и меня нельзя переубедить.

[@error4ik614]

бан

[@alekseymudla5374]

Тут даже на википедии вопрос рассмотрен ru.m.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

[@vfnikster]

Здесь путаете цель и средство. Средство - сокрытие (от изменения посторонними операциями), цель - защита данных и кода от ошибок в посторонних модулях.

[@BlizzardLight]

@@vfnikster взрыв пукана инкапсуляция делается сокрытием *горит канал

[@Олегатор-щ4й]

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

[@BlizzardLight]

Хотите поговорить о религии и карании демонов Палачом?

[@illegalboy8508]

Я говорил на собеседованиях кучу раз что это сокрытие. И все было ок, кидали офферы

[@juliusmalkov9620]

они просто не знают правду)

[@VladDraculator]

После этого видео все изменится)

[@scary_ai]

бляц

[@ВадимОгир]

Первый канал, которому действительно не впадлу поставить колокольчик

[@YlwDrknss]

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

[@zcbesaba]

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

[@warbine5819]

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

[@SteelyGlow]

Любители хранить бул в лонг-лонг-инте согласны с автором ролика

[@yakub8798]

я начинающий программист и поэтому половину того что ты сказал я не понял но было интересно

[@алексавы-р5к]

Понятие инкапсуляции из книги по Java Шилдта. Если это не сокрытие то я хз как это назвать. возможно просто автор этого ролика сам не очень хороший программист Механизм, связывающий код и данные, которыми он манипулирует, защищая оба эти компонента от внешнего вмешательства и злоупотреблений, называется инкап­ суляцией. Инкапсуляцию можно считать защитной оболочкой, которая предохраня­ ет код и данные от произвольного доступа со стороны другого кода, находящегося снаружи оболочки. Доступ к коду и данным, находящимся внутри оболочки, строго контролируется тщательно определенным интерфейсом.

[@MikyWay-justsay]

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

[@LordoftheLamerS]

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

[@iosifguzeev4362]

Всех знакомых спрашивали (С++, С#), но да, конечно от отрасли зависит.

[@LordoftheLamerS]

@@iosifguzeev4362 ну на плюсах не удивлён такому)

[@mars8430]

@@LordoftheLamerS на каждом собесе по пыхе меня спрашивают паттерны. Наверное про них не спрашивают только html программистов

[@LordoftheLamerS]

​@@mars8430 Яндекс, Касперский, Mail.ru, Ingram Micro, МегаФон на вакансию веб-разработчика меня не спрашивали об этом, обычно спрашивали только там где на мой взгляд достаточно слабые команды как ни странно). Другой вопрос почему так? Я полагаю просто потому что опытные разрабы/тимлиды реально понимают, что если ты используешь паттерны проектирования, то либо ты пилишь свою библиотеку, либо делаешь что-то неоправданно сложным (там где можно сделать проще), как правило все эти паттерны проектирования уже вшиты во внутрянки всяких фреймворков/библиотек и нам остается просто этим пользоваться.

[@AdamFullowsky]

На 32х битных системах в принципе байтоёбить не норм, в итоге будет на 2 операции ассемблерных больше. По крайней мере на сях. Там дополнительно идёт перевод в dword

[@justamosquito191]

1:40 эта реклама настолько внезапная, что мне понадобилось 10 секунд, чтобы сообразить.

[@Archik4]

Лол, ирония в том, что byte всё равно упаковывается в (процессорный) int. Это легко заметить, даже без асма, когда складываешь два байта тебя просят итоговую сумму явно привести в байт. Так что, если пишешь "производительный код" будь добр хотя бы убедится, что не страдаешь хернёй. Как минимум перед оптимизацией посмотреть во что превращается код после компиляции, может то, что ты хотел сказать компилятор и без тебя понял и твоя оптимизация ничего не изменит кроме длины кода.

[@SteelyGlow]

В память кладётся именно байт, а не инт, размер которого, кстати, варьируется в зависимости от компилятора и платформы. Поэтому, если надо жёстко контролировать, что же у тебя в массивы/файлы пишется, unsigned char наше всё

[@Archik4]

@@SteelyGlow каждому инструменту своё применение. Я же говорил просто про арифметические операции внутри процессора и про C#. На C++ можно быстро смотреть здесь gcc.godbolt.org/

[@Archik4]

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

[@Archik4]

@@SteelyGlow хороший пример оптимизации компилятором gcc.godbolt.org/z/rvA7MF

[@SteelyGlow]

@@Archik4 а известно, какого именно процессора?) Известно ли, в каком порядке байты? Я про кросс-платформенные программы говорю. Пример #1: 16-битный контроллер или вообще 8-битный 6502, для него утилитой, которая должна давать одинаковый вывод на всех платформах, надо подготовить двоичный файл данными, и чтобы этот файл можно было той же утилитой править, не пересоздавая его каждый раз. Пример #2: Есть некий файл, его нужно открывать в разных ОС, программа, которая его открывает и сохраняет, собирается из исходников. Нужно обеспечить совместимость файлов, созданных на разных ОС с минимумом плясок с бубном. В этих случаях можно оперировать только фиксированными величинами, если не хочешь морочиться с директивами компилятора и писать отдельные куски кода для каждой платформы. XML, разумеется, не вариант, т.к. имеет тенденцию раздуваться в десятки раз по сравнению с полезными данными.

[@diasakishev8897]

10:55 и вправду звучит как цитата говнокодера)))

[@MrSmith01]

"Premature optimization is the root of all evil" -- DonaldKnuth

[@Вродебычеловек]

Сейчас только начал учить HTML и CSS. Ни**го не понял, но очень интересно.

[@U7Craft]

учите ооп, не байтоебте, учите английский на камблу, забудьте про синглтон - учите мултитон

[@anotherone3641]

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

[@alexanderbelov6892]

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

[@ewgeny911]

ООП - это очень малая часть программирования. И далеко не самая важная. Понимание бизнесс процессов, архитектуры и взаимодействия различных составляющих всей ИТ инфраструктуры в компании - это важнее. Знание и понимание взаимодействия с базами данных и оптимизации баз данных, знание разных языков программирования и фрейворков, и понимания выгоды применения их в разных ситуациях, это гораздо важнее. Архитектура важнее кодинга, а бизнес аналитик важнее программиста - вот так. А что ООП... вот возьмите spring из java. Популярный фрейворк, основная идея которого - это за счёт рефлексии попытаться обойти ограничения ООП. При реализации бизнес логики, когда бизнес прицессы в компании постоянно меняются, использовать ООП даже вредно, потому, что в этом случае переделки, внесение изменений в код усложняется. ООП можно применять тогда, когда конечная цель точно известна и есть уверенность, что завтра не придется ничего переделывать. Даже visual studio для C# при малейшей возможности советует класс сделать статическим! Раньше программы занимали меньше места на диске в разы, а сейчас что? Увеличение объема программ (и соотвествующее замедление их работы) - это прямое следствие бездумного применения ООП где нужно и где не нужно. Это потому, что для того чтобы ипользовать один метод чужого класса необходимо включить в свою программу весь класс, а тот класс тянет за собой ещё классы и так далее. В результате имеем, что в современных программах 99% кода не используется.

[@vladimiryaskov5259]

Так не сами же классы тянем, а ссылки на классы. Это как раз и позволяет сократить код. На счёт паттернов с ООП полность согласен - это прям символ веры какой-то.

[@ewgeny911]

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

[@Василий-э8ч4ш]

слава богу смотрел на скорости 1.5, и проебал не 11 минут жизни, а 7

[@alexander551]

Запомните! Самое главное - не перепутать сокрытие со вскрытием

[@k1ark143]

"Инкапсуляция это сокрытие" ExtremeCode

[@Delirium132231]

Фраза про обмылок и фото индуса это то что меня добило и я подписался на канал))

[@alexander551]

Узнал себя