10 советов от Senior для начинающих программистов

[@nooftube2541]

"Если вы не понимаете GRASP, паттерны вас не спасут." GRASP - General Responsibility Assignment Software PATTERNS

[@lolmaster7459]

Хорошие советы. Четвёртый год учусь, но все ещё ощущение, что до джуна не дотягиваю - балдёж

[@walson4708]

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

[@const1988]

@@walson4708 как такое может быть? Ты нашел работу?

[@walson4708]

@@const1988 Привет, нет, мало того, я попал в армию :с. Но ничего, осталось 51 день, пока был в армии удалось наладить контакт с 2 паблишерами (хоть что-то для начала), и собрать небольшую команду: Я: отвечаю за геймдизайн, документацию, архитектурную часть и игровую аналитику(с ней пока плохо) 2 3D artist'a - один больше шарит по окружениям, умеет работать по тз, в срокам и по пайплайну. Второй - любитель, но за него поручился первый. Sound designer - много лет пишет эмбиенты и не только, есть своя студия звукозаписи. С художниками проблема пока, хотя бы по интерфейсам найти. Для HK сегмента такой шарашкиной конторы хватит за глаза, единственное, когда на волю выйду, поищу второго программиста.

[@ruslanowlysadykov1558]

@@walson4708 имхо пробовать в инди геймдев без опыта работы в проф. команде - заведомо провальный план. Лучше устрой себе марафон тестовых заданий и разбора их ошибок, устройся джуном в тот же HK, посмотри как изнутри что работает и потом уже если захочешь рискнуть - пойдешь в инди. да и зачем такая команда, больше 90% HK игр не юзают уникальные звуки, их просто покупают с хостингов. с модельками тоже самое, быстрее и дешевле купить ассет, чем заставлять работать 3дшника, при том что никаких гарантий нет, возможно ваш видос не пройдет CTR тест и вся работа зря.

[@Tokarevbest]

Говорят джуном за полгода можно стать.

[@АлександрКузнецов-ш4н]

"комментарии это костыль" - комментарии это инструмент и в определенных ситуациях очень полезный. Может в играх это не так важно, но в крупных корпоративных проектах случаи когда залазиешь в какую-нибудь entity (\dto\poco), видишь ее поля и не можешь быстро понять а зачем они именно нужны (бизнес-смысл) - ситуация не редкая. И искать все ссылки на нее чтобы перечитать весь код или искать документацию в конфлюенсе, конечно, вариант, но это боль. Код это в первую очередь алгоритм и передача бизнес-контекста это лишь его побочная функция. Вкратце: если над некоторыми вещами вы будете оставлять комменты со ссылкой на документацию\таску, то коллеги вас будут любить

[@КлимНуралин-у4у]

Нет такой вещи которую нельзя декомпозировать даже в этом случае, но людям лень, и по сути они и допускают комментарии потому что им лень, и кстати, дто считается плохой идеей, Active Objects лучше делать, но тут 100% речь про легаси

[@ОлегПронин-и1т]

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

[@КлимНуралин-у4у]

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

[@КлимНуралин-у4у]

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

[@dmitrikonnov922]

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

[@vladislavvorzhev2375]

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

[@cimweed18]

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

[@cimweed18]

@@lekretka да у меня вообще проблемы с этим. Поэтому не работаю в компаниях

[@АнтонДудкевич]

@@alexandr_sirota ну да ну да. А бизнес ведь очень заинтересован, чтобы новички хер разгребли существующий код.

[@Kot-Alenya]

Правильный код - это идеальный баланс его красоты , удобства , надёжности и производительности.

[@bratttn]

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

[@imalllio]

​@@bratttnчушь! Правильный код это тот, который пушистый, вибрирующий, теплый и мяукающий!

[@stanislavsh6582]

