Advanced: Тема повышенной сложности или важная.
Куда катится наш мир :)
Они даже целый фреймворк создали 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
скопируй сюда текст, там не возможно копи-пастить
Тема закрыта.