Нет, в этой статье я буду писать не про ту отрасль, которая в ИТ-сообществе известна как "Solution Architect", а про подход к решению задач; про то, как можно и как следует решать некоторые поставленные задачи. В архитектурном смысле.
Немного из прошлого
Работал я на одном проекте, интересном с точки зрения приложения навыков разработчика, но крайне непроработанном с точки зрения технических аспектов (но это даже интересно). Иными словами, задача "сделать хорошо" была вполне себе обыденным делом. Т.е. некоторые входные данные были, но множество важных технических моментов отдавались на откуп самим разработчикам.
Мне тогда надо было сделать специальный редактор данных, однако я знал лишь о том, что за данные будут, но ни намёка ни про структуру их хранения, ни про названия полей данных (в то время бэкенд сильно отставал и предоставить эти данные мне не мог; архитектор тоже был сосредоточен на иных задачах). И вот тут мной была допущена принципиальная архитектурная ошибка. Я представил какой может быть структура, назвал по-своему поля, привязался к названию полей, реализовал интерфейс, продемонстрировал и... тут, наконец, пришла структура данных, которая даже близко не соответствовала той, что я использовал. Фиаско. Использовать интерфейс было фактически невозможно. С помощью лома и такой-то матери я-таки связал данные, но это был невероятный костыль.
Впрочем, это меня многому научило и подобных ошибок я не повторял.
Что же такое архитектура решения
Тут, пожалуй, нельзя дать чёткое определение, потому что в каждой области она имеет свою особенность. Но это и не нужно; для меня, пожалуй, наиболее подходящим будет следующее определение: решение, которое предельно гибко реагирует на изменение требований.
То есть, решая любую задачу, пред собой следует ставить только один вопрос: что в данном решении "неподвижно", а что должно меняться? Это позволит решать задачи настолько гибко, насколько это возможно.
Но для понимания того, что должно меняться - необходимо видеть немного больше, чем горизонт выполнения ближайшей задачи; необходимо смотреть на то, где и как ещё может быть использовано данное решение, как внутри текущей задачи, так и, возможно, за её пределами.
Количество вопросов, которые задаются к задаче, определяются в соответствии с опытом, как относительно целостности и встраиваемости решения, так и относительно каких-то задач, которые потребуется ещё решать при помощи текущего решения.
Звучит довольно абстрактно. Попробую привести пример того, как это работает: мы делаем некоторый диалог, который позволит редактировать набор данных (всё просто), но необходимо учесть ряд факторов.
- Диалог будет открываться и, как следствие, управляться только в одном месте, или интерфейс его открытия должен быть "мобилен"?
- Структура данных строго определена или может меняться?
- Правила проверки данных фиксированные или настраиваемые?
- Диалог только редактирует данные или позволяет отправлять их в 1 или несколько источников?
И так далее. Список может быть весьма значителен, даже когда это касается всего навсего диалога.
К чему это всё
Собственно, желание создавать игры - это просто увлечение. Примерно такое же, как катание на роликах или на санках, хотя и с некоторым отличием.
В планах у меня написать ещё несколько игр и поэтому будет правильней сделать несколько универсальный движок, который позволит относительно легко реализовывать задачи и в иных играх. Этим я сейчас и занимаюсь и поэтому всё долго.
Готовый движок брать нет смысла, т.к. увлечение хорошо тем, что есть некоторые условия для него. В моём случае - это использование WebAssembly (Rust). Эта идея мне кажется весьма интригующей, т.к. Rust вызывает интерес и открывает новые возможности, а интеграция приложений на нём написанных (равно как и на других языках, способных собираться в wasm) в браузер, фактически, частично стирает границы применения.