Уже относительно размышлений о том что язык просто маленькая деталька возникают вопросы. Ну как. Мы можем много вещей делать на плюсах. Плюсы - великолепный язык. Но сможет ли человек который знает, допустим, шарп - въехать за неделю в проект на плюсах которому 10 лет, если этот человек - мидл-разработчик, который работал n лет с шарпом, а плюсы последний раз видел на лабах в вузе? А наоборот? Да нет. Нужно же знать не только язык и общие вещи, типа структур данных, алгоритмов, паттернов, нужно понимать модель памяти, как считаются ссылки, как в разных языках реализована работа с потоками, плюс минимально историю знать. Вот допустим в шарпе - есть Interlocked, в C++98 - не было как-то вынесено в стандарт многопоточное программирование и в итоге - кто как мог, так и делал, плюс в одних компиляторах i++ - потокобезопасно выполняется, у других - нет, у третьих - зависит. Я это к чему. К тому что специфики много и ее нужно знать для того чтобы не стрелять себе в колено. И ведь такие баги ты не на этапе компиляции поймаешь и даже тестами так просто не покроешь Ладно, смотрим дальше. Относительно стандартов и говнокода. Это вообще с какой-то стороны странная фигня началась. Ну как, при чем тут стандарты и прочее? Если я не использую '_' в именовании полей - теперь весь тот код внезапно стал говнокодом? А в остальном стандарты - нихрена не говорят. Они говорят как мы струкрурируем проект, как именуем что-то, сколько пробелов нужно вместо таба использовать и как оформать комментарии. Чисто по стандартам шарпа - я могу вполне взять и копипастнуть весь текст документа прямо в исходный код, вместо того чтобы из ресурсов его получать, в итоге - читать это будет невозможно, но все еще стандарты не нарушены. Получаем ситуацию - говнокод есть, стандарт не нарушен. Это к чему. К тому что говнокод, в привычном смысле: Оно делает то что от него хотят, но трогать это - не хочется. Все. Стандарты и объективность это сбоку стоит таки. Да, про опытных разработчиков. Вот есть офис дедов что на си с 2001 года пишут. Опытные? Да офигеть какие. Я прихожу красивый-молодой, пишу на шарпе, они теперь тоже. Но они - привыкли экономить на спичках, плюс им сама концепция ООП неприятна, хотя они и пишут на шарпе. Я делаю классы, делаю тесты, они хреначат статикой, а на тесты кладут болт(зачем тесты, если такие есть отдел QA? пусть они и тестируют). Если я позову их и попрошу отревьюить мой код - он для них будет говнокодом, как и их код для меня, потому что с одной стороны - процедурное программирование, с другой ООП и мы не сойдемся во мнении, по их логике - все эти SOLID - придумали евреии чтоб русских программистов дурачить и заставлять писать больше кода. А кто тут прав-то? Они опытны и при этом им не нравится ООП, я тоже не вчера кодить начал но мне сам подход ООПшный сразу вкатил. А сбоку стоит адепт функциональщины и рассказывает про лямбда-исчисление и что грядет страшный суд, на котором все кто не придут к функциональщине - будут наказаны. С остальным в принципе согласен. Да. Вот. Да.

[@RGcrasyRG]

Мне, например, дико не впирает концепция ООП когда классы перестают отображать объекты реально мира. А вот функциональщина доставляет: пишешь функцию, она делает одно. Хочешь усложнить? Используешь функцию, которая использует функцию... и т.д. Жаль только в энтерпрайзе нужна джава\шарпы, а не хаскелл с растом.

[@RGcrasyRG]

@@flexxxxer ну если это про кучу синтаксического сахара, который позволяет использовать ПОДХОД фп в том же си шарпе - то это немножечко не то. Тот же синтаксис хаскела для меня кажется лаконичным и прекрасеным.

[@АнтонДудкевич]

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

[@ArquitectoR]

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

[@limestoneMinecraft]

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

[@kirillsviderski4739]

"Никто не пишет большие классы". Рома, после этого я не плачу, мне просто сорцы анриала в глаз попали ХД

[@sergeyinozemcev1070]

И статиков тоже достаточно, но я согласен с автором. Unreal - это плохой код.

[@tyoma_yashin]

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

[@чибзик]

класс view в андроиде с 30к строк: я для вас шутка что ли?

[@Neon30]

аж слеза покатилась

[@babush6]

а автор вообще кто ? он в какой компании работал и в каких проектах участвовал ?

[@Fedorlesorub]

СуперДжун в очень большой компании, мне даже не дают писать код)) Больше верстка лц) Ноо, все советы сто проц рабочие, я прямо видел их реализацию у нас) Очень полезный видос, про реально важные вещи, спасибо!)

[@ProkerKusaka]

90% игр со статичным гейм менеджером приуныли

[@R3v0ult]

100%

[@kilinar2239]

@@R3v0ult Не 100 точно, может 99.99, я обычно через Синглтон пишу - да, да - поражайтесь глубине моего падения - антипаттерн и все такое. Но на мой взгляд он тут уместен.

[@kilinar2239]

@Гоша Ватюнга Интересно, пока не совсем понятно, буду разбираться. Спасибо.

[@Diyozen]

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

[@kilinar2239]

@@Diyozen Всегда полезно узнать что-то новое или посмотреть на что-то с другой стороны. Полезно ли будет - посмотрим.

[@TedFanat]

