Спасибо за замеры с 1. На самом деле было интересно, есть ли разница. Автосвойствами я не пользуюсь, так как пока не возникало кейсов, где они были бы нужны. В некоторых случаях можно кешировать проперти (чтобы не дёргать лишний раз), но согласен, что не всегда.
А про комменты тоже не соглашусь, в они часто бывают полезны, так как если скажем в коде реализован сложный алгоритм (тот же волновой алгоритм поиска пути или же алгоритм триангуляции невыпуклого контура), то не каждый с ходу их сможет узнать, и был бы полезен коммент, что тут именно происходит, чтобы не лезть в документацию лишний раз. Да, и в ряде случаев люди мыслят немного по разному и нейминг, который одному человеку кажется очевидным для другого не так очевиден.
Спасибо. Статья хорошая, но реализация шаблонного синглтона, которая тут описана — плохая. Если я не ошибаюсь, она мне не запрещает иметь два синглтона в одной сцене (первый найденный файндом и будет прав) Тут должна быть ещё проверка на то, что если объект существует, то его нельзя прицепить. Хотя я бы вообще не советовал делать монобехи синглтонами.
1. В каком смысле не использовать свойства? Какие свойства? Если имеется ввиду в своих классах, то допустим нам нужна инкапсуляция. Вопрос, в чём отличие свойства от геттера и сеттера реализованных методами?
2. Про GetComponent<> вообще отдельный разговор, я не совсем понимаю зачем его использовать в принципе. Это конечно, наверное, ускоряет работу (хотя я считаю, что это банальная лень программистов), но в большинстве случаев можно обойтись вообще без него. Т.е. компоненты, которые висят на объекте всегда, можно просто сериализовать. А те объекты, которые цепляются динамически откуда-то можно хранить пуллом в скрипте, в котором они цепляются и обращаться с этим (точнее говоря это по разному можно решать)
4. Опасно, так как вроде Vector3 не иммутабелен (поэтому его геттер и сделан через new), и если кто-то случайно в коде натупит (случайно или по невнимательности), то такую ошибку очень тяжело найти (а точнее понять в чём именно ошибка). Соглашусь, что надо кешировать и т. п., и что случай редкий, но тем не менее я бы кешировал внутри класса, где это используется. (Допустим, кто-то вызовет метод Scale или уж совсем непонятно зачем — Set)
5. А как же StringBuilder?
С этим я просто не согласен, читабельность можно сохранить при правильных подходах если не торопиться. В крайнем случае решается это комментарием, что делает эта магическая строка.
«Самым плохим моментом оптимизаций является то, что ваш структурированный и „идеальный“ код растекается в местами не очень читабельное нечто. К сожалению, это неизбежно. Главное помнить о том, что это жертва в угоду производительности.»
Я просто себе слабо представляю 15 взаимосвязанных стейтов интерфейсов в игре, так как глубина переходов больше, чем в 3 — это уже плохо с точки зрения проектировки UI. А если они достаточно независимы, то я для этого использую модульную систему и в нужных местах вызываю необходимые модули. Не спорю, такие ситуации возможно могут возникать, просто в моём понимании они очень специфичны.
В статье не хватает «для чего и в каких случаях это хорошо». Если конечным автоматом с состояниями представлять навигацию по главному меню скажем — ок, а вот если речь идёт уже о попапах, диалоговых окнах и т. п. то нет. И стейты далеко не всегда нужны, так как во многих задачах они будут избыточны и будут только усложнять структуру кода. Просто далеко не всегда нужна полная смена гуя, и иногда проще стейтмашину ставить независимо от интерфейса, а тут оно достаточно жёстко связано. Простой енам и выбор, какой именно гуй инстанцировать/показывать был бы ничем не хуже (хотя может я просто не вижу минусов)
А по данной реализации, она интересная, но на мой взгляд, она слишком сложная для такого функционала, и я не совсем понимаю, почему бы стейт свитчер не сделать синглтоном.
А для чего на Spawner вообще висит компонента бокс коллайдер? Решение так себе, согласен с Tutanhomon И зачем вейпоинты искать файндом? Вообще юнитёвые файнды лучше юзать в крайних случаях, когда по-другому не обойтись, а тут и без него обойтись довольно просто.
Критерий странный, а в остальном прикольно. Просто данная система подсчёта «очков» по идее даёт нам вполне определённое множество специфичных строк, и по идее они далеко не всегда будут правильными. Или я неправильно понял разбираемую задачу. Просто, честно говоря, я не вникал в работу алгоритма очень сильно, но мне кажется, что он составляет строку из минимального количества слов. А это далеко не всегда верное решение подобной задачи.
На самом деле решать можно по разному. Зависит от задач. Работать через разные сцены не всегда бывает удобным. Очень часто удобнее делать одну сцену с геймплеем, и одну сцену для интерфейсов (главное меню, стор, что-то ещё). А уровни сериализовать каким-нибудь JSON, XML, YAML, а после строить их на старте сцены. Если вариант для начинающих, то думаю да. По сцене на уровень удобнее всего.
Ну просто, на мой взгляд, должен быть адекватный рост соразмерно скиллам. Да, можно платить меньше рыночной цены, но не в 2 раза же. 5 лет срока — это очень много. Год-два возможно. Просто чтобы проектирование доверяли студентам, я такого не видел, наверное зависит от компаний. Хотя, я и сам то, по сути, выпустившийся студент, некоторое время работал на разных проектах, в разных фирмах и на фрилансе.
А всё, кроме пожалуй примера с потоками, это я бы всё-таки не назвал обучением. Обучение, это когда студент не имеет представления о паттернах, о адекватном применении наследования, о том какие существую приёмы, чтобы избежать дублирования и т. п. и ему объясняется «как надо». Просто то, что описано звучит, как код ревью вне зависимости от уровня специалиста. («У тебя кнопки ОК и Отмена наоборот, в винде не так» это вообще скорее к проектированию UI, а не к разработке)
Но в случае, когда у человека реально вырос уровень, вы, как компания, получаете хорошего специалиста, которого плюс ко всему не надо вводить в проект, который в нём уже +- разбирается и может достаточно хорошо выполнять большой класс задач, так почему ему платить на порядок ниже рыночной цены? Так как он пришёл к вам студентом и якобы он вам «обязан», хотя он так же работал? Это достаточно странное обоснование.
То есть я правильно понимаю, что вы предлагаете разработчику не максимизировать свою выгоду из гуманистических побуждений? Просто заниматься обучением имеет смысл, когда нет свободных специалистов на рынке. Если обучением считать выполнение детских/рутинных задач, то это тоже стоит денег и человек по факту их отработал. А я полагаю, что при разнице предложений в 10-15%, если на работе нет никаких серьёзных проблем, человек вряд ли перейдёт в другую компанию. А если уровень специалиста вырос, то смысл ему сидеть в компании, если ему в другой предлагают на 100-200% больше? Ведь в долгосрочной перспективе он теряет не эти 100%, а значительно большие суммы денег. Я не говорю про скуку, этот вопрос другой и тут айти специалисты может быть действительно зажрались, но я в мало каких компаниях видел нормальную систему обучения. Обычно тебя бросают на задачи, и ты должен с ними разобраться. Иногда можешь спросить совета у старших коллег (хотя чаще быстрее помогают гугл и StackOverflow). Это не совсем обучение.
Сцену с редактором — имеется ввиду сцену с редактором уровней, которую просто запускал. А получившийся уровень у меня сохранялся то ли в формате XML, то ли в YAML. Поэтому апдейт и прочее отрабатывало в каждом кадре.
Я видел в документации такое, но работало оно как-то странно. И хоткеи мне нужны были, чтобы соединять на сцене точку А с точкой Б верёвкой, которая генерировалась скриптом (ну то есть был метод, который принимал параметрами трансформ начала и трансформ конца, и по данной информации генерировалась верёвка между ними) Update не работает в Editor моде, а OnInspectorGUI() и OnSceneGUI() работает довольно странно (вроде там завязано на том, когда мышь движется внутри гуя инспектора или сцены) Использовать [ExecuteInEditor] не хотелось уже не помню почему, но в данном случае Update() вроде тоже работает как OnSceneGUI(), но вот тут я могу ошибаться, не помню точно.
Поэтому я сделал просто сцену с редактором, где Update() работает в каждом кадре и создал класс Keyboard, в котором была скрыта логика работы событий ввода и явно описана логика работы необходимых методов. Так же хоткеи мне нужны были не для меню итемов, а для созданных мной интерфейсов, которые были в виде EditorWindow для левелдизайна и отвечали за инстанцирования префабов на сцену (просто менюшка с кнопочками). Причём префабы брались рекурсивно из папок (чтобы не прописывать каждый раз новый созданный объект) и кнопки создавались динамически. А тот вариант, который предложили вы хороший, но для простейших задач.
Я не совсем понял смысл, а зачем перехватывать события в данном случае? Обрабатывать события ввода с мыши можно и без таких конструкций. Лучше бы была бы где-нибудь статья, как в редакторе юнити настроить кастомные хоткей Вот это не так просто делается, если я правильно помню то, по какому принципу отрабатывает OnSceneGUI и OnInspectorGUI. Когда-то мне было проще сделать редактор просто отдельной сценой и запускать, чтобы с хоткеями работать (хотя это немного костыльненько, но удобно, в случае когда редактируемые объекты хранятся в виде файлов никак не связанных с Unity)
По стилистике кода. Я бы советовал писать по-разному локальные переменные, поля класса и т. п. Просто видимо тут поля класса в стиле простых переменных, не критично, но читать удобнее когда с ходу понятно что есть что. (Вот пример одного из моих классов pastebin.com/ezvhTYG1, с помощью которых обрабатывается свайп в одном проекте, он большой, но тут по стилю по сути использовано всё)
А про комменты тоже не соглашусь, в они часто бывают полезны, так как если скажем в коде реализован сложный алгоритм (тот же волновой алгоритм поиска пути или же алгоритм триангуляции невыпуклого контура), то не каждый с ходу их сможет узнать, и был бы полезен коммент, что тут именно происходит, чтобы не лезть в документацию лишний раз. Да, и в ряде случаев люди мыслят немного по разному и нейминг, который одному человеку кажется очевидным для другого не так очевиден.
1. В каком смысле не использовать свойства? Какие свойства? Если имеется ввиду в своих классах, то допустим нам нужна инкапсуляция. Вопрос, в чём отличие свойства от геттера и сеттера реализованных методами?
2. Про GetComponent<> вообще отдельный разговор, я не совсем понимаю зачем его использовать в принципе. Это конечно, наверное, ускоряет работу (хотя я считаю, что это банальная лень программистов), но в большинстве случаев можно обойтись вообще без него. Т.е. компоненты, которые висят на объекте всегда, можно просто сериализовать. А те объекты, которые цепляются динамически откуда-то можно хранить пуллом в скрипте, в котором они цепляются и обращаться с этим (точнее говоря это по разному можно решать)
4. Опасно, так как вроде Vector3 не иммутабелен (поэтому его геттер и сделан через new), и если кто-то случайно в коде натупит (случайно или по невнимательности), то такую ошибку очень тяжело найти (а точнее понять в чём именно ошибка). Соглашусь, что надо кешировать и т. п., и что случай редкий, но тем не менее я бы кешировал внутри класса, где это используется. (Допустим, кто-то вызовет метод Scale или уж совсем непонятно зачем — Set)
5. А как же StringBuilder?
С этим я просто не согласен, читабельность можно сохранить при правильных подходах если не торопиться. В крайнем случае решается это комментарием, что делает эта магическая строка.
И очень не хватает картинок
А по данной реализации, она интересная, но на мой взгляд, она слишком сложная для такого функционала, и я не совсем понимаю, почему бы стейт свитчер не сделать синглтоном.
А всё, кроме пожалуй примера с потоками, это я бы всё-таки не назвал обучением. Обучение, это когда студент не имеет представления о паттернах, о адекватном применении наследования, о том какие существую приёмы, чтобы избежать дублирования и т. п. и ему объясняется «как надо». Просто то, что описано звучит, как код ревью вне зависимости от уровня специалиста. («У тебя кнопки ОК и Отмена наоборот, в винде не так» это вообще скорее к проектированию UI, а не к разработке)
Но в случае, когда у человека реально вырос уровень, вы, как компания, получаете хорошего специалиста, которого плюс ко всему не надо вводить в проект, который в нём уже +- разбирается и может достаточно хорошо выполнять большой класс задач, так почему ему платить на порядок ниже рыночной цены? Так как он пришёл к вам студентом и якобы он вам «обязан», хотя он так же работал? Это достаточно странное обоснование.
Поэтому я сделал просто сцену с редактором, где Update() работает в каждом кадре и создал класс Keyboard, в котором была скрыта логика работы событий ввода и явно описана логика работы необходимых методов. Так же хоткеи мне нужны были не для меню итемов, а для созданных мной интерфейсов, которые были в виде EditorWindow для левелдизайна и отвечали за инстанцирования префабов на сцену (просто менюшка с кнопочками). Причём префабы брались рекурсивно из папок (чтобы не прописывать каждый раз новый созданный объект) и кнопки создавались динамически. А тот вариант, который предложили вы хороший, но для простейших задач.