Хорошая статья. Хорошо показывает, зачем и как можно использовать принципы SOLID. Эти принципы просты только для тех, кто из уже хорошо понимает и/или хорошо подкован в программировании вообще и архитектуре в частности, а для джунов эти принципы сложны, как раз из-за недостатка опыта сложно увидеть грабли. Статья на хорошем примере показывает, что бывает без этих принципов.
Понятно, что в статье пришлось убрать некоторые вещи, на которые указали в комментах. Если это всё это сделать, то статья станет в три раза больше и в десять раз сложнее, и не поможет джунам понять принципы.
А можете пояснить, почему так? Мне это не интуитивно: таблица - это данные (и те сущности, список которых хранится в таблице). Да, бывают таблицы, в которых не сущность, а отношения (для многие-ко-многом), но из-за них все таблицы назвать отношениями? Ведь может быть такая вырожденная БД, где только одна таблица, и нет отношений (не с кем относиться).
Было бы хорошо, если бы сделали такой трюк - геймплейный скип для профи - прямо в первом раунде обучения показать, что ты профи, но новичок не сможет это увидеть/понять/суметь и пойдёт учиться. Например, показать зону с кучей ботов, новичок испугается туда пойти, а профи пойдёт, всех победит за N секунд, и тем самым заскипит обучение (и получит +1 к ЧСВ :). Или как пасхалка, скип - скрытая локация в обучении, профи узнал про это на форуме и знает, как туда пройти.
По поводу пункта "Польза от интерфейса № 1". Изменили классы и перевели связи на интерфейсы. Красиво получилось, я тоже люблю, когда красивая картинка получается. Но есть одно "но"! Раньше Менеджер мог оценивать только Служащего, а теперь может оценивать и другого Менеджера. Изменились бизнес-правила во время рефакторинга, так не должно быть, это не фича, это баг.
Посмотрите статью, может, пригодится их 80lvl экселевый шаманизм.
Ещё вот есть от Milfgard, какие способы баланса существуют.
Ещё есть статья с интересным примером балансирования TowerDefence, довольно полезно.
В современных версиях Unity не работают поля типа rigidbody2D (поле rigidbody2D есть, но имеет тип Component, а не Rigidbody2D). Их нужно присваивать в методе Start в отдельную переменную:
public class CharacterControllerScript : MonoBehaviour
{
//переменная для установки макс. скорости персонажа
public float maxSpeed = 10f;
//переменная для определения направления персонажа вправо/влево
private bool isFacingRight = true;
//ссылка на компонент анимаций
private Animator anim;
private Rigidbody2D rb;
/// <summary>
/// Начальная инициализация
/// </summary>
private void Start()
{
anim = GetComponent<Animator>();
rb = GetComponent<Rigidbody2D>();
}
И дальше в коде использовать поле rb вместо rigidbody2D.
В принципе, можно переопределить новое поле со старым именем rigidbody2D:
Отличная статья, очень практическая. Огромное спасибо за подробный рассказ и примеры, это очень ценно, в подобных статьях останавливаются общими фразами типа «делайте концепты и прототипы», а тут прямо «мясо». Особенно будет ценно тем, кто только ступил первый шаг на дорогу геймдева. Даже странно, что такой маленький рейтинг статьи.
Книга «Варлорд. Темный пакт» (Angel Delacruz). Одежду печатают в прет-а-порте-принтерах, бесплатно, но вот список разрешённых вариантов одежды — у каждого свой, красивые модели надо оплачивать.
А какие у них тарифы? там не всё понятно с бесплатным тарифом. Насколько я помню, в публичном месте можно бесплатно, а вот ограниченном разделе (по логину) только платно. Или не так?
Был монолит со сложностью 10. Делим на 10 микросервисов, получается не 10 по 1, а 10 по 2-3. Но проектом со сложностью 2-3 управлять гораздо проще, чем сложностью 10. И плюс добавляем сложность в взаимодействии, если декомпозиция проведена хороша, то взаимодействий от 9, иначе до 90, сложностью 1.
Получается, вместо сложности 10 выходит 30=20(сервисы)+10(взаимодействия), как и написано в статье («разработка может обойтись вам примерно в 3 раза дороже, чем на монолите», в последнем абзаце). Но управлять 10 монолита уже нереально (невозможно добавить ещё одну, чтобы стало 11), тогда и делают микросервисы.
Эта история — крайность, безусловно. Хотя и в реальности появляются крайние вещи. Бывают и менеджеры — эффективные, которые сильно помогают программистам.
Просто другую крайность мы тоже читаем — в книгах про «эффективных менеджеров». Там одна крайность, в этой статье — обратная крайность. Истории и той, и этой крайности — важны и поучительны. nmivan, а сможете написать про подобную историю, но с точки зрения менеджера? Или когда менеджер научит программисту быть лучше. Я не все ваши посты читал, может, уже есть?..
Считаете неправильно, предложите своё решение, обоснуйте, найдите общий язык с человеком и расскажите что к чему, эскалируйте проблему выше если не решается.
Автор уже писал про это, в повести «Проще, чем кажется» — начало тут. Годная история.
Насколько я понял по тексту, героиня имела в виду, что если компания не умеет делать отношения, то никакая срм не поможет. Но если компания умеет, то это может стать хорошим инструментом (за меньшие ресурсы делать большие дела).
Хорошая статья. Хорошо показывает, зачем и как можно использовать принципы SOLID. Эти принципы просты только для тех, кто из уже хорошо понимает и/или хорошо подкован в программировании вообще и архитектуре в частности, а для джунов эти принципы сложны, как раз из-за недостатка опыта сложно увидеть грабли. Статья на хорошем примере показывает, что бывает без этих принципов.
Понятно, что в статье пришлось убрать некоторые вещи, на которые указали в комментах. Если это всё это сделать, то статья станет в три раза больше и в десять раз сложнее, и не поможет джунам понять принципы.
А можете пояснить, почему так? Мне это не интуитивно: таблица - это данные (и те сущности, список которых хранится в таблице). Да, бывают таблицы, в которых не сущность, а отношения (для многие-ко-многом), но из-за них все таблицы назвать отношениями? Ведь может быть такая вырожденная БД, где только одна таблица, и нет отношений (не с кем относиться).
Было бы хорошо, если бы сделали такой трюк - геймплейный скип для профи - прямо в первом раунде обучения показать, что ты профи, но новичок не сможет это увидеть/понять/суметь и пойдёт учиться. Например, показать зону с кучей ботов, новичок испугается туда пойти, а профи пойдёт, всех победит за N секунд, и тем самым заскипит обучение (и получит +1 к ЧСВ :). Или как пасхалка, скип - скрытая локация в обучении, профи узнал про это на форуме и знает, как туда пройти.
По поводу пункта "Польза от интерфейса № 1". Изменили классы и перевели связи на интерфейсы. Красиво получилось, я тоже люблю, когда красивая картинка получается. Но есть одно "но"! Раньше Менеджер мог оценивать только Служащего, а теперь может оценивать и другого Менеджера. Изменились бизнес-правила во время рефакторинга, так не должно быть, это не фича, это баг.
А видео докладов есть? Что-то не нашёл в канале по ссылке. Очень уж интересные темы...
Ещё вот есть от Milfgard, какие способы баланса существуют.
Ещё есть статья с интересным примером балансирования TowerDefence, довольно полезно.
И дальше в коде использовать поле rb вместо rigidbody2D.
В принципе, можно переопределить новое поле со старым именем rigidbody2D:
А почему лучше избегать треугольники, если их потом всё равно делать при триангуляции? Ведь и видеокарта умеет делать только треугольники.
Получается, вместо сложности 10 выходит 30=20(сервисы)+10(взаимодействия), как и написано в статье («разработка может обойтись вам примерно в 3 раза дороже, чем на монолите», в последнем абзаце). Но управлять 10 монолита уже нереально (невозможно добавить ещё одну, чтобы стало 11), тогда и делают микросервисы.
Просто другую крайность мы тоже читаем — в книгах про «эффективных менеджеров». Там одна крайность, в этой статье — обратная крайность. Истории и той, и этой крайности — важны и поучительны.
nmivan, а сможете написать про подобную историю, но с точки зрения менеджера? Или когда менеджер научит программисту быть лучше. Я не все ваши посты читал, может, уже есть?..
Автор уже писал про это, в повести «Проще, чем кажется» — начало тут. Годная история.