Соман Ракутин как всегда правду матку рубит, хуярит! Так держать!

[@Sergey.Aleksandrovich.P-37rus]

Пздц как рубит) советы годные... Хоть я и на Java пилю, но всегда чем то цепляет Ромыч.... 🤔

[@TheSmokySwan]

Я недавно стал джуном и пишу П.О на c++ и qml в основном. И вот например в qml , мне кажется комментарии бывают просто необходимы, в qml нередка ситуация , когда ты 1 элемент запихнул в другой элемент и его в третий, а это всё лежит ещё в каком-нибудь verticalLayout там столько фигурных скобок, что путаешься , что к чему относится поэтому я в их начале и конце пишу комментарий. Например: //начало Button, //конец Button.

[@ДенисКорделюк]

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

[@jet4904]

Подлизал так подлизал

[@karpovantonio]

ну че шиз, выучил? или все шторки собираешь?

[@johnyelasto]

Шиз 🥹

[@alexh1904]

Насчёт удаления кода: Да. Часто так бывает, я бы даже сказал в 99% случаев, когда алгоритм пишется с большим трудом. И потом и потом, может даже через несколько дней, ты в этой же программе пишешь какой-то следующий алгоритм попроще, и его сигнатура перекликается с тем сложным алгоритмом и ты видишь решение более эффективное для предыдущей задачи. Тогда да, переписываешь первый алгоритм удаляя предыдущий. Но нужно помнить о следующих моментах: 1) не изобретай велосипед. 2) оставляй лучший код удаляя говно 3) При использовании чужого кода, внимательно изучай чужой код, быть может твой окажется лучше.

[@nooftube2541]

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

[@Gexetr]

Начал изучать язык C и уже написал свою доту2. Решил посмотреть для себя 10 советов, а он тут про какое-то ООП рассказывает почти все советы. Удовлетворён

[@АрсланГаджиев-ж5ж]

А где обучился на C ???? И сколько заняло обучение по времени???

[@ricardomilos857]

@@АрсланГаджиев-ж5ж интернет...

[@АрсланГаджиев-ж5ж]

@@ricardomilos857 а можешь скинуть ссылки для обучения

[@ricardomilos857]

@@АрсланГаджиев-ж5ж а какая разница язык си это или паскаль? учи не язык, а направление в программировании

[@АрсланГаджиев-ж5ж]

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

[@user-zq1fx8fq1u]

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

[@darkproject8068]

Если декомпозировать задачу слишком долго, она перестанет существовать (с) Умный дядька

[@behappianstudio3576]

Опять добрый Рома! Выздоравливай))

[@assetslambekov2449]

Самый объективный it блогер) Все по делу сказал, респект

[@omegakrakengames]

Очень хороший и важный комментарий для продвижения видео

[@СтороннийНаблюдатель-ч6ф]

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

[@jv_en_py3667]

Роман разлогинься

[@Hafune]

Cтатику можно если объект не содержит состояния. Всякие там Math например.

[@hematogen50g]

Воистину, но думаю тут Рома имел ввиду статику, которую маслятки юзают для совершенно низменных целей.

[@rsakutin]

>объект >без состояния Понимаю

[@КлимНуралин-у4у]

Ну я успел всех заебать с Бугаенко, но там одно из первых в Elegant Objects это лучше раскрывается, операцию например в виде статического метода желательно заменять на объект содержащий результат операции через свойство типа Value, и всякие Math были реализованы без оглядки на это, однако со своим кодом лучше уж сделать как выше описал

[@Hafune]

@@rsakutin ещё бы примеры почему нельзя то и то, насчёт статики думаю хороший пример -> сделать перезапуск игры(без выключения клиента конечно). Вот тут то статика и покажет себя.

[@mdvulfix]

Отличные советы, спасибо! Очень много почерпнул из твоих предыдущих видео. Продолжай в том же духе!)

[@hematogen50g]

И ты продолжай изучать и программировать. practice makes perfect.

[@sergeyinozemcev1070]

Все стандартные контейнеры в std - это гигантские простыни, к слову.

[@ikao3834]

Это легаси.

[@МаксимНосарев]

Да... Декомпозиция конечно для меня это беда. Постоянно пишу монструозные классы, надо бы попинать себя уже и порубить в паре проектов их по уму)

[@hematogen50g]

Главное не ленится. начни с малого - сначала один метод напиши, самый простой. и т.д.

[@КлимНуралин-у4у]

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

[@vanyasotnikoff6024]

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

[@ВладНещамаев]

Когда Роман начал говорить "просто напомню" сразу промотал на две минуты вперёд

[@SergeySvotin]

