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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

спасибо за инфу. а как же статические методы расширения? например 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()));

интересно, а синглтон у вас можно ?)

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

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

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

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

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

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

👍👍👍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👾

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня вопрос, умеешь ли ты делать собственный движок например на основе openTk? Или хотя бы пробовал, очень интересно про это увидеть видео

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

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

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

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

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

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

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

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

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

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

Да уж. Где взять такие деньги на обучение? Блин, один платеж по рассрочке 15к, это чуть больше половины моей зарплаты.

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

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

Слепой печатью не овладел за несколько лет опыта

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

Что со звуком то?

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

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