Я уже пару лет как непрерывно занимаюсь проектированием информационных порталов и разного рода сервисов. За это время в голове поднакопилось мыслей, которые просто жалко хоронить под новыми. К тому же бывает сложно за время кратких совещаний выдать коллегам часть того бэкграунда, который позволяет принимать решения о дальнейшем курсе разработки. И каждому новому сотруднику становится все сложнее и сложнее въехать в общую колею.
Чтобы решить проблему первоначального обучения кадров, я попробую хотя бы часть мыслей изложить в блоге. Уверен, мне быстро надоест этим заниматься :) Но хотя бы пару заметок я напишу - и это уже будет что-то, с чего можно начинать.
Что самое сложное в порталах?
Ответ очевиден из заголовка: правильное проектирование. Под правильным проектированием я подразумеваю не идеально продуманную схему построения портала, нет. Правильное проектирование - это когда вы раз за разом задаете себе максимально возможное количество вопросов касательно архитектуры предстоящей системы и с каждым разом остается все меньше неясностей и противоречий. Как будут оформлены результаты проектирования - решать разработчику. Главное чтобы было четкое видение процесса работы системы.
Итак, давайте начнем. Допустим, у вас есть концепция проекта: я имею в виду идею, внешний вид, схему взаимодействия с пользователем и т.д. Пора приниматься за разработку. Однако, прежде чем начать, нам надо задать себе несколько вопросов, ответы на которые помогут нам не сесть в лужу посреди проекта и избавиться от потенциальных головняков.
Вопрос №1: Из каких частей состоит проект?
Деление подразумевается двух видов - идеологическое и функциональное. Допустим, есть портал, в котором есть разделы “Недвижимость” и “Развлечения”, в которых предстоит публиковать статьи и расписание событий. Идеологическое деление здесь - это деление по разделам. Функциональное - это деление на модуль статей и модуль событий.
Внимательно обдумайте, что в вашем случае первично - разделы или модули. Сделать это довольно просто: задумайтесь, что во что будет чаще добавляться. Допустим, вы планируете в раздел “Недвижимость” добавить функционал доски объявлений, предложения от риэлторов и ипотечный калькулятор, а в раздел “Развлечения” - конкурсы, знакомства и чат. В этом случае разумно разделять проект по разделам. Если же вы планируете создать еще 5 разделов, в каждом из которых будет блок событий и статьи, а уникальных “фишек” для каждого раздела не предусматривается - вам нужно делить проект на модули.
Наиболее сложный вариант - это когда модули и разделы равноценны. В этом случае универсального рецепта я назвать не могу, потому как чаще всего такую патовую ситуацию можно свести к одной из двух вышеобозначенных. Если не получается - придется много думать.
Вопрос №2: Каким образом разделены части проекта?
Различные секции проекта могут быть по разному связаны между собой. Это могут быть просто разные контроллеры внутри одного приложения, могут быть контроллеры и модели, разнесенные по разным пространствам имен (или вынесенные в плагины, например, с помощью Rails Engines). Это могут быть разные приложения, работающие на одной базе данных. Или приложения с самостоятельными БД, но в пределах одного сервера. Самый крайний вариант - это когда отдельные части проекта полностью самостоятельны и работают на разных серверах.
Степень разделения сильно зависит от специфики проекта. Если проект маленький (имеется в виду объем функционала), то имеет смысл хранить все части внутри одного приложения. Если функционала много, то имеет смысл разделить его на несколько частей, которые могли бы работать как отдельные, но тесно связанные приложения в рамках одного сервера. Под тесной связью я понимаю связь через единую БД, файловую систему, memcache или shared memory.
Если же функционала много и при этом предполагается, что приложение будет масштабироваться на несколько серверов, то лучше всего разбить весь проект на несколько приложений, каждое из которых будет включать какую-то часть проекта и будет слабо связано с другими. Под слабой связью я подразумеваю обмен информацией через HTTP-протокол с возможностью автономной работы одних приложений в случае недоступности других.
Вопрос №3: Какой функционал является общим и как он используется?
Во многих частях проекта так или иначе будет встречаться повторяющийся функционал. Например, в рамках проекта могут присутствовать статьи, анонсы событий и посты в блогах - и ко всем этим материалам пользователь может оставлять комментарии. Или выставлять оценки. Такой функционал имеет смысл выносить отдельно и делать его независимым от конечных объектов, к которым он привязывается.
В случае, когда части проекта не разделены на отдельные приложения, все решается довольно просто. Такой функционал выносится в отдельный модуль (плагин, контроллер, нужное подчеркнуть) и подключается по мере необходимости. В rails-проектах таким образом оформлено порядочное количество плагинов acts_as_*, которые поставляют готовый функционал для комментариев, рейтингов и многого другого. Однако я бы не хотел привязывать свою статью к какой-то конкретной платформе. Похожие техники есть и при разработке на PHP, Java, Python и прочих языках.
Когда проект разбивается на несколько приложений, вопрос решается несколько сложнее, т.к. встает проблема правильного хранения данных. Если все приложения работают в рамках одной БД, то все в порядке, они все могут включать в себя один и тот же функционал, который оформляется в виде единого плагина и портируется во все части проекта. В том случае, если проект разделяется на несколько независимых приложений, есть два варианта:
- Каждое приложение включает в себя общий функционал и хранит свои данные внутри себя
- Общий функционал оформляется в отдельное приложение, а остальные с ним интегрируются
И тот, и другой вариант имеет свои издержки. Первый осложняет единое хранение и обработку однотипных данных, а второй увеличивает сложность системы, плотность взаимной интеграции ее компонентов и, как следствие, снижает отказоустойчивость системы в целом. В будущих статьях я постараюсь более подробно раскрыть преимущества и недостатки обоих вариантов.
Думаю, для начала пищи мозгу хватит. Если вы уже занимаетесь разработкой проекта, задайте себе эти вопросы. Возможно, вам что-то захочется изменить в вашем подходе к разработке. Если еще только планируете приступить к работе, то ответы на эти вопросы помогут вам избежать многих проблем, с которыми вы можете столкнуться в будущем.
