Не следует привлекать новые сущности без самой крайней на то необходимости.
Уильям Оккам
Сейчас веб-разработка сталкивается с большой проблемой - сверхнизкое повторное использование кода.
Как происходит, когда разработчик начинает делать свой проект, скажем, на PHP. Сначала он идет, например, на PHP Classes. Там очень много классов. Все разные. Каждый написано по-своему. У некоторых внешний интерфейс через один класс, у других через пять, у третьих через десять и два конфига. В результате требуется изучать архитектуру каждого класса, и, что самое важное, сайт из таких “компонентов” быстро не построишь.
Тогда разработчик идет смотреть готовый фреймворк. Фреймворков на рынке с десяток. Все разные. Все сложные. Все несовместимые друг с другом. Все они, повторяю, сложные, у каждого достаточно запутанная архитектура, своя реализация MVC, разные подходы работы с БД, с шаблонами, с кодогенерацией.
И они сложные. Поэтому мало кто (в мировом масштабе) их осваивает. Поэтому мало готовых компонентов для этих фреймворков, и все равно многое надо писать самому. Компоненты от разных фреймворков не совместимы.
В итоге, разработчик в лучшем случае осиливает готовый фреймворк и пишет проект под него, в худшем и более частом - пишет что-то новое свое, разумеется, абсолютно несовместимое со всем остальным.
Есть, конечно, более “компонентные” решения, вроде Joomla и Drupal, но они не являются открытыми стандартами, они являются продуктами со своей историей и они тяжеловесны.
На других языках ситуация бывает полегче, но, как правило, дело не идет дальше общего репозитория классов. Классов, а не компонентов, то есть не столько готовых бетонных блоков, из которых можно быстро собрать сайт, сколько щебенки и кирпичей. Как правило, недостает даже цемента.
Это то, как разработка ведется сейчас. А теперь, как она будет вестись на платформе, которую я хочу создать.
Итак, Open Web Platform (OWP). OWP является компонентной системой. А именно: каждый блок проекта является “компонентом”, который общается с другими компонентами не напрямую, а через общий интерфейс “ядра платформы”. Пример:
owp_core::call("auth", "login",
array("user" => "me", "password" => “123”)
);
$user_id = owp_core::call("auth", "user_id");В этом примере некий управляющий компонент shell обращается к компоненту auth, который производит авторизацию пользователя, после чего возвращает user_id. Компонент shell ничего не знает о компоненте auth. Не знает, на каком тот написан языке. Из каких состоит классов. Как он разработан. Где он находится в файловой системе. Он даже может оказаться на другом сервере. Компоненту shell и его разработчикам это безразлично - они знают имя компонета auth и вызовы, которые можно ему направлять, этого совершенно достаточно.
Таких компонентов в нашей системе может быть сколько угодно, однако все они общаются через единый интерфейс owp_core::call. На файловой системе это может выглядеть так:
Все единообразно. Если посмотреть на Class Diagram любого сколь-либо сложного “обычного” проекта, мы всегда увидим клубок ниток. Здесь мы имеем единую шину, к которой динамически подключаются разные устройства-компоненты.
Каждый компонент может быть написан как угодно. Это не важно. Главное, чтобы они все реализовывали единый внешний интерфейс, вроде такого:
interface owp_app {
public function __construct($app, $process_name);
public function start();
public function autoload();
public function stop();
public function install();
public function uninstall();
public function call($method, $data);
}Что находится “за” этим интерфейсом - не важно. Вам достаточно написать мануал (не сложнее команды man в Linux) для вашего компонента, после чего вы можете делать с бекэндом все, что захотите.
При этом компонент даже не обязательно должен быть написан как на PHP, как здесь. Ядро может иметь “драйвера” для различных языков разработки и вызывать компоненты между языками.
Оцените, как при таких условиях упрощается рефакторинг. При рефакторинге “внутри” компонента другие не затрагиваются никак, поэтому проблем не возникает. Если же рефакторинг касается внешнего интерфейса, то этот интерфейс простой, поэтому его изменение сводится к простому “поиск и замена” по всему проекту.
И это еще не все преимущества такого подхода. У нас есть компоненты, они все однотипны. Одни компоненты могут использовать другие. Значит, можно создать единый репозиторий с зависимостями, как для Linux. Тогда установка одного компонента автоматически повлечет за собой установку связанных. Поскольку все они независимы друг от друга, вы вообще не заметите то, что что-то там установилось. Все просто работает.
Разные компоненты могут нести разный функционал. Одни могут быть “базовыми”, вроде mysql-компонента, другие реализовывать логику проекта, третьи генерировать HTML-блоки для вторых (VC и M из MVC соответственно). Однако архитектурно они все являются однотипными.
Теперь посмотрим, что будет, если мы хотим сделать сайт. Мы заходим в глобальный репозиторий компонентов и скачиваем оттуда все необходимое. При этом все вспомогательные компоненты, необходимые для работы нужных нам, будут рекурсивно установлены автоматически. Мы не должны думать, что нужно для работы наших компонентов. Оно уже установлено. Теперь нам остается только дописать “свои” компоненты, которые используют установленные и реализуют уникальный функционал нашего сайта. Всё.
А теперь сравните это с описанием “современной” разработки из первых абзацев.
Итак, сейчас я занимаюсь разработкой такой платформы. Она частично написана. Однако, для того чтобы такая платформа стала мировым стандартом, мне нужны мнения разработчиков. Только они знают, как надо скорректировать код и архитектуру такой платформы, чтобы им было удобно ей пользоваться. Я с радостью выслушаю все требования, которые вы выскажите. Я особенно буду рад, если встреча произойдет вживую, с перекрестным изучением кода (у меня есть возможность организовать это в офисе на берегу Москвы-реки, с хорошей экологией и бесплатным Wi-Fi).
Жду ваших писем.
Дмитрий Лейкин
Email: dilesoft@gmail.com Skype: dilesoft ICQ: 67937292 Телефон: +7 (903) 125 33 68