10:57 не совсем согласен, в большинстве случаев, конечно, так, но, когда случается, что необходимо написать скрипт на js в проекте на java, то даже нейминг не очень помогает, потому что, по сути, твой код раскидан по трем разным файлам: java код, js-код и коннектор, в котором может быть определена некоторая js-функция-коллбжк. Я стараюсь код на не основном для проекта языке максимально комментировать (кроме того, что я пояснения в МР делаю), иначе придет следующий разработчик на основном языке, он это просто не поймет. Но пишу я, конечно, не столько, ЧТО делает код, сколько ЗАЧЕМ

[@vanyasotnikoff6024]

Я бы дал самый главный совет - не воспринимайте советы как руководство к действию. Потому что разные программисты решают разные задачи и у каждого формируется свое видение. Более того, мышление у людей не одинаковое. Не нужно искать серебрянную пулю. Все как в жизни, не все однозначно. Хотя с опытом вы найдете свои ответы. Опять все как в любой другой деятельности, все приходит с опытом.

[@СерёгаСокольский]

Сама команда Майкрософт внедрила в VS2019 подсказку. Звучит примерно так: "Метод не обращается к членам экземпляра. Можно пометить, как static."

[@evon2543]

А потом, когда нужно будет обратиться, то внезапно пол-проекта придётся переписывать.

[@СерёгаСокольский]

@@evon2543 уже нельзя. Будет нарушен принцип открыт / закрыт. Нельзя модифицировать метод. Пиши новый метод или метод расширения.

[@afterjourney4304]

Про статик очень спорно, та же архитектура Unity или UE с кучей static методов в классах. Мы ведь не скажем что там код говно, верно?) Да и программисты я думаю, там на порядок компетентны в вопросе проектирования. Если программист яростно бомбит на статик, то у него ООП головного мозга.

[@МихаилСуворов-к2щ]

Первые версии Unity писали не опытные студенты. И Весь говнокод, который тянется с тех лет там живёт до сих пор. Если бы Unity был хорошо написан, то его бы явно не хотели бы переписывать в Untity 5 в 201 году и сейчас перtход на новую архитектуру на основе DOTS

[@afterjourney4304]

@@МихаилСуворов-к2щ Эта архитектура отличается от ООП, поэтому речь о статик в априори бессмысленна, по крайне мере, пока не узнаем детали реализации DOTS

[@eugene-white-shark]

@@lekretka Индусы поумнее многих русских.

[@grayhouse6925]

@@МихаилСуворов-к2щ вы енамами пользуетесь? Или утил классами типа Math? )) всегда, когба говорят что статики плохо- задаю эти 2 вопроса)

[@КлимНуралин-у4у]

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

[@bomb5994]

Недавно была серия постов с троллингом

[@КлимНуралин-у4у]

@@bomb5994 уже понел

[@dreamy6096]

Если комментарии зло, то зачем они в каждом ЯП'е?

[@my_noname_channel]

Поверю, что static - это плохо-плохо-плохо-недопустимо, когда встречу фреймворк, который не требует использовать свои статик-классы/методы, чтобы вообще хоть что-нибудь сделать. А если Майкрософт не смог написать без статиков, то сложно требовать того же от каждого первого программиста.

[@grayhouse6925]

В целом верно и вещи правильные. Но с двумя моментами я не согласшусь. 1. Комменты нужны. Но нормальные. Над классом, над методами(функциями) зачем, (иногба почему именно такой подход). 1 строка обычно для хорошей функции достаточна если функция нормальная. Для чего нужно? Банально новый разработчик вкатится гораздо быстрее, какой бы код хороший небыл. Или для генерации вики например. Это важно, когда проект реально большой, когда ты даже можешь не знать бОльшую часть комманды. Как говорится, код пишут для людей 2. Статик классы. Тоже поспорю. Есть минимум 2 типа статик , которые оправданы в программе. Наборы Констант и утил классы. Первые - эт в подавляющем большинстве енамы (внезапно по сути - это набор элементов, доступных статически). По утил классам типа Math и т.п зачем создавать много экземпляров? А если сингтон, то тогда какой смысл пихать его в конструктор или получать инстанс статически? Оправдано будет делать такие вещи не статик, если у тебя есть контракт (интерфейс) и несколько реализаций. Тогда конечно, интерфейс в конструктор, твой класс работает с контрактом, а реализацию уже инжектишь нужную. А в остальном лайк, в люьом случае полезно

[@MrGourmetRazzy]

14:10 "Нельзя пройти ревью, если есть код с модификатором static" Тем временем: *static* void Main(string[] args) *YOU SHALL NOT PASS!!!*

