Показаны сообщения с ярлыком архитектура. Показать все сообщения
Показаны сообщения с ярлыком архитектура. Показать все сообщения

пятница, 19 мая 2017 г.

Архитектура клиентского приложения (механизмы структуризации)

История первая


Некоторое время назад я работал в одной игровой компании, которой руководил немец. Создание игр не было основным бизнесом этого немца. Основные доходы он получал от продажи косметики и от сдачи коммерческой недвижимости в аренду. Наличие игровой компании было способом выделиться среди своих знакомых бизнесменов.


Игровая компания немца разрабатывала 3 вида игр:

  1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
  2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
  3. Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

С самого начала была понятна только общая канва игры. Маленькая фея ходит по саду, встречает своих подруг (других фей), разговаривает с ними и приглашает на вечеринку. Подготовка к этой вечеринке занимает значительную часть игры: фея украшает сад, собирает яблоки, готовит из них праздничный пирог. Вечеринка проходит весело: фея и ее подруги играют на музыкальных инструментах, а затем — танцуют.

Предполагалось, что игра будет представлять собой последовательность мини-игр. Каждая мини-игра посвящена определенной теме: украшению сада, сбору яблок, приготовлению праздничного пирога, исполнению музыки и танцам. Не смотря на то, что были понятны темы мини-игр, не были понятны их детали. Геймдизайнера в команде не было.

Поначалу над игрой работало два программиста и один 3D-моделлер. Когда я присоединился к команде, не было ни проработанного игрового дизайна (или человека за него отвечающего), ни платформы, на которой можно было бы сделать игру.

На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.

На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.

Далее

понедельник, 26 декабря 2011 г.

Архитектура ОС Singularity (отзыв на статью)


Прочитал отчет Microsoft Research «Проект Singularity: обзор». Появился ряд мыслей, которыми хочется поделиться.

А. Singularity – это тестовая операционная система, разработанная исследовательской группой Microsoft. При работе над проектом была поставлена такая задача:

воскресенье, 11 декабря 2011 г.

Отзыв на книгу "Шаблоны интеграции корпоративных приложений"


Прочитал книгу:

Хоп, Грегор, Вульф, Бобби. Шаблоны интеграции корпоративных приложений. : Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007. – 672 с.: ил.

Книга вышла в серии “A Martin Fowler Signature Book” и посвящена шаблонам интеграции корпоративных приложений.

В настоящее время для интеграции корпоративных приложений используются 4 техники:

1)      Передача файла (File Transfer).
2)      Общая база данных (Shared Database).
3)      Удаленный вызов процедуры (Remote Procedure Invocation).
4)      Обмен сообщениями (Messaging).

В книге делается обзор всех четырех техник, но наиболее подробно рассматривается обмен сообщениями. Собственно говоря, этим книга меня и заинтересовала, т.к. в последних своих проектах я использовал асинхронную модель. Коммуникация между потоками, выполняющими разные функции, осуществлялась при помощи обмена сообщениями.

На примере шаблонов интеграции, описанных в книге, можно подметить ряд закономерностей, которые, думаю, будут интересны.

понедельник, 5 декабря 2011 г.

Отзыв на книгу Фаулера "Архитектура корпоративных приложений"


Просмотрел сильно разрекламированную книжку Мартина Фаулера «Архитектура корпоративных приложений» (точная ссылка: Фаулер, Мартин. Архитектура корпоративных приложений.: Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544 с.: ил.). Книжка описывает архитектурные паттерны, которые можно использовать при разработке корпоративных (как правило, web-based) приложений. Поскольку такие приложения практически не обходятся без использования базы данных, очень много места в книжке уделяется объектно-реляционному отображению.

А. Общие впечатления.

Основные впечатления от книжки:

1)       Книга не содержит описания архитектур, хотя в названии используется слово «архитектура». Книга содержит отдельные частные решения, которые можно использовать при проектировании – и только-то!

2)       Книга не содержит перечня архитектурных задач (хотя бы неполного). Отсутствует какая-либо модель постановки задач при разработке архитектуры. Что такое творческая задача в архитектуре? Автор об этом умалчивает.

3)       Поскольку описание задач отсутствует, нет критерия для отбора паттернов. Паттерны включены в книгу в произвольном порядке. Приведенные решения не разделены на качественные уровни. В результате «слабые» паттерны соседствуют вместе с «сильными».

4)       Многие паттерны образованы по схеме: «преобразование + объект, к которому оно применяется». В результате паттерны дублируются. Хоть преобразования, лежащие в их основе, одинаковые, но вот объекты разные.

Вывод: