Есть миллион причин почему jQuery плох во все времена. Одна из них — он нереально усложняет отладку кода. Вторая — в динамике разработки; сначала код пишется чуть быстрее, а потом гораздо-гораздо медленнее, чем на чистом JS. В основном это происходит из-за потери гибкости, внесения дополнительных и совершенно ненужных абстракций и правил.
На самом деле чистый JS весьма неплохо спроектирован — атомарно и консистентно, на нём можно быстро писать эффектные прототипы. А продакшн-разработку можно вести на TypeScript.
Очень благодарю Вас за труд по написанию моей биографии в стиле псевдонаучной фантастики. Вот Вам ещё несколько фактов для разжигания фантазии:
В последние годы я вообще не лезу в код проектов, которыми руковожу. Я не знаю сколько там файлов, строк кода, я даже не знаю есть ли там ООП. Но я досконально знаю требования заказчика, наш технологический стек и его свойства, каждого разработчика и его зону ответственности, и лично провожу ревью каждой фичи.
Спарта — здесь я был рядовым программистом, на проекте работало 50 человек. Код был фаршем на С++ ровно в том стиле, который пропагандирует @S_Revan в своих комментах.
Сочи — здесь я был тех лидом, на проекте работало 30 человек. Код — модульный C# под Unity.
С 2013 года я сознательно не занимался проектами с командой более 10 человек. При этом время, которое я провожу на работе, сократилось в 2 раза, мои доходы выросли в 1,5-2 раза, я получил возможность жить в любой точке мира (что в 2 раза дешевле Москвы и в 100 раз интереснее).
Зачем мне ваши 1000-100000 человек и должность «раб лампы»?)
А зачем задуматься? Я и так знаю что произошло со всеми моими проектами. Если проблемы и возникали, то не на уровне технологий, а на уровне развития бизнеса. Иногда из-за неверных управленческих решений новый владелец сам разоряет свой бизнес. Тут уж я ничем не могу помочь.
А иногда всё идёт нормально. Короче, кому как повезло)
Проект развивается постоянно. До продажи компании это осуществляется нашими силами. После продажи — силами нового владельца.
Мы оформляем информационные системы так, чтобы заказчик мог без программистов менять свойства информационной системы для нужд своего бизнеса. Обычно для этого используется документация с методиками и кастомный domain specific language, который мы разрабатываем под каждый конкретный проект. Таким образом после продажи для развития проекта уже нет нужды лезть в кодовую базу или в структуры данных. Что тут противоречивого?)
У нас весь отдел разработки уходит в отпуск одновременно. Предварительно мы приводим инфосистему к стабильному состоянию, в котором она работает без проблем и без постоянной поддержки со стороны разработчиков. В наше отсутствие код не меняется (ибо некому его менять), соответственно риск возникновения проблем минимален.
Будут ещё какие-то домыслы про возможные проблемы? Или смиритесь, что мой подход рабочий?
Иногда популярность — это просто следствие исторически сложившихся обстоятельств. Можно не рекламировать плохую технологию, и она всё равно захватит мир, как какой-нибудь jQuery. В любом случае, нужно не полагаться на принцип, что «миллион леммингов не могут ошибаться», а подумать своей головой.
Лично для меня критерий прост: чем меньше я трачу времени и усилий на создание решения, и чем больше зарабатываю на нём, тем лучше у меня подход и инструментарий. По этой причине в моей конторе ООП давно списан в утиль.
Абсолютно согласен, что писать такой код как у Вас — это неконструктивно. BTW, по правилам русского языка «не» с краткими прилагательными пишется слитно, если их полная форма употребительна. В нашем случае существует употребляемое полное прилагательное «неконструктивный».
Без статических методов можно обойтись, но зачем?
Затем, чтобы показать пример ООП в обсуждении про ООП. Иначе у читателей возникнут сомнения в Вашей адекватности.
Почему статические методы противоречат концепции ООП?
Потому что это по сути те же глобальные переменные. Они нарушают принцип инкапсуляции. Глобальные константы также нарушают инкапсуляцию. Согласно ООП ничто извне не должно менять поведение объекта. А что Вы делаете?
const int Global::magicOOPNumber = 5;
...
function MyLovelyGamedevClass::Fire(IMonster *victim)
{
victim->takeItAsADamage(this->power * Global::magicOOPNumber);
}
Я могу только предположить, что на основании того, что вы используете C++, вы утверждаете, что ваш код — это ООП. Но, к сожалению, C++ — это не объектно-ориентированный язык. Это мешанина из всех известных человечеству концепций. Чисто теоретически на нём можно написать ООП код, но у вас, увы, это пока что не получается. Как и у всех, кого я знаю)
С таким же успехом можно было написать просто log(50-5)
Позвольте не согласиться. Успеха тут не получится, потому что это — не валидный JS-код.
console.log(50-5);
Вот так будет работать, но в чём смысл? Это просто однократная арифметическая операция с магическими числами.
Важно, чтобы было понятно какова семантика входных и выходных данных. И потом уже эту семантику можно подключать к системам ввода/вывода. Также важно оформить типичные операции над данными в функции, которые можно вызывать повторно и использовать для разных сущностей в игре.
В моём коде тоже описывается взаимодействие между игровыми сущностями. Тут есть и hp, и xp, и сила удара, и уровень Монстра. Просто я оформил игровую сущность как структуру данных и не стал накручивать несуществующие в тексте статьи дополнительные требования (типа 3д, физики, affectableLayer'ов и прочего оверинжиниринга).
А Вы пытаетесь реализовать то же самое взаимодействие тех же самых сущностей через объекты. Но это не ООП, это не компилится, и у этого до сих пор нет скринов — а вечер уже близко.
Я давно уже не работаю рядовым разработчиком. Обычно я ухожу из компании, когда она успешно продана. То есть мы подготавливаем полную базу знаний о нашем продукте, в том числе DSL для настройки системы для нужд нового владельца. Лезть в низкоуровневый код ему уже не потребуется — он просто ведёт свой бизнес на готовой инфосистеме. Поэтому отдел разработки ему без надобности.
А если вдруг захочется взять и кардинально что-то поменять, тогда он наймёт себе CTO, который оценит бизнес-процессы, соберёт команду разработчиков и вместе с ними решит что лучше — разбираться в моём легаси-коде или переписать всё с нуля. Но это уже совсем другая история и не про меня.
В 2002 году получил ежегодную премию, вручаемую Симпозиумом по принципам распределённых вычислений (англ. Symposium on Principles of Distributed Computing) Ассоциации вычислительной техники «за публикацию, оказавшую наибольшее влияние на область распределённых вычислений»; в знак признания заслуг учёного с 2003 года эта премия носит название премии Дейкстры.
суть ООП — правильные абстракции уменьшают количество ...
Ну так у Вас и не пахнет правильными абстракциями. ООП — как следует из названия — ориентирован на объекты. Это значит, что не должно быть статических методов и глобальных констант. Всё должно быть реализовано на объектах. А иначе уже идёт процедурное программирование в стиле C из 1970х. Но у Вас всё хуже — у Вас дикая смесь одного, другого и, скорее всего, чего-то третьего.
То, что принято использовать в низкобюджетном геймдеве, не является правильным ООП. Это просто какая-то традиция, вероисповедание, исторически сложившееся нелогичное нагромождение случайных шаблонов. Поэтому не стоит приводить это как пример использования ООП.
Она не рабочая. Она решает одну тривиальную задачу в вакууме.
Определитесь, пожалуйста, моя демка нерабочая или всё-таки решает задачу?)
Мой код запускается и работает прямо в консоли Вашего браузера. Да, у него нет 3Д и партиклов. Но в постановке задачи этого и не было. Соответственно я пошёл по кратчайшему пути и дошёл быстро. Я могу показывать свою демку заказчику описанной логики взаимодействия Игрока и Монстра уже сейчас.
А Вы когда сможете?
Вы не поставили мне задачу, поэтому рассуждать о путях её реализации бессмысленно. Впрочем, 90% заказчиков так же поступают. Поэтому я должен спросить — Что конкретно вы хотите сделать? Зачем это нужно, как это будет использоваться в реальности?
как вы будете хранить коллекцию структур в вашей программе?
Прежде чем писать программу, я напишу документ с требованиями к ней. И пока что там зияющая пустота)
Скажите пожалуйста, как мы внезапно оказались в контексте «сурового ынтерпрайза»? Я пишу про свой практический опыт — руководство командами от 3 до 30 разработчиков. Поэтому я пишу про свой подход, который реально работал. А то, о чём вы пишете, делали мои предшественники, которые доводили проект до предсмертного состояния и увольнялись. Потому что все эти фабрики фабрик хорошо только в книжках работают. Когда перед тобой есть цель, срок и бюджет, и ты сам лично за них отвечаешь перед владельцем бизнеса, то начинаешь мыслить прагматично. И с такой точки зрения ООП — это нож в спину. Это сложно объяснить словами в рамках комментарий, но легко ощутить на собственном опыте, — попробуйте ;-)
Выбросить код не так страшно как кажется.
Только в тех случаях, когда информация о том, что код должен-таки делать содержится где-то ещё.
Ну тут я вижу, что Вы в принципе не владеете методами оценки состояния инфо-проекта на уровне бизнеса.
Допустим, я пришёл в контору, где есть кодовая база. Все программисты разбежались. Что я буду делать? Полезу в код? Полезу в багтрекер? Полезу в их внутреннюю вики? Нет.
Я посмотрю внедрён ли этот продукт в реальный бизнес-процесс. Если нет, то ценность в нём нулевая — выкидываю смело и начинаю разработку заново с нуля с владельцем бизнеса.
Если проект внедрён, то я анализирую этот бизнес процесс и составляю его модель (база знаний по проекту). Эта модель как раз и будет содержать актуальные общие требования к системе. Далее я проанализирую структуры данных, с которыми работают реальные пользователи. Что они получают на входе, что должны получить на выходе, как это структурируют, всё ли в этом процессе оптимально устроено. В 100% случаев оказывается, что имеющийся код не соответствует реальному бизнес-процессу, потому что делался под другие требования, а потом жестоко хачился. Соответственно и заглядывать туда не стоит — я делаю за несколько недель (обычно этого срока достаточно) собственную систему для осуществления тех же бизнес-процессов и работы с теми же структурами данных, а потом незаметно подменяю одно другим. И вуаля — теперь у меня код мой, подконтрольный и прагматичный. А не какой-то легаси-монстр, с которым надо по неделе за каждую новую кнопочку сражаться.
Что дальше? А дальше идёт оптимизация и модификация бизнес-процессов для повышения прибыли компании. Больше всего этот процесс затрагивает структуры данных, а код для алгоритмов тянется уже в хвосте.
Теперь хотелось бы услышать про Ваш опыт организации миграции проектов из Бангалора (а точнее из Бенгалуру) в Токио. И как на практике ООП в этом помог.
Я написал коммент про языки программирования. И про то, что оценивать уровень Дейкстры не каждому из нас под силу. Скажите, пожалуйста, при чём тут красивый и некрасивый код, шаттлы и надёжность?) У меня просто жестокий разрыв контекста сейчас.
Да тут нет никакого ООП. Почему физика — это namespace, а не объект? Что это за такой Globals? Где идёт разделение игровой логики, физической модели, геометрической модели и рендеринга? Коллайдер — это геометрия, а не физика. Физика опять же бывает разная: кинематика, динамика, инверсная кинематика.
Вобщем, Ваш код больше похож на хаки джуна, это своеобразная мимикрия под продакшн-код в геймдеве. Я такого добра много видел на проектах второкурсников — они его по выходным по ночам до 4 утра отлаживали перед выставками, а потом оно всё равно тормозило, глючило и падало.
Нагородить абы каких абстракций — это не помогает. А с возрастом и опытом понимаешь — даже если нагородить «правильных» абстракций — это тоже не помогает. В итоге Time To Market рулит процессом и определяет стиль программирования.
Мой код не имеет внешних зависимостей. Его можно уже брать и использовать. А Ваш код имеет кучу внешних зависимостей, которые нельзя описать без дополнительной информации от заказчика. Мой Time To Market — 10 минут. Ваш — если всё-таки возьмётесь довести свой код до работоспособного состояния — пара дней. Эффект для пользователя один и тот же.
Теперь считаем: 1 час разработчика стоит $100. За готовую демку платят $1000.
Я заработал $980.
Вы в убытке на $600.
Вот Вам и примитивные задачи)
Под функциональным кодом я понимаю код, который описывает функции и даёт прямой видимый эффект. Про концепцию ФП я вообще тут не говорю.
Код как раз пишется для машин. А для человека пишется база знаний. «Любой дурак» — это тот, кто пытается подменить человекочитаемую базу знаний кодом с комментариями)
Суровая реальность ИТ в том, что большинство бизнесов или долго не живут, или быстро не развиваются. Поэтому почти никогда нет нужды 10 лет что-то там активно поддерживать и развивать.
Сказку про «других сотрудников», развивающих чей-то легаси код я тоже слышал. Но в реальности код неотрывно связан со своим создателем, ибо основан на миллионах неявных логических моделей и связей, которые никак не отражены в коде, но присутствуют в голове автора. Стоит отделить автора от его кода, и он превращается в «наглядное пособие». Поэтому наиболее эффективно, когда новый программист пишет с нуля новый код под себя и в соответствии с зафиксированными в старом коде требованиями заказчика. Выбросить код не так страшно как кажется.
Деградация кода неизбежна, как ни старайся. Даже если всё поектировать идеально, бизнес постоянно меняет условия игры и старые архитектурные решения перестают соответствовать реальности. В итоге в определённый момент всю систему проще полностью переписать с нуля, чем продолжать её мучительные переделки, которые с каждой новой фичёй даются всё сложнее и сложнее.
императивная лапша
Вы забываете о структурах данных, которые идут на вход в систему. А также о бизнес-процессах, которые рождают и используют эти структуры данных. Проектирование решения — это работа и с бизнес-процессами, и со структурами данных, и с алгоритмами. Если это всё не разделить оптимальным образом и не продумать, то лапша как раз и получится. Не важно на чём описывать алгоритмы — на ООП, на ФП, в декларативном или императивном стиле.
Поэтому я считаю, что кратчайший путь — это оптимальная декомпозиция для решения актуальной задачу бизнеса, которое не создаёт ему дополнительных проблем и не тратит время и деньги попусту.
Зачем? — не сказано
Что? — без понятия — какие-то данные, какие-то операции
Как? — расположить данные в таблицу горизонтально или вертикально и проводить одни и другие операции
Мне в принципе думать об этом сложно) Слишком мало информации о задаче. И здесь, как я полагаю, Вы под структурой данных подразумеваете сервисную структуру, которой оперирует алгоритм. Но люди из Data Driven мира под структурой данных всегда имеют ввиду входные данные, которые Вы всё равно не контролируете — они определяются легаси-кодом и устоявшимися бизнес-процессами. А как вы её там трансформируете для своих нужд — это Ваше внутреннее дело.
let player = {
attackPower: 5,
xp: 0
};
let monster = {
hp: 50,
level: 10
};
function isMonsterAlive(monster)
{
return monster.hp > 0;
}
function playerHitsMonster(player, monster)
{
monster.hp -= player.attackPower;
if (!isMonsterAlive(monster))
player.xp += monster.level;
}
Минимально необходимое количество структурированных данных и функций для решения поставленной задачи. Минимальная стоимость реализации и поддержки ведёт к максимальной прибыли от внедрения решения в бизнес-процесс (в случае, если гипотеза геймдизайнера оказалась верна и этот функционал стал приносить прибыль). А что дадут в денежном эквиваленте все эти Actor, ActorValue, HitInfo, Globals, Physics, IAffectable, IEffect? Лишнее время на проектирование, написание и отладку, лишние сущности и связи между ними, больше рисков словить баги.
На самом деле чистый JS весьма неплохо спроектирован — атомарно и консистентно, на нём можно быстро писать эффектные прототипы. А продакшн-разработку можно вести на TypeScript.
Зачем мне ваши 1000-100000 человек и должность «раб лампы»?)
А зачем задуматься? Я и так знаю что произошло со всеми моими проектами. Если проблемы и возникали, то не на уровне технологий, а на уровне развития бизнеса. Иногда из-за неверных управленческих решений новый владелец сам разоряет свой бизнес. Тут уж я ничем не могу помочь.
А иногда всё идёт нормально. Короче, кому как повезло)
Проект развивается постоянно. До продажи компании это осуществляется нашими силами. После продажи — силами нового владельца.
Мы оформляем информационные системы так, чтобы заказчик мог без программистов менять свойства информационной системы для нужд своего бизнеса. Обычно для этого используется документация с методиками и кастомный domain specific language, который мы разрабатываем под каждый конкретный проект. Таким образом после продажи для развития проекта уже нет нужды лезть в кодовую базу или в структуры данных. Что тут противоречивого?)
Я описал цикл продажи компании. А вы спрашиваете о цикле релизов. Вы знаете в чём разница?
Будут ещё какие-то домыслы про возможные проблемы? Или смиритесь, что мой подход рабочий?
Лично для меня критерий прост: чем меньше я трачу времени и усилий на создание решения, и чем больше зарабатываю на нём, тем лучше у меня подход и инструментарий. По этой причине в моей конторе ООП давно списан в утиль.
Абсолютно согласен, что писать такой код как у Вас — это неконструктивно. BTW, по правилам русского языка «не» с краткими прилагательными пишется слитно, если их полная форма употребительна. В нашем случае существует употребляемое полное прилагательное «неконструктивный».
Затем, чтобы показать пример ООП в обсуждении про ООП. Иначе у читателей возникнут сомнения в Вашей адекватности.
Потому что это по сути те же глобальные переменные. Они нарушают принцип инкапсуляции. Глобальные константы также нарушают инкапсуляцию. Согласно ООП ничто извне не должно менять поведение объекта. А что Вы делаете?
Я могу только предположить, что на основании того, что вы используете C++, вы утверждаете, что ваш код — это ООП. Но, к сожалению, C++ — это не объектно-ориентированный язык. Это мешанина из всех известных человечеству концепций. Чисто теоретически на нём можно написать ООП код, но у вас, увы, это пока что не получается. Как и у всех, кого я знаю)
Позвольте не согласиться. Успеха тут не получится, потому что это — не валидный JS-код.
Вот так будет работать, но в чём смысл? Это просто однократная арифметическая операция с магическими числами.
Важно, чтобы было понятно какова семантика входных и выходных данных. И потом уже эту семантику можно подключать к системам ввода/вывода. Также важно оформить типичные операции над данными в функции, которые можно вызывать повторно и использовать для разных сущностей в игре.
В моём коде тоже описывается взаимодействие между игровыми сущностями. Тут есть и hp, и xp, и сила удара, и уровень Монстра. Просто я оформил игровую сущность как структуру данных и не стал накручивать несуществующие в тексте статьи дополнительные требования (типа 3д, физики, affectableLayer'ов и прочего оверинжиниринга).
А Вы пытаетесь реализовать то же самое взаимодействие тех же самых сущностей через объекты. Но это не ООП, это не компилится, и у этого до сих пор нет скринов — а вечер уже близко.
А если вдруг захочется взять и кардинально что-то поменять, тогда он наймёт себе CTO, который оценит бизнес-процессы, соберёт команду разработчиков и вместе с ними решит что лучше — разбираться в моём легаси-коде или переписать всё с нуля. Но это уже совсем другая история и не про меня.
Действительно, откуда ему что-то знать?)))
Ну так у Вас и не пахнет правильными абстракциями. ООП — как следует из названия — ориентирован на объекты. Это значит, что не должно быть статических методов и глобальных констант. Всё должно быть реализовано на объектах. А иначе уже идёт процедурное программирование в стиле C из 1970х. Но у Вас всё хуже — у Вас дикая смесь одного, другого и, скорее всего, чего-то третьего.
То, что принято использовать в низкобюджетном геймдеве, не является правильным ООП. Это просто какая-то традиция, вероисповедание, исторически сложившееся нелогичное нагромождение случайных шаблонов. Поэтому не стоит приводить это как пример использования ООП.
Определитесь, пожалуйста, моя демка нерабочая или всё-таки решает задачу?)
Мой код запускается и работает прямо в консоли Вашего браузера. Да, у него нет 3Д и партиклов. Но в постановке задачи этого и не было. Соответственно я пошёл по кратчайшему пути и дошёл быстро. Я могу показывать свою демку заказчику описанной логики взаимодействия Игрока и Монстра уже сейчас.
А Вы когда сможете?
Прежде чем писать программу, я напишу документ с требованиями к ней. И пока что там зияющая пустота)
Ну тут я вижу, что Вы в принципе не владеете методами оценки состояния инфо-проекта на уровне бизнеса.
Допустим, я пришёл в контору, где есть кодовая база. Все программисты разбежались. Что я буду делать? Полезу в код? Полезу в багтрекер? Полезу в их внутреннюю вики? Нет.
Я посмотрю внедрён ли этот продукт в реальный бизнес-процесс. Если нет, то ценность в нём нулевая — выкидываю смело и начинаю разработку заново с нуля с владельцем бизнеса.
Если проект внедрён, то я анализирую этот бизнес процесс и составляю его модель (база знаний по проекту). Эта модель как раз и будет содержать актуальные общие требования к системе. Далее я проанализирую структуры данных, с которыми работают реальные пользователи. Что они получают на входе, что должны получить на выходе, как это структурируют, всё ли в этом процессе оптимально устроено. В 100% случаев оказывается, что имеющийся код не соответствует реальному бизнес-процессу, потому что делался под другие требования, а потом жестоко хачился. Соответственно и заглядывать туда не стоит — я делаю за несколько недель (обычно этого срока достаточно) собственную систему для осуществления тех же бизнес-процессов и работы с теми же структурами данных, а потом незаметно подменяю одно другим. И вуаля — теперь у меня код мой, подконтрольный и прагматичный. А не какой-то легаси-монстр, с которым надо по неделе за каждую новую кнопочку сражаться.
Что дальше? А дальше идёт оптимизация и модификация бизнес-процессов для повышения прибыли компании. Больше всего этот процесс затрагивает структуры данных, а код для алгоритмов тянется уже в хвосте.
Теперь хотелось бы услышать про Ваш опыт организации миграции проектов из Бангалора (а точнее из Бенгалуру) в Токио. И как на практике ООП в этом помог.
Вобщем, Ваш код больше похож на хаки джуна, это своеобразная мимикрия под продакшн-код в геймдеве. Я такого добра много видел на проектах второкурсников — они его по выходным по ночам до 4 утра отлаживали перед выставками, а потом оно всё равно тормозило, глючило и падало.
Нагородить абы каких абстракций — это не помогает. А с возрастом и опытом понимаешь — даже если нагородить «правильных» абстракций — это тоже не помогает. В итоге Time To Market рулит процессом и определяет стиль программирования.
Мой код не имеет внешних зависимостей. Его можно уже брать и использовать. А Ваш код имеет кучу внешних зависимостей, которые нельзя описать без дополнительной информации от заказчика. Мой Time To Market — 10 минут. Ваш — если всё-таки возьмётесь довести свой код до работоспособного состояния — пара дней. Эффект для пользователя один и тот же.
Теперь считаем: 1 час разработчика стоит $100. За готовую демку платят $1000.
Я заработал $980.
Вы в убытке на $600.
Вот Вам и примитивные задачи)
Код как раз пишется для машин. А для человека пишется база знаний. «Любой дурак» — это тот, кто пытается подменить человекочитаемую базу знаний кодом с комментариями)
Суровая реальность ИТ в том, что большинство бизнесов или долго не живут, или быстро не развиваются. Поэтому почти никогда нет нужды 10 лет что-то там активно поддерживать и развивать.
Сказку про «других сотрудников», развивающих чей-то легаси код я тоже слышал. Но в реальности код неотрывно связан со своим создателем, ибо основан на миллионах неявных логических моделей и связей, которые никак не отражены в коде, но присутствуют в голове автора. Стоит отделить автора от его кода, и он превращается в «наглядное пособие». Поэтому наиболее эффективно, когда новый программист пишет с нуля новый код под себя и в соответствии с зафиксированными в старом коде требованиями заказчика. Выбросить код не так страшно как кажется.
Деградация кода неизбежна, как ни старайся. Даже если всё поектировать идеально, бизнес постоянно меняет условия игры и старые архитектурные решения перестают соответствовать реальности. В итоге в определённый момент всю систему проще полностью переписать с нуля, чем продолжать её мучительные переделки, которые с каждой новой фичёй даются всё сложнее и сложнее.
Вы забываете о структурах данных, которые идут на вход в систему. А также о бизнес-процессах, которые рождают и используют эти структуры данных. Проектирование решения — это работа и с бизнес-процессами, и со структурами данных, и с алгоритмами. Если это всё не разделить оптимальным образом и не продумать, то лапша как раз и получится. Не важно на чём описывать алгоритмы — на ООП, на ФП, в декларативном или императивном стиле.
Поэтому я считаю, что кратчайший путь — это оптимальная декомпозиция для решения актуальной задачу бизнеса, которое не создаёт ему дополнительных проблем и не тратит время и деньги попусту.
Что? — без понятия — какие-то данные, какие-то операции
Как? — расположить данные в таблицу горизонтально или вертикально и проводить одни и другие операции
Мне в принципе думать об этом сложно) Слишком мало информации о задаче. И здесь, как я полагаю, Вы под структурой данных подразумеваете сервисную структуру, которой оперирует алгоритм. Но люди из Data Driven мира под структурой данных всегда имеют ввиду входные данные, которые Вы всё равно не контролируете — они определяются легаси-кодом и устоявшимися бизнес-процессами. А как вы её там трансформируете для своих нужд — это Ваше внутреннее дело.
Минимально необходимое количество структурированных данных и функций для решения поставленной задачи. Минимальная стоимость реализации и поддержки ведёт к максимальной прибыли от внедрения решения в бизнес-процесс (в случае, если гипотеза геймдизайнера оказалась верна и этот функционал стал приносить прибыль). А что дадут в денежном эквиваленте все эти Actor, ActorValue, HitInfo, Globals, Physics, IAffectable, IEffect? Лишнее время на проектирование, написание и отладку, лишние сущности и связи между ними, больше рисков словить баги.