Войти
Инди-ЮнитиФорум

Мастер класс по хорошему коду в юнити

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 Следующая »
#0
(Правка: 1:45) 1:18, 12 сен. 2020

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

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

Постепенно будет больше, но начну я с простого и обрушу сегодня свой гнев на тех кто ничего не понимает или делает отвратно, когда:

(Ах, да, в выражениях не стесняйтесь пока это про код, а не переход на личности - буду тереть)

* Настраивание объектов под контекст игры

  • Хранение статичных данных скрипта (компонента) - связки в сцене
  • Неиспользование стандартной сериализации
  • Для юнити это 3 синонима в названии темы. Со временем я понял, что самый большой грех программиста - это оверхед и создание дополнительных зависимостей (да, да и совсем не призрачная, академическая "чистота кода"). Юнити дает вполне терпимый аппарат для сериализации данных, чтобы вам не думать как хранятся настроенные компоненты(скрипты). Почему вы их не используете, зачем придумываете какие то велосипеды с сериализацией, или используете совершенно говно-либы для этого? Например, odininspector и т.п. бред. Если это так вы расписались в проф. непригодности .. а теперь спорьте ... чтобы вас мне понять , мне надо понять вначале - зачем вам такой гавнокод и зависимости в коде, и не хватает сериализации из коробки?

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

    Возможно, где-то это будут священные-войны, не без этого, главное чтобы обросло мясом - аргументами, детализацией и примерами кода

    #1
    (Правка: 1:26) 1:20, 12 сен. 2020
    Здесь запланировано место для содержания тем вообще с ссылками на пост-тему, и наиболее сильные аргументы в них
    #2
    1:20, 12 сен. 2020

    (резервация)

    #3
    1:20, 12 сен. 2020

    (резервация)

    #4
    1:20, 12 сен. 2020

    (резервация)

    #5
    1:20, 12 сен. 2020

    (резервация)

    #6
    (Правка: 9:49) 9:49, 12 сен. 2020

    tac
    > Юнити дает вполне терпимый аппарат для сериализации данных, чтобы вам не
    > думать как хранятся настроенные компоненты(скрипты). Почему вы их не
    > используете, зачем придумываете какие то велосипеды с сериализацией, или
    > используете совершенно говно-либы для этого?
    Если прочитать мануал Юнити, можно узнать, что:
    - Кастомные сериализуемые классы сохраняются как структуры. Т.е. две ссылки на один и тот же объект становятся разными объектами после десериализации
    - Не поддерживается Null для кастомных классов. Если сериализуемое поле такого типа имеет значение Null, Юнити автоматически заполнит его новым экземпляром
    - Не поддерживается полиморфизм
    Если ты компетентный программист, ты легко сможешь представить себе ситуации, в которых эти пункты окажутся серьёзной проблемой.

    #7
    (Правка: 1:02) 0:53, 13 сен. 2020

    BooTheJudge
    > окажутся серьёзной проблемой
    В том то и дело, что серьезной проблемы это не вызывает. А если уж припрет компетентный программист, сможет легко эти легкие моменты обойти. Причем не решая эти проблемы, а считаясь с тем, что он неправильно хочет сериализовать, то что на самом деле сериализовать не нужно.

    #8
    (Правка: 1:29) 1:27, 13 сен. 2020

    что ж поехали дальше ... следующая болезнь слабых программистов ..

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

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

    Отсюда правило для написания ассетов: он должен решать лишь одну конкретную задачу, и иметь "адекватное" кол-во классов реализации. Все остальные крупные ассеты умрут, их перестанут поддерживать, а вы не сможете тянуть на себе, то что вам на 80% не нужно.

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

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

    #9
    10:41, 14 сен. 2020

    tac
    > Причем не решая эти проблемы, а считаясь с тем, что он неправильно хочет
    > сериализовать, то что на самом деле сериализовать не нужно.
    Тут мне почему-то вспомнились "обзорщики" с ютуба, которые говорили: "Dark Souls 2 не говно, вы все просто неправильно в неё играете!".

    Вообще уже второй совет подряд относительно использования (точнее, не использования) чужого кода. Когда уже будут советы по своему коду?

    #10
    (Правка: 20:55) 20:53, 14 сен. 2020

    BooTheJudge
    > Когда уже будут советы по своему коду?
    о, нет, увольте, любезнейший, я лишь буду писать как вредно, как срамно, и как гавняно пишут местные дилетанты ... а все остальное за деньги :)

    tac
    > разберем самые фейс палмы

    #11
    (Правка: 23:21) 23:17, 15 сен. 2020

    Насмотрелся я тут крутых инди проектов и пля.. простите, не удержался.
    Инди, это свобода. Свобода от правил кода, свобода в выборе палитры, гаммы или чего бы то ни было. Это свободное выражение своих идей, подходов и механик. Это свобода, которая не подразумевает логику или физику, это полная и совершенная абстракция (в лучшем её виде). Инди, это я, инди, это ты. Будьте проще и всё у вас получится.. бб.

    #12
    0:42, 16 сен. 2020

    tac
    > Юнити дает вполне терпимый аппарат для сериализации данных, чтобы вам не думать
    > как хранятся настроенные компоненты(скрипты). Почему вы их не используете,
    > зачем придумываете какие то велосипеды с сериализацией
    кастую Alprog'a в топик

    #13
    10:33, 16 сен. 2020

    tac
    > о, нет, увольте, любезнейший, я лишь буду писать как вредно, как срамно, и как
    > гавняно пишут местные дилетанты ... а все остальное за деньги :)
    Не понял ты мой вопрос. Я как раз и имел в виду: покажи уже, что пишут местные дилетанты, мне интересно. Пока ты только написал, что они используют чужие "говнобиблиотеки".

    #14
    5:23, 19 сен. 2020

    tac
    Мсье. Ну тут прямо дело чести ответить на мой вопрос. Он звучит так: Сколько стоит час Вашего ревью?

    Страницы: 1 2 3 4 Следующая »
    Инди-ЮнитиФорум