В целом подход подойдёт для любого пет проекта, который целится стать коммерческим.
Сервисы положил себе в закладки.
У меня проект нет dev2dev, поэтому как оказалось первого джуна мне пришлось искать из QA. Очень хочется делегировать свои задачи, но пока есть ощущение, что времени потрачу больше на ревью и менторство. С удовольствием попробовал бы ИИ ассистента, но в гейм деве как-то пока медленно развиваются инструменты.
Возникает вопрос как доказать налоговой, что ты купил крипту p2p, когда чаще всего это происходит через карточки третьих лиц. Связь между покупкой и сделкой весьма условная.
Когда студия выбирает стек, она изначально планирует, кто сможет на этом работать. Если таких разработчиков будет мало, а вакансий станет много, то расходы будут выше рынка. Ну или придется довольствоваться работниками, которые за счёт работодателя будут изучать для себя новый стек. Звучит как плохая идея для бизнеса.
В целом большая часть разработки строится на том, чтобы не повышать сложность проектов всеми силами, чтобы вхождение новых людей в проект было максимально быстрым. Иначе проект умирает.
В конечном итоге для многих разработчиков будет решающим количество вакансий на том или ином движке. И как раз этого движка нет в списке лучших :) имею ввиду Unity.
Ещё здорово бы для быстрого обзора движка добавить поддерживаемые ЯП, тоже довольно влажный фактор
Нужно размуно подходить к разработке и адекватно оценивать время и затраты на будущую поддержку.
Примпняю DDD в unity мидкорных проектах, ещё ни разу не пожалел.
По началу, когда идёт фитчеринг немного дольше получается. Но количество костылей, полученных багов - минимально.
А когда проект доходит до лайв опс, то без нормальной архитектуры все начинается рушится.
По каждому принципу в статье написано из разряда: "это слишком сложно, быстрее будет отказаться и писать как получится".
В реальности, если действительно сравнить 2 проекта соблюдающий солид и не соблюдающий, то станет очевидна разница, где хочется работать, а где на каждую задачу разработчики будут накидывать сверх оценку, потому что нужно рефакторинг.
Спасибо за список атрибутов.
Может быть есть ещё атрибут, который будет работать с JB библиотекой lifetimes.
А именно интересует как можно пометить ISource<T?> Чтобы ide подсказала, что может прийти null?
Интересная статья.
В целом подход подойдёт для любого пет проекта, который целится стать коммерческим.
Сервисы положил себе в закладки.
У меня проект нет dev2dev, поэтому как оказалось первого джуна мне пришлось искать из QA. Очень хочется делегировать свои задачи, но пока есть ощущение, что времени потрачу больше на ревью и менторство. С удовольствием попробовал бы ИИ ассистента, но в гейм деве как-то пока медленно развиваются инструменты.
Здорово, что компания поддерживает такие инициативы.
Обязательно предложу у себя на работе.
Спасибо. Отличная статья. Вроде идея лежит на поверхности, но не думал что будет так просто добавить локализацию.
Будет интересно какие лимиты предоставляются для lfs хранилища в бесплатной версии. Пока из всех российских аналогов gitflick выигрывает.
Это довольно важно для геймдев проектов.
Спасибо за статью. Попробую использовать по вашей инструкции.
Возникает вопрос как доказать налоговой, что ты купил крипту p2p, когда чаще всего это происходит через карточки третьих лиц. Связь между покупкой и сделкой весьма условная.
Это так не работает при найме.
Когда студия выбирает стек, она изначально планирует, кто сможет на этом работать. Если таких разработчиков будет мало, а вакансий станет много, то расходы будут выше рынка. Ну или придется довольствоваться работниками, которые за счёт работодателя будут изучать для себя новый стек. Звучит как плохая идея для бизнеса.
В целом большая часть разработки строится на том, чтобы не повышать сложность проектов всеми силами, чтобы вхождение новых людей в проект было максимально быстрым. Иначе проект умирает.
Ну это просто не правда:)
Посмотрите количество вакансий, большинство будет unity.
Библиотеки на c++ пусть будут написаны, это не мешало сделать c# первым.
Почему не C# первым?
В конечном итоге для многих разработчиков будет решающим количество вакансий на том или ином движке. И как раз этого движка нет в списке лучших :) имею ввиду Unity.
Ещё здорово бы для быстрого обзора движка добавить поддерживаемые ЯП, тоже довольно влажный фактор
Нужно размуно подходить к разработке и адекватно оценивать время и затраты на будущую поддержку.
Примпняю DDD в unity мидкорных проектах, ещё ни разу не пожалел.
По началу, когда идёт фитчеринг немного дольше получается. Но количество костылей, полученных багов - минимально.
А когда проект доходит до лайв опс, то без нормальной архитектуры все начинается рушится.
По каждому принципу в статье написано из разряда: "это слишком сложно, быстрее будет отказаться и писать как получится".
В реальности, если действительно сравнить 2 проекта соблюдающий солид и не соблюдающий, то станет очевидна разница, где хочется работать, а где на каждую задачу разработчики будут накидывать сверх оценку, потому что нужно рефакторинг.