[@alexanderalexander1637]

мы наблюдаем рождение и становление Великого Инквизитора C#

[@headhuntez]

спасибо за инфу. а как же статические методы расширения? например public static void WriteLine(this T message) => Console.WriteLine(message); public static T RandomElement(this IEnumerable elements) => elements.ElementAt(Random.Shared.Next(0, elements.Count()));

[@zaironslaysert5159]

Статические методы это когда обращение идет напрямую ? А тут указывалось про то что все ходы должны быть расписаны что зачем запускает открывается ? то есть коде расписать полную цепочку действий от а до я а не прямое действие сразу с начала в конец Я просто ничего не понимаю в этом и решил спросить правильно ли я понял XD

[@headhuntez]

@@zaironslaysert5159 да обращаешься не к екземпляру а к типу DateTime.DaysInMonth(2023, 1)

[@SergeySvotin]

7:25 таким людям легко объяснить: говнокод объективен, потому что само преятие "говнокод" - это не значит, что у тебя есть несколько ошибок в коде, это значит, что бОльшая часть твоего кода состоит из ошибок. Если у тебя парочка неточностей, говнокодом не общовут, просто пометят для исправления и примут потом, а вот если у тебя вообще все неправильною настолько, что вычленить что-то полезное - тяжелая задача, то вот это уже говнокод. Лучше стереть все и написать заново

[@LordZiegfrid]

Чувак, приватный статический метод это норма. Смысл таскать this там где он не нужен - нету, приватная статика часть реализации и все норм внедряется.

[@hematogen50g]

По мне так главное, чтобы вашими прогами пользовались. Тогда от этого есть смысл, а иначе ваше прогерство сродни артхаусу.

[@КлимНуралин-у4у]

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

[@hematogen50g]

@@КлимНуралин-у4у Обожаю ютуб. Можно получать ответы на свои вопросы.

[@КлимНуралин-у4у]

@@hematogen50g тогда стак оверфлоу получше будет

[@КлимНуралин-у4у]

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

[@easycodeunity3d14]

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

[@xezdx]

Статик не поэтому плохо. Думаю много есть аргументов в пользу и против. Я использую только тогда когда эти методы ничего не меняют и являются чистыми функциями. Но если они начинают хранить состояния тут уже появляется проблема их инициализации, очистки и т.п. Один из минусов юнити - ПОЧТИ ВО ВСЕХ мануалах рассказывается как юнити порождает объекты и любой программист задается вопросом "а как потом объект найти, получить доступ к нему, обратиться к или от него к ядру игры" и получается что статика самый простой способ сделать это. Но это вовсе не значит что это хорошо, это так архитектура юните сделана. Меня лично бомбит от того что про архитектуру игры сложнее прыгающего болванчика нигде не рассказывают, чтобы не иметь этих проблем, можно только мельком увидеть в каких-то проектах сцены типа init со стартовыми скриптами и поставив на паузу пытаться рассмотреть.

[@EBIIaTuu_KoJIoBpaTuu]

Мельком в видосе упоминалось про GRASP, а я хочу для себя уточнить, насколько оно практически полезно? Т.е. я понимаю и использую ООП и СОЛИД, но не особо понимаю бенефитов от ГРАСП, не мог бы кто-нибудь объяснить?)

[@LordZiegfrid]

Солид оттуда вытекает, единая обязанность из информейшан экспер например

[@xezdx]

Смысл как обычно в том, чтобы сделать программу поддерживаемой. Чем меньше запутанность, тем лучше. Но мне эти принципы не нравятся, потому что задачи бывают очень разные и принимать решение об ответственности кто управляет, а кто управляемый, приходится всякий раз руководствуюсь более сложными аргументами, чем там описаны. По мне так самое главное это KISS - Keep it simple, stupid. Если вызовов слишком много, если параметров в методе слишком много, если метод слишком длинный, если в классе слишком много методов, если зависимостей много и т.д. то скорее всего этот код делает слишком много разных вещей и их можно разбить. Не факт, но "скорее всего".

[@cotulars]

Привет, знаю что не ответишь но всё же... За сколько я могу получить от тебя кодревью(ну т.е. оценку кода) на яве?) Ну просто покупать курс по шарпу для меня дороговато, а ревью от тебя увидеть хочется...

[@hakari_]

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

[@ikao3834]

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

[@АлександрСоловьев-ю9ц2к]

Намного увеличивает продуктивность (нет проблем "накатал простыню не в той раскладке и с опечатками") и улучшает здоровье (постоянно бегающий туда-сюда взгляд еще быстрее сажает зрение и быстрее вызывает утомляемость).

