Анализ архитектуры на основе анализа используемой модели данных

Да, заголовок получился длинным. Ночь - голова работает иначе чем рано утром, в ароматах крепкого кофе.

Довелось мне сегодня получить интереснейший опыт, хочу им поделиться.

Вот уже несколько дней, а может и недель - в agile на динамичном проекте время летит незаметно - мы всей командой размышляем над одним сложным вопросом.

У нашего продукта неожиданно обнаружился конкурент, да такой, что при сравнении мы не могли выделить существенных плюсов и минусов их или нашего решения. Хорошо, что оба решения имеют открытый исходный код.

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

Все идеи, приходящие в мою тестерскую голову не годились - они были совсем не о том и уводили меня в сторону от правильного решения, либо были слишком маленькими и незначительными, либо, наоборот, слишком масштабными. Т.е. неприменимыми.

И мне в голову пришла совершенно странная идея - взять одинаковый объект из двух конкурирующих продуктов и сравнить модель данных, которыми он описан в одной и другой системах (да, у этих продуктов обнаруживались пересекающиеся сущности, реализованные совершенно различным образом)

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

И найден небольшой, но заметный для пользователя, дефект в нашем приложении! (одно из полей имело некорректное описание)

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

Вот так вот, взяв два файла в различных форматах и наложив один на другой, иногда можно увидеть решение поставленной задачи.

И, анализируя архитектуру чужого приложения, можно найти баг в своём ) - хотя, конечно, ценность найденного архитектурного решения намного выше обнаруженного дефекта )