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

Куда катится наш мир :)

Они даже целый фреймворк создали Zenject для говнокода

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

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

Extenject - здесь более актуальная версия.
- сенкс за советы - я удалили все тесты и закомитил - сейчас пишу заявление на перевод в отдел QA - сказали буду тестить руками билды на всех платформах

patsanchik3
А вот мне интересно сколько ты написал автоматических тестов, и когда они тебе помогли :)

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

public class SoundPlay : MonoBehaviour
{
  public AudioClip[] SoundsFon;

  private AudioSource Audio;

  void Start ()
  {
    Audio = GetComponent<AudioSource>();
  }

  void Update ()
  {
          if (SoundsFon.Length > 0)
    {
      if (Audio.isPlaying == false)
      {
        int SoundID = Random.Range(0, SoundsFon.Length - 1);
        Audio.clip = SoundsFon[SoundID];
        Audio.Play();
      }
    }
  }
}

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

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

patsanchik3
> ты че нить посложнее попробую пописать
ожидаемо :) Т.е. ты согласен, что внедрением зависимостей стоит заниматься в исключительных случаях, а не со всеми классами? По моей оценке таких случаев меньше 1%, так? Попробуешь объяснить когда такой случай наступает?

Ну или давай так - дай мне работающий проект, где по твоему без внедрения зависимостей ну точно ни как?

Ну или перепиши его [мой пример] с внедрением зависимостей, мне даже интересно на сколько он вырастет?

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

patsanchik3
> - крафты
ну написан у меня краф для моей игры, и ничего, мир не перевернулся :)

давай свой код на ревью с крафтом, выпрямлю :) потом еще спасибо скажешь ... 

дело тут не столько в пользе самих тестов а в том что если код тестируемый он отличается обычно в лучшую сторону от портянок в 2К строк в апдейте:
- модульностью (со всеми вытекающими)
- независимость от внешних фреймворков
- отвечает принципу единственной ответственности

да и после рефакторинга всегда приятно прогнать тесты что бы убедится что все нахрен не сломалось и есть шанс не уронить проект перед релизом :)

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

patsanchik3
> это больше про программирование а не про скриптование :)
вот только не надо, это больше про оверхед ,чем про программирование

patsanchik3
> и это еще tac ecs не заметил
туда же - в мусорку

patsanchik3
> отличается обычно в лучшую сторону
это справедливо для моего кода :) я никогда не напишу код, который будет сложно рефакторить и поддерживать .. но тут нет единой теории - это батенька - опыт, а не доморощенные теории и паттерны ... даже тот болван, говорит, что внедрение зависимостей не защищает от гавнокода ... весь секрет в том, что надо понимать когда, что применять и как

Кстати, выше так никто и не спросил про MVC ... ну тут очевидно, что в геймдеве это никогда не пригодится? Почему? Да потому что в играх ВСЕГДА примитивный GUI в смысле повторного использования. Так зачем же вы городите огород? но это другая тема, что называется "по требованию" ...

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

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

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

согласен с топикстартером на все сто

tac давай про mvc дальше
говнокод реактивной модели игрока

patsanchik3
скопируй сюда текст, там не возможно копи-пастить