[@ikao3834]

@@АлександрСоловьев-ю9ц2к покажи пример где ты пишешь быстро нормальный код

[@АртемСавельев-п8и]

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

[@EdwardNorthwind]

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

[@АлександрЦарегородцев-х4я]

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

[@romanbush5164]

Блят кто бы мне сказал десять лет назад, что программирования это не только язык программирования!?!!!**$*

[@kilinar2239]

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

[@КлимНуралин-у4у]

Разницы особо не будет, если заменить такой статический метод на объект который представляет результат операции

[@hexagon4326]

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

[@rsakutin]

0-9 - суммарно 10

[@hexagon4326]

@@rsakutin а вступление тоже считается или я где-то 2 в 1 пропустил?

[@user-kp4xy7iu9e]

Коментарии зло... Ну если в стиле капитана очевидности, то да. А если писать по делу, то сохранит очень много времени, например почему мы выбрали то или иное решение(стукруту данных, алгоритм и т.д.), прокоментировать аргументы функций \ возвращаемое значение (где может быть не очевидно без просмотра тела функции) и прочее.

[@art61017]

Комментарии должны предупреждать о подводных камнях в коде, иногда объяснять "почему выбран именно этот способ решения задачи", что, как правило, уместно для промышленного кода. Например, проблемы могут быть в сторонних библиотеках, а отправить pull request разработчику и дождаться выхода следующей стабильной версии не всем подходит. Также для сложных алгоритмов, автоматизации инженерных задач и т.п., будет очень наивно полагать, что другие разрабы целиком и полностью понимают работу того, что вы делаете. Да, возможно, код с комментариями - "плохой код", но в Java и Python (возможно также на Си или в ассемблер-кодах) - это зачастую бывает вынужденным злом.

[@АнтонДудкевич]

Код с комментариями - хороший код. Просто комментарии должны объяснять не что делает код (из хорошего кода это должно быть понятно), а зачем.

[@ArquitectoR]

@@АнтонДудкевич именно так, автор похоже сам ни разу в разработке какого-нибудь крупного проекта не участвовал. Если он только казуалки на Юнити пишет командой 2-3 программиста + дизайнеры, то ему может и не нужны комментарии. В простых проектах всё сильно проще.

[@Degril]

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

[@ВладиславАфанасьев-й7г]

А как данные между сценами передавать, если без статика.

[@ggfycest4571]

Запретить статические классы?? А математические методы куда вынесешь??

[@babush6]

для него такие сложные вопросы это сложно

[@TestSub1000]

Крутой канал, первый раз попал на тебя. даже непонятно, цыган ты или право имеешь 🤣🤣

[@vovanchik_ru4208]

а как же экстеншены со статикой?

[@Бот5329-и5г]

А если у класса будет метод который будет общий для всех его экземпляров то что вызывать его у каждого экземпляра или сделать его статическим?

[@osore_7875]

Половина советов основы ооп.

[@sbm31337]

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

[@kodomo5490]

Роман, если в программе есть класс с методами вроде "сохранить информацию в файл"/"загрузить информацию из файла", такой класс тоже нельзя делать статическим?

[@rsakutin]

Вы процедурно мыслите

[@excommunicado2932]

Почему не сделать некий объект типа File с методом .Save( ) / .SaveTo(path) ? И, например, объект типа Document с методом .Content( ). Будет: а) более поддерживаемо (как минимум можно задекорировать (паттерн декоратор) каждый объект б) все необходимое инкапсулируется в объект и нет необходимости руками "передавать" данные от одной процедуры/функции к другой в) интерфейс IDocument (/ абстрактный класс в крайнем случае) даст полиморфизм и, например, DI. к примеру сделать класс для асинхронного чтения данных с тем же типом IDocument г) никакой связанности между функциями, которые вы хотите создать, не будет. у каждого класса своя ответственность. То, что вы хотите создать, это не ООП, а библиотека процедур как в языке С. д) отдельный класс (имхо) проще тестировать.

[@hematogen50g]

Можно сделать статические методы в динамическом классе. Будет куда более ООПэшненько.

[@excommunicado2932]

@@hematogen50g не соглашусь, в ООП вообще ключевое слово "static" лишнее. И использовать его бы следовало в крайнем случае только. Например, сильная нужда в производительности, так как создание объекта в куче, естественно, дороже. Но по важности (имхо) перформанс < качество кода (в смысле основной задачи разработчика)

[@hematogen50g]

@@excommunicado2932 То есть методы из классов типа Math это исключения из правил. По факту они статические, но их юзают в ООП и норм.

[@mrklebold4480]

