@@R3v0ult Не 100 точно, может 99.99, я обычно через Синглтон пишу - да, да - поражайтесь глубине моего падения - антипаттерн и все такое. Но на мой взгляд он тут уместен.
@Гоша Ватюнга совет охуенный. Особенно, учитывая, что DI, зачастую - это тот же самый синглтон. Ещё и какие-то надмозги нашли остроумным внедрять зависимости прямо в поля.
Да, такое же ощущение, 4 года варюсь в этом говне, на первый год обучения был экспоненциальный рост, потом стагнация, потом упадок. Сейчас я ниже уровня первого года, вообще не знаю, что делать.
@@const1988 Привет, нет, мало того, я попал в армию :с. Но ничего, осталось 51 день, пока был в армии удалось наладить контакт с 2 паблишерами (хоть что-то для начала), и собрать небольшую команду: Я: отвечаю за геймдизайн, документацию, архитектурную часть и игровую аналитику(с ней пока плохо) 2 3D artist'a - один больше шарит по окружениям, умеет работать по тз, в срокам и по пайплайну. Второй - любитель, но за него поручился первый. Sound designer - много лет пишет эмбиенты и не только, есть своя студия звукозаписи. С художниками проблема пока, хотя бы по интерфейсам найти. Для HK сегмента такой шарашкиной конторы хватит за глаза, единственное, когда на волю выйду, поищу второго программиста.
@@walson4708 имхо пробовать в инди геймдев без опыта работы в проф. команде - заведомо провальный план. Лучше устрой себе марафон тестовых заданий и разбора их ошибок, устройся джуном в тот же HK, посмотри как изнутри что работает и потом уже если захочешь рискнуть - пойдешь в инди. да и зачем такая команда, больше 90% HK игр не юзают уникальные звуки, их просто покупают с хостингов. с модельками тоже самое, быстрее и дешевле купить ассет, чем заставлять работать 3дшника, при том что никаких гарантий нет, возможно ваш видос не пройдет CTR тест и вся работа зря.
7:19 А зачем вообще для подтверждения тезиса об объективности говнокода нужно апеллировать к "объективным стандартам", принятым на каком-то волшебном великом соборе, мнению толпы "профессиональных" разработчиков и т.д., если это все не объективные критерии? Мнение собора - не объективно, мнение людей с большой татуировкой "Профессиональный разработчик" на пузе - не объективно. Почему бы просто не сказать, что критерием качества кода является предоставляемая им возможность поддерживать его с наименьшей затратой ресурсов, в частности времени? Например, когда в этом коде нужно разбираться людям, его не писавшим, либо самому автору кода после длительного перерыва в работе с ним. Как человека согласного с позицией об объективности критериев качества кода меня крайне смущает отсутствие аргументов в её защиту в словах Романа при наличии в них лишь апелляции к авторитетам.
Уже относительно размышлений о том что язык просто маленькая деталька возникают вопросы. Ну как. Мы можем много вещей делать на плюсах. Плюсы - великолепный язык. Но сможет ли человек который знает, допустим, шарп - въехать за неделю в проект на плюсах которому 10 лет, если этот человек - мидл-разработчик, который работал n лет с шарпом, а плюсы последний раз видел на лабах в вузе? А наоборот? Да нет. Нужно же знать не только язык и общие вещи, типа структур данных, алгоритмов, паттернов, нужно понимать модель памяти, как считаются ссылки, как в разных языках реализована работа с потоками, плюс минимально историю знать. Вот допустим в шарпе - есть Interlocked, в C++98 - не было как-то вынесено в стандарт многопоточное программирование и в итоге - кто как мог, так и делал, плюс в одних компиляторах i++ - потокобезопасно выполняется, у других - нет, у третьих - зависит. Я это к чему. К тому что специфики много и ее нужно знать для того чтобы не стрелять себе в колено. И ведь такие баги ты не на этапе компиляции поймаешь и даже тестами так просто не покроешь Ладно, смотрим дальше. Относительно стандартов и говнокода. Это вообще с какой-то стороны странная фигня началась. Ну как, при чем тут стандарты и прочее? Если я не использую '_' в именовании полей - теперь весь тот код внезапно стал говнокодом? А в остальном стандарты - нихрена не говорят. Они говорят как мы струкрурируем проект, как именуем что-то, сколько пробелов нужно вместо таба использовать и как оформать комментарии. Чисто по стандартам шарпа - я могу вполне взять и копипастнуть весь текст документа прямо в исходный код, вместо того чтобы из ресурсов его получать, в итоге - читать это будет невозможно, но все еще стандарты не нарушены. Получаем ситуацию - говнокод есть, стандарт не нарушен. Это к чему. К тому что говнокод, в привычном смысле: Оно делает то что от него хотят, но трогать это - не хочется. Все. Стандарты и объективность это сбоку стоит таки. Да, про опытных разработчиков. Вот есть офис дедов что на си с 2001 года пишут. Опытные? Да офигеть какие. Я прихожу красивый-молодой, пишу на шарпе, они теперь тоже. Но они - привыкли экономить на спичках, плюс им сама концепция ООП неприятна, хотя они и пишут на шарпе. Я делаю классы, делаю тесты, они хреначат статикой, а на тесты кладут болт(зачем тесты, если такие есть отдел QA? пусть они и тестируют). Если я позову их и попрошу отревьюить мой код - он для них будет говнокодом, как и их код для меня, потому что с одной стороны - процедурное программирование, с другой ООП и мы не сойдемся во мнении, по их логике - все эти SOLID - придумали евреии чтоб русских программистов дурачить и заставлять писать больше кода. А кто тут прав-то? Они опытны и при этом им не нравится ООП, я тоже не вчера кодить начал но мне сам подход ООПшный сразу вкатил. А сбоку стоит адепт функциональщины и рассказывает про лямбда-исчисление и что грядет страшный суд, на котором все кто не придут к функциональщине - будут наказаны. С остальным в принципе согласен. Да. Вот. Да.
Мне, например, дико не впирает концепция ООП когда классы перестают отображать объекты реально мира. А вот функциональщина доставляет: пишешь функцию, она делает одно. Хочешь усложнить? Используешь функцию, которая использует функцию... и т.д. Жаль только в энтерпрайзе нужна джава\шарпы, а не хаскелл с растом.
@@flexxxxer ну если это про кучу синтаксического сахара, который позволяет использовать ПОДХОД фп в том же си шарпе - то это немножечко не то. Тот же синтаксис хаскела для меня кажется лаконичным и прекрасеным.
Кроме того, по конкретному языку надо знать фреймворки, стандартную библиотеку, доп.библиотеки. Понятно, что автор имел в виду, но все же, язык - не мелкая деталька.
Правильно всё пишете. Есть похожие ЯП, но есть и очень разные. Есть разные парадигмы, разные типизации, разные подходы к конкурентности и к метапрограммированию. Пока вы со всем этим разберётесь вы уже больше десятка ЯП будете знать. Ну или не захотите а это погружаться, застрянете на уровне миддла и пойдёте учить желающих войти в IT 😂
"комментарии это костыль" - комментарии это инструмент и в определенных ситуациях очень полезный. Может в играх это не так важно, но в крупных корпоративных проектах случаи когда залазиешь в какую-нибудь entity (\dto\poco), видишь ее поля и не можешь быстро понять а зачем они именно нужны (бизнес-смысл) - ситуация не редкая. И искать все ссылки на нее чтобы перечитать весь код или искать документацию в конфлюенсе, конечно, вариант, но это боль. Код это в первую очередь алгоритм и передача бизнес-контекста это лишь его побочная функция. Вкратце: если над некоторыми вещами вы будете оставлять комменты со ссылкой на документацию\таску, то коллеги вас будут любить
Нет такой вещи которую нельзя декомпозировать даже в этом случае, но людям лень, и по сути они и допускают комментарии потому что им лень, и кстати, дто считается плохой идеей, Active Objects лучше делать, но тут 100% речь про легаси
@@КлимНуралин-у4у как будто нет никаких других причин, чтобы оставлять комментарии. Я покупаю скрипты у программистов и в коде ориентируюсь плохо. Комментарии мне помогают понимать как быстро сделать то-то и то-то. Точно так же я оставляю комментарии в сервисах, где строю блоки без кода. Потому что я то всё понимаю. А туда может зайти заказчик, проджект, помощник чей-нибудь. И им придётся вызывать меня из-за какой-то мелочи, которую они могли бы решить и разобраться сами, если бы там были комментарии.
@@ОлегПронин-и1т вообще это тема того, что до меня недавно дошло. Создание объектной модели это достаточно эвристический процесс, иерархичность модели и контракт объектов позволяет делать очень понятным всё что происходит в коде и достаточно исчерпывающим, только за счёт того что человеку проще составить аналогию из реального мира для того что он читает в коде. У меня вот проект стратегии есть, есть понятия "Кусок карты", "Прямоугольник выделения куска карты", "Стоимость куска карты", так и названы классы, кусок карты агрегирует стоимость куска карты и прямоугольник выделения. Из этого простого примера мы уже знаем где искать функциональность в рамках этих понятий. Мы можем просто утилити классы создать под детали реализации этих функциональностей, если ты немного в математике шаришь то в принципе будешь приватные методы называть математическими именами, офигенно а? И дело в том, что всё это для более сложных систем тоже работает, только нужно к построению модели отнестись серьезнее а не на ходу придумывать. А в ситуации где хочется сделать человекопонимаемые модули реализации объекта в модели можно пользоваться MV паттернами, вообще всё предельно просто становится. В ситуации где ты не пишешь с нуля систему а допиливаешь что то в крупной это не значит что ты не можешь пользоваться приёмами построения объектной модели и не придумать подходящее имя для куска кода что ты пишешь
@@ОлегПронин-и1т на самом деле да, если куча авторов кода и как то всё надо связывать то по идее да то это нереально без комментариев, но это та самая ситуация где по идее проект только для первой версии в основном чтоли
Я считаю, что комментарии должны быть написаны строго по стандартам. В библиотечных классах и утилитах каждый публичные метод должен иметь стандартизованный комментарий. Мы же все любим, когда идешечка нам говорит, что метод делает, какие параметры принимает, что возвращает, какие исключения кидает. И ещё примерчики. Но вот комментирвание отдельных строк кода - это ебанина, только если мы не используем какие-то магические значения. Ну и комментирование не по стандарту - это бесполезное комментирование.
Много спорного, но насчет комментариев - можно открыть практически любой серьезный open source проект, и увидеть, что там в каждом файле есть комментарии с пояснениями. Хотя с утверждением о том, что хороший код - это самодокументируемый код, поспорить сложно.
Фростбайт с оберткой графического апи в 25к строк в одном файле в статике передает привет) Но да, для начала все-таки нужно знать правила, чтобы их красиво нарушать
Говно советы от "мастера". Комментарии должны быть в заголовке метода или класса, чтобы было понятно, что делает этот метод или класс без необходимости смотреть код этого метода/класса. Статику вовсю рекомендуют использовать, когда не изменяется состояние конкретного объекта.
Ну все таки комменты иногда нужны, только они должны описывать не происходящие а причину существования этого кода, и не всегда это можно зарефакторить так что бы это было самодокументирование. Например соответствие какому нибудь рфс. Да и к тому же в реальной жизни куча легаси зачустую дурно пахнущего, который рефакторить нет возможности и постфактумные комменты очень спасают.
Про статик очень спорно, та же архитектура Unity или UE с кучей static методов в классах. Мы ведь не скажем что там код говно, верно?) Да и программисты я думаю, там на порядок компетентны в вопросе проектирования. Если программист яростно бомбит на статик, то у него ООП головного мозга.
Первые версии Unity писали не опытные студенты. И Весь говнокод, который тянется с тех лет там живёт до сих пор. Если бы Unity был хорошо написан, то его бы явно не хотели бы переписывать в Untity 5 в 201 году и сейчас перtход на новую архитектуру на основе DOTS
@@МихаилСуворов-к2щ Эта архитектура отличается от ООП, поэтому речь о статик в априори бессмысленна, по крайне мере, пока не узнаем детали реализации DOTS
Ну я успел всех заебать с Бугаенко, но там одно из первых в Elegant Objects это лучше раскрывается, операцию например в виде статического метода желательно заменять на объект содержащий результат операции через свойство типа Value, и всякие Math были реализованы без оглядки на это, однако со своим кодом лучше уж сделать как выше описал
@@rsakutin ещё бы примеры почему нельзя то и то, насчёт статики думаю хороший пример -> сделать перезапуск игры(без выключения клиента конечно). Вот тут то статика и покажет себя.
Вы точно по программированию курсы преподаете? По-моему у вас другие курсы. Не используйте Статик? Что за дичь? А если нам не нужен экземпляр класса? Всё равно не используйте? Дичь...
Если есть хуилион обьектов класса, в каждом из которых есть поле с общим значением и это значение нам нужно изменить, мы будем вызывать хуилион методов для каждого обьекта? Либо воспользуемся функционалом статики и решим задачу элементарным образом? Твое радикальное отношение к статике либо полная дичь либо твое отношение к ней ни такое уж и радикальное. Надеюсь, ты обобщал, когда говорил об этом.
Насчет комментов не все так просто. Нельзя так категорично рассуждать. Например, комментариями можно выражать ценные сведения в двух словах, которые по коду сразу не увидишь. Это экономит время. Не всегда код можно переписать идеально. В жизни бывают разные ситуации и предостерегающие комменты в таких случаях очень кстати. И т.п.
Мельком в видосе упоминалось про GRASP, а я хочу для себя уточнить, насколько оно практически полезно? Т.е. я понимаю и использую ООП и СОЛИД, но не особо понимаю бенефитов от ГРАСП, не мог бы кто-нибудь объяснить?)
Смысл как обычно в том, чтобы сделать программу поддерживаемой. Чем меньше запутанность, тем лучше. Но мне эти принципы не нравятся, потому что задачи бывают очень разные и принимать решение об ответственности кто управляет, а кто управляемый, приходится всякий раз руководствуюсь более сложными аргументами, чем там описаны. По мне так самое главное это KISS - Keep it simple, stupid. Если вызовов слишком много, если параметров в методе слишком много, если метод слишком длинный, если в классе слишком много методов, если зависимостей много и т.д. то скорее всего этот код делает слишком много разных вещей и их можно разбить. Не факт, но "скорее всего".
1. В ситуации если программа зайдет и ее будут юзать, ну или инвесторы заплатят, то придется все переписывать, потому шо прототип был упрощен и расширять или дорабатывать его в будущем от проблематично до невозможно 2. В ситуации если ваш прототип не понравился, мы теряем все говно что написали, написали бы грамотно, части можно было бы выделить в библиотеку и использовать повторно
@@hematogen50g для примера, ААА или относительно сложный проект нельзя делать плохо, есть баланс между стоимостью разработки "через жопу" и разработкой хорошо, разработка хорошо потенциально стоит больше по некоторым причинам, и сложность проекта может сделать переделку плохого прототипного варианта более дорогой чем изначальное написание хорошего варианта, да и совместная работа заставляет писатт хорошо
Я недавно стал джуном и пишу П.О на c++ и qml в основном. И вот например в qml , мне кажется комментарии бывают просто необходимы, в qml нередка ситуация , когда ты 1 элемент запихнул в другой элемент и его в третий, а это всё лежит ещё в каком-нибудь verticalLayout там столько фигурных скобок, что путаешься , что к чему относится поэтому я в их начале и конце пишу комментарий. Например: //начало Button, //конец Button.
Поверю, что static - это плохо-плохо-плохо-недопустимо, когда встречу фреймворк, который не требует использовать свои статик-классы/методы, чтобы вообще хоть что-нибудь сделать. А если Майкрософт не смог написать без статиков, то сложно требовать того же от каждого первого программиста.
10:57 не совсем согласен, в большинстве случаев, конечно, так, но, когда случается, что необходимо написать скрипт на js в проекте на java, то даже нейминг не очень помогает, потому что, по сути, твой код раскидан по трем разным файлам: java код, js-код и коннектор, в котором может быть определена некоторая js-функция-коллбжк. Я стараюсь код на не основном для проекта языке максимально комментировать (кроме того, что я пояснения в МР делаю), иначе придет следующий разработчик на основном языке, он это просто не поймет. Но пишу я, конечно, не столько, ЧТО делает код, сколько ЗАЧЕМ
Насчёт удаления кода: Да. Часто так бывает, я бы даже сказал в 99% случаев, когда алгоритм пишется с большим трудом. И потом и потом, может даже через несколько дней, ты в этой же программе пишешь какой-то следующий алгоритм попроще, и его сигнатура перекликается с тем сложным алгоритмом и ты видишь решение более эффективное для предыдущей задачи. Тогда да, переписываешь первый алгоритм удаляя предыдущий. Но нужно помнить о следующих моментах: 1) не изобретай велосипед. 2) оставляй лучший код удаляя говно 3) При использовании чужого кода, внимательно изучай чужой код, быть может твой окажется лучше.
СуперДжун в очень большой компании, мне даже не дают писать код)) Больше верстка лц) Ноо, все советы сто проц рабочие, я прямо видел их реализацию у нас) Очень полезный видос, про реально важные вещи, спасибо!)
7:25 тут даже не суть в том, что скажуттслучайные 10 "опытных" разработчиков, паттерны проектирования, например, вырабатывались десятки лет, методом проб и ошибок, глупо надеяться, что ты один такой у мамы умный, что 30 лет развития перечеркнешь. На ЯП пишут спецификации, с некоторыми пунктами можно спорить, но суть-то в том, что программистов много, если каждый будет писать по-своему - хрен вы что соберете, поэтому и нужен стандарт, кто-то его должен продумать. Логично, что стандарты ЯП придумывают авторы ЯП, уж они-то точно разбираются в тонкостях своего языка
Начал изучать язык C и уже написал свою доту2. Решил посмотреть для себя 10 советов, а он тут про какое-то ООП рассказывает почти все советы. Удовлетворён
@@ricardomilos857 Просто для полного нуля в программировании разницы нет что учить вопрос в том что востребованей и реально устроиться на работу в компанию
Дельные советы, но, к сожалению, их поймёт и воспримет только испытавший всё это на своей шкуре. Можно объяснять слепому про цвет, но неплохо было бы для начала открыть ему глаза. Новичкам надо с примерами обязательно, и то не факт, что дойдёт.
7:25 таким людям легко объяснить: говнокод объективен, потому что само преятие "говнокод" - это не значит, что у тебя есть несколько ошибок в коде, это значит, что бОльшая часть твоего кода состоит из ошибок. Если у тебя парочка неточностей, говнокодом не общовут, просто пометят для исправления и примут потом, а вот если у тебя вообще все неправильною настолько, что вычленить что-то полезное - тяжелая задача, то вот это уже говнокод. Лучше стереть все и написать заново
Интересно и главное правильно рассказываешь. Философски сильная позиция у тебя. Критикуешь - предлагаешь. Строишь основу на личном опыте. т.е. на том в чём сам уверен. Я сам долгое время интересуюсь психологией и философией. Само анализ и философия миро воздания. Я плох в грамматике так как с детства намеренно не связывал себя ни с какой сферой деятельности пока сам не пойму чего я хочу. Я не уделял времени для приобретения знаний в ораторском искусстве и приобретал не большой опыт в этом направлении(В социуме иначе не получается). Так вот, я веду к тому, что спустя 32 года (После того как я уделял всё время в основном для ориентирования на местности, для ПОНИМАНИЯ мира в котором я начал свою жизнь) я пришёл к тому что разработка игр, это единственная среда которая роднится с моими уже приобретёнными навыками. Психология - работа с сознанием людей через продукт. Философия - логические взаимосвязи. Я не увидел ни одной перспективной среды где я могу применить те знания которые я приобрёл и испытать себя. У меня нет денег на платное обучение, я за ближайший год работая на заводе по сборке шторок для автомобилей, накопил на слабенький компьютер. Я обязательно выучу язык программирования! Это единственная не достающая деталь к моему успеху в плане для осознания и доказательства себе того что я не зря проводил время своей жизни. Так вот. Я это к тому что среди всех тех блогеров что я видел, ты единственный кто схож со мной по типажу и кого я легко понимаю как себя. Я хочу также довести этот навык до искусства и надеюсь что в дальнейшем мы с тобой встретимся как конкуренты. В споре рождается истина!)
Коментарии зло... Ну если в стиле капитана очевидности, то да. А если писать по делу, то сохранит очень много времени, например почему мы выбрали то или иное решение(стукруту данных, алгоритм и т.д.), прокоментировать аргументы функций \ возвращаемое значение (где может быть не очевидно без просмотра тела функции) и прочее.
Комментарии. Я бы хотел тебя посадить за проект на 5-6 тысяч строк. Когда У тебя голова засерется до того, что никакое именование не спасёт. Где у тебя только глобальных переменных около 2000 800 из которых массивы и сотня энумераторов. Хотя если у тебя имя переменной будет типа: eTa_peremennaya_otvechaet_za_etu_huynyu даже это не спасёт. Не слушайте этого, чудесника!!! Во первых: Комментарии дисциплинируют. Во вторых: не во всех средах программирования есть #Region который не столько скрывает участки кода, сколько делит их на секции, это можно делать также комментариями. В третьих: если проект откладывается, а вы к нему возвращаетесь через месяц или два, то без комментариев вам ППЦ. ... Корочек дядь! или не учи людей вообще или не городи дичь.
Комментарии - это плохо! Нетривиальный код: ладно Статики запрещены в ООП! Синглтоны и некоторые другие паттерны ООП: ок В общем-то ты говоришь неплохие вещи, но зачастую настроен уж слишком радикально
Я бы дал самый главный совет - не воспринимайте советы как руководство к действию. Потому что разные программисты решают разные задачи и у каждого формируется свое видение. Более того, мышление у людей не одинаковое. Не нужно искать серебрянную пулю. Все как в жизни, не все однозначно. Хотя с опытом вы найдете свои ответы. Опять все как в любой другой деятельности, все приходит с опытом.
Подпишусь под каждым словом! Так и нужно учить джунов - выкручивать настройки до максима, запретить статик, запретить толстые классы и методы, запретить произвольный нейминг - и в бой. Слушайте что вам старший товарищ говорит.
Привет, знаю что не ответишь но всё же... За сколько я могу получить от тебя кодревью(ну т.е. оценку кода) на яве?) Ну просто покупать курс по шарпу для меня дороговато, а ревью от тебя увидеть хочется...
Мне подписчик как-то написал что gовно код позволяет проявить фантазию в программировании, а опытные программисты которые придерживаются правил ограничены в программировании. Что ты думаешь по этому поводу? Пхахпхах
Я не знаю как в программировании, не программист, нов моей работе примерно так есть. Для серьезных проектов надо все делать максимально стандартно, что бы снизить риски. А с маленькими можно творчески поиграться
Думаю он использовал логику проф. киберспорта - матчи по старкрафту ГМЛ куда скучнее смотреть, чем любительские. Т.к. грандмастера играют почти всегда одинаково, у них все стратки заучены и они не могут поступить иначе. Думаю в прогерстве так же. Что и отличает любителя от профессионала. Первый романтик, второй - прагматик.
Не поможет. И ему нужно кидать книгу: "Программирование на C# для начинающих" или что-то в том же роде. Но даже так, это не поможет по причинам, описанным вышестоящим комментатором.
сакутин противоречит сам себе? пару дней назад говорил, что ничего такого нет, если использовать статик (про вывод логов) и в видео теперь говорит, что статик это хуево и ТОЛЬКО В РЕДКИХ ИСКЛЮЧЕНИЯХ нормально.
Очередная шляпа по высказываю «не используйте статику» ты хоть когда-то профилировал статику? Подозреваю что нет, так вот я тебе отвечу, что статика меньше жрет и быстрее выполняется
@@mrxprojects Оно и видно! Других критикует, а сам нифига не знает, я б советовал ему курсы пройти по джуну! Кстати, пускай тест пройдёт в прямом эфире на джуна, посмотрим его уровень 😂
Намного увеличивает продуктивность (нет проблем "накатал простыню не в той раскладке и с опечатками") и улучшает здоровье (постоянно бегающий туда-сюда взгляд еще быстрее сажает зрение и быстрее вызывает утомляемость).
Слепая печать очень удобная штука, советую научиться. 30 минут в день на сайте с упражнениями, и уже через неделю будет получаться, а дальше уже само пойдет
Про статик вообще не понял тебя. Тот же DI статик, DI который пробрасывает завимиости, тоже являются статик. Статик работает в эдиторе, почему я не могу библиотеку локализации делать статической, если у меня есть кейс, сгодогенрировать view допустим импортирую из figma и мне нужно локализовать все тексты и проверить есть ли такой ключ, внутри эдитора, как бы ты решил это без статика?
Комменты в коде хороши, чтобы описать человеческим языком неочевидную хуйню (костыли). Костыли -- это плохо, но это, зачастую, вынужденный компромисс. В частности, когда сторонняя апишка гонит хуйню время от времени, а тебе от нее нужен результат, приходится как-то изъёбываться, чтобы его получить. И лучше это неочевидное поведение описать, чем не описать, имхо.
А как потом без комментов даже самому поддерживать код, который содержит кучу матана в классах? Держать в голове все алгоритмы, нахуя? Как быть с приватным конструктором, городить рефлексию где она не нужна, или же просто блять добавить статический метод? З.Ы. Не про геймдев, его специфики не знаю.
Кто сказал что ООП это панацея, а процедурное программирование это прошлый век. Это не правда. Конечно ООП это лидирующая парадигма. Но ситуации бывают разные. Многое зависит от задачи, предметной области, специфики, истории и много чего. После таких утверждений появляются программисты, которые пытаются все превратить в объекты любой ценой. Например, я имел дело с задачей чтения ячеек excel, одна программа каждую ячейку описывала классом, затем превращала в объект, а другая просто читала в список. О производительности говорить не приходится.
В целом верно и вещи правильные. Но с двумя моментами я не согласшусь. 1. Комменты нужны. Но нормальные. Над классом, над методами(функциями) зачем, (иногба почему именно такой подход). 1 строка обычно для хорошей функции достаточна если функция нормальная. Для чего нужно? Банально новый разработчик вкатится гораздо быстрее, какой бы код хороший небыл. Или для генерации вики например. Это важно, когда проект реально большой, когда ты даже можешь не знать бОльшую часть комманды. Как говорится, код пишут для людей 2. Статик классы. Тоже поспорю. Есть минимум 2 типа статик , которые оправданы в программе. Наборы Констант и утил классы. Первые - эт в подавляющем большинстве енамы (внезапно по сути - это набор элементов, доступных статически). По утил классам типа Math и т.п зачем создавать много экземпляров? А если сингтон, то тогда какой смысл пихать его в конструктор или получать инстанс статически? Оправдано будет делать такие вещи не статик, если у тебя есть контракт (интерфейс) и несколько реализаций. Тогда конечно, интерфейс в конструктор, твой класс работает с контрактом, а реализацию уже инжектишь нужную. А в остальном лайк, в люьом случае полезно
Шо за чипуху ты говоришь? Если человек пишет код он не программист, а кто тогда???? Человек юзает язык ПРОГРАММИРОВАНИЯ, значит он уже программист, а вообще нужно говорить в целом про языки, а не только про тупой unity. Если я веб-разработчик, нафига мне твои алгоритмы нужны?!!!
Друзья, время серьёзных вопросов. А почему Роман говорит си шарш, грээсп и т.д. с истинным америкэн произношением. Словно усталый ковбой, завёл своего верного коня в стойло и сказал, гуд бой, си шэрп, гуд бой. Ну коня так звать, си шарп. Шутка в этом. А вот Юнити говорит по русски. Это он не уважает Юнити или наоборот уважает?
Насчёт статики очень спорное мнение. Плохи не сами статические классы как таковые, а статические классы, которые обладают стейтом, т.к. по сути такой стейт - глобальная переменная. Если у тебя есть чистая функция, которая стейт не мутирует, сделать её статической вполне нормально. Ну и так как в C# не возможны свободные функции, не принадлежащие никакому классу, несколько таких общих для всего проекта функции собираются в статик класс. С другой стороны, если функция достаточна простая и не дублируется её удобнее будет как анонимную лямбду оформить
Мог бы и оставить в описании или закрепленном комментарии название книг, которые рекомендовал по ходу видео, чтобы не приходилось выискивать или повторно просматривать ролик...
Язык не важен, так же в каждом собесе: расскажите об отличительных особенностях, а эти интерфейсы откуда, а эти интерфейсы куда, а фреймворки, а это что за аннотации. По итогу получаем шквал вопросов, а работать по итогу вообще приходится с другими вещами.
Комментарии должны предупреждать о подводных камнях в коде, иногда объяснять "почему выбран именно этот способ решения задачи", что, как правило, уместно для промышленного кода. Например, проблемы могут быть в сторонних библиотеках, а отправить pull request разработчику и дождаться выхода следующей стабильной версии не всем подходит. Также для сложных алгоритмов, автоматизации инженерных задач и т.п., будет очень наивно полагать, что другие разрабы целиком и полностью понимают работу того, что вы делаете. Да, возможно, код с комментариями - "плохой код", но в Java и Python (возможно также на Си или в ассемблер-кодах) - это зачастую бывает вынужденным злом.
@@АнтонДудкевич именно так, автор похоже сам ни разу в разработке какого-нибудь крупного проекта не участвовал. Если он только казуалки на Юнити пишет командой 2-3 программиста + дизайнеры, то ему может и не нужны комментарии. В простых проектах всё сильно проще.
Совет номер 9. Не стоит завышать количество советов в названии ролика для красивой цифры. Зачастую это просто рудимент, который может стригерить некоторых личностей (например меня).