Совет 6 к разработке ПО (бекенда) на Java тоже применим?

[@АлександрГлебов-х4я]

Вообще, по Троелсону, статику выгодно использовать для обслуживающих классов.

[@CodeWriter]

Мне подписчик как-то написал что gовно код позволяет проявить фантазию в программировании, а опытные программисты которые придерживаются правил ограничены в программировании. Что ты думаешь по этому поводу? Пхахпхах

[@rsakutin]

Думаю стоит забанить придурка

[@Vander0_0]

@@rsakutin Хахахахахаха а ловко ты это придумал

[@chemistryege]

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

[@kirillsviderski4739]

@@chemistryege Хороший код и помогает сходу вводить любые творческие эксперименты

[@hematogen50g]

Думаю он использовал логику проф. киберспорта - матчи по старкрафту ГМЛ куда скучнее смотреть, чем любительские. Т.к. грандмастера играют почти всегда одинаково, у них все стратки заучены и они не могут поступить иначе. Думаю в прогерстве так же. Что и отличает любителя от профессионала. Первый романтик, второй - прагматик.

[@oldborodach]

Что в начале все же нужно изучать С# или сам движок Unity? 🤯 А то один одно другой другое мнения разнятся. Кстати и почему? Короче совет нужен и по литературе и нужна ли она вообще в начале?

[@yt78455]

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

[@oldborodach]

@@yt78455 согласен, но интересно знать мнение экспертов!

[@yt78455]

@@oldborodach пни, если тебе ответит кто-нибудь компетентный, тоже интересно

[@oldborodach]

@@yt78455 оставь контакт для связи скину кое что!

[@ProkerKusaka]

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

[@Cefalet]

Роман, вы говорите, что static новичкам использовать нельзя совсем никак и никогда, потому то это нарушает граф объектов и новички должны учиться пробрасывать зависимости и всё такое... Но как, например, насчёт перегрузки операторов? Для объявления перегрузки оператора нужно написать и public и static в одном месте. Неужели и перегрузка операторов - это плохо?

[@ArquitectoR]

Ну такое, перегружать операторы надо очень аккуратно. Джунам лучше в эту сторону не думать.

[@АлинаЛебедева-м5ь]

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

[@ИапГоревич]

Ну, про синглтоны - это спорное утверждение

[@-urdy]

👾

[@Zhangeldi1023]

👍👍👍

[@sevenlands2354]

10 вещей которые ты обязан знать , а советов всего 9 :D

[@КлимНуралин-у4у]

Нумерация с нуля

[@sevenlands2354]

@@КлимНуралин-у4уТочно как я мог не увидеть 0 ))) вот только идет она до Компота под номером 8

[@xelax3613]

блин придется удалять static void main

[@MrFalaban]

Как же проектирование, Роман? Я думаю важно уметь продумать задачу перед началом

[@Maksimeo]

согласен

[@Вебразработка-м2г]

чего у парня в видео шея обосцана?

[@SergeySvotin]

7:25 тут даже не суть в том, что скажуттслучайные 10 "опытных" разработчиков, паттерны проектирования, например, вырабатывались десятки лет, методом проб и ошибок, глупо надеяться, что ты один такой у мамы умный, что 30 лет развития перечеркнешь. На ЯП пишут спецификации, с некоторыми пунктами можно спорить, но суть-то в том, что программистов много, если каждый будет писать по-своему - хрен вы что соберете, поэтому и нужен стандарт, кто-то его должен продумать. Логично, что стандарты ЯП придумывают авторы ЯП, уж они-то точно разбираются в тонкостях своего языка

[@bratttn]

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

[@vladyan01]

Сегодня впервые скачал юнити, до этого на другом движке работал. И методом тыка сделать кнопку UI и текст, и сделал по нажатию кнопки прибавление +1 в тексте, и создал АПК для теста на тлф. Вопрос: какого хрена АПК файл весит 18 мб, должен с таким функционалом 1-2 мб весить же. Я ахринел какой багаж юнити впихивает.

[@kaidozdev]

такую херню высрал. ты видимо ещё ни разу с xamarin не работал

[@itnoob7379]

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

[@CtrlAltDente]

Не расстраивайся) А вообще то желательно прочитать книги по программированию (не языкам), и глянуть стандарты и общепринятые методы, чтобы +/- что-то понимать. Хотя с обратной стороны, у каждого свои собственные стандарты, и ты не можешь предугадать в какой компании будут свои локальные стандарты. И я уж не говорю о том что некоторые примеры в одной книге могут прямо противоречить примеру в другой книге. Но банально те факты что именовать переменные надо так чтобы они отображали свою суть и код должен выглядеть читабельным с учётом отступов через Tab (не встречал чего-то другого) никто не отменял. Желательно вообще устроиться в компанию на первые строки заявляя что опыта у тебя 0.000000003 и ты готов "рвать и метать" лишь бы научиться чему-то новому и хорошему, даже не упоминая о ЗП. А уж более опытные тебе в этом помогут, и литературу дадут, и может задания даже. Конечно тут на самом деле как повезёт.

[@Digildon]

13:47 Синглтоны не нужны?

[@timurnikolaev1438]

12500 За кофту? можно две

[@markhabaevv5770]

Стоит ли практиковаться на сайтах типа Leetcode, иль стоит пробовать сфокусироваться на любительских проектах?

[@KALMAPUK]

И так и так правильно.

[@ikao3834]

Не используйте "static", а как же к примеру методы расширения существующих типов?

[@КлимНуралин-у4у]

Можно кнеш, методы расширения семантически относятся к расширяемому классу, да и название такого статического класса вроде чаще всего понятно

[@sbm31337]

Он сказал "приватные члены" ...

[@dimaq4428]

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

[@EBIIaTuu_KoJIoBpaTuu]

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

[@CoRecYT]

У тебя получилось из-за баланса белого, будто нижняя часть экрана в кинематографичной чёрной полоске) Надо либо поменять одежду, либо место съёмки, либо подкрутить камеру.

[@mrsgonzaa]

Если выкрутить баланс белого, цвета на стене будут бледными. Тут либо добавить контровой свет, которого в данный момент нет, либо сменить одежду. P.S. Нижняя часть экрана как в кино называется экранное каше.

[@vanyasotnikoff6024]

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

[@КлинокСтальной]

Классный худи)). Такая говорящая голова получается))).

[@yatsuk_vitalii]

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

[@iamdozerq]

Речь идет не о классе math, который статический на 100%, а о твоих собственных сущностях. Когда делаешь математику там все на 100% функциональщина. Я расчеты по учебе автоматизировал много - там ооп негде применить, а самое главное не за чем.

[@yatsuk_vitalii]

@@iamdozerq Спасибо

[@nightyonetwothree]

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

[@InqDan]

Переведите это и отправьте яндере деву.

[@kilinar2239]

Не поможет. И ему нужно кидать книгу: "Программирование на C# для начинающих" или что-то в том же роде. Но даже так, это не поможет по причинам, описанным вышестоящим комментатором.

[@dippe2261]

Привет Рома! У меня возник вопрос, вот что мне делать? Я учусь в универе, щас на втором курсе, но программировать не умею. Если дают задание, то всегда прихожу к тому что ищу ответ в инете, а сам ничего не могу сделать. Может быть ты сможешь что-то посоветовать, чтобы я смог понять алгоритмы и ваще как писать. А то всегда я понимал что если хочу стать программистом то надо учить язык программирование, но в итоге язык знаю, а программировать нет.

[@twojger8242]

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

[@K-RACUBO]

Совет 0: Только программист начнёт с 0

[@Saprovec]

Математика - это не алгоритмы, бля...

[@ourtube5191]

там тоже затрагивается тема алгоритмов

[@Saprovec]

@@ourtube5191 где там?))

[@ourtube5191]

@@Saprovec в школьной математике

[@Saprovec]

@@ourtube5191 дай ссылку))

[@Saprovec]

@@ourtube5191 Логика - относится к алгоритмам, а не математика. Открою тебе секрет. ))

[@ostrov11]

... чувак, что у тебя с шеей со стороны горла ???

[@Vander0_0]

Как ты начинал учить программирование ?

[@fgyly78]

14:53 Точка входа Main: За что?

[@АлександрКоллеров-ц7ъ]

Хех тоже считаешь с нуля красва😜

[@codememory]

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

[@mrxprojects]

Не обращай внимания, он некомпетентен.

[@codememory]

@@mrxprojects Оно и видно! Других критикует, а сам нифига не знает, я б советовал ему курсы пройти по джуну! Кстати, пускай тест пройдёт в прямом эфире на джуна, посмотрим его уровень 😂

[@kaidozdev]

сакутин противоречит сам себе? пару дней назад говорил, что ничего такого нет, если использовать статик (про вывод логов) и в видео теперь говорит, что статик это хуево и ТОЛЬКО В РЕДКИХ ИСКЛЮЧЕНИЯХ нормально.

[@СтороннийНаблюдатель-ч6ф]

Для логов не надо использовать статик.

[@vasiliychernov2123]

Тот пост был толстым вбросом