Источник: Философия, которая сформировала Успешные Рамки
За последнее десятилетие мы стали свидетелями появления многих программных фреймворков, таких как Spring и Ruby on Rails, которые были очень успешными фреймворками, и освоение их означает открытие дверей для множества рабочих мест. Однако для успеха каждой платформы большинство разработчиков, стоящих за ней, не были замечены. Википедия перечислила 67 веб-фреймворков на 1 января 2008 года. Однако сегодня более двух третей случаев исчезновения фигурируют в списке или не обновлялись в течение трех лет. Как создатель фреймворка Yii, я потратил много времени на изучение различных фреймворков и понимание того, почему некоторые из них преуспели, а другие потерпели неудачу. Я опишу некоторые из философий, которые, как я обнаружил, формируют основу успеха.
Почему фреймворк?
Чтобы создать успешный фреймворк, важно понять, что такое фреймворки и зачем они нужны разработчикам.
Дуглас С. Шмидт и другие считают, что платформа обеспечивает многоразовую архитектуру для связанных приложений в виде набора интегрированных программных компонентов, таких как классы, объекты и компоненты. Согласно этому определению, фреймворк должен представлять собой завершенный каркас приложения, состоящий из повторно используемых и настраиваемых компонентов. Разработчики расширят и настроят платформу для формирования полного приложения, предоставив свои приложения и логику, специфичную для домена.
Типичной особенностью фреймворка является так называемая инверсия управления. Фреймворки обычно играют роль организации основной программы и вызова кода приложения. Вот обратный поток управления — он вызывает меня вместо того, чтобы я вызывал фреймворк. На следующем рисунке показана взаимосвязь между фреймворками, функциональными библиотеками и приложениями. Обратите внимание, что фреймворки часто предоставляют библиотеки готовых функций, которые помогают разработчикам быстрее создавать приложения.
Наиболее важная причина, по которой разработчики используют фреймворки, заключается в том, как фреймворки повышают производительность и помогают улучшить качество кода. Например, современные фреймворки (например, django) часто предоставляют инструменты генерации кода или шаблоны, помогающие немедленно начинать новые проекты. Кроме того, в структуру встроены хорошо продуманные меры защиты безопасности, которые помогают разработчикам предотвращать совершение типичных уязвимостей в системе безопасности.
Дополнительным преимуществом рамок корпоративного использования является то, что они могут применяться на предприятии для содействия внедрению стандартов. Платформа обеспечивает шаблон записи, а инструменты детального проектирования и реализации используются для обеспечения согласованной структуры во всех приложениях. Например, в Capital One мы разработали платформу “Шасси” в качестве основы для интеграции, которая объединяет API для разработки приложений у многих поставщиков и клиентов.
Конечно, не все разработчики любят использовать фреймворки. Некоторые постоянные жалобы включают крутые кривые обучения, высокую сцепляемость кадров, низкую производительность и так далее. Сегодня в этой статье я объясню, как современные фреймворки решают эти проблемы, чтобы большинство этих жалоб больше не применялись.
Философия
Как и любой продукт, успех фреймворка зависит от многих факторов, включая идеи, лежащие в его основе, качество кода, документацию, окружающие сообщества, маркетинг, поддержку и так далее. На мой взгляд, особенно важно учитывать философию, когда разрабатывается и разрабатывается структура.
Тим Питерс, разработчик Python, опубликовал 20 принципов дизайна девиза под названием Python Zen давным-давно, когда он разрабатывал Python. “Красота лучше, чем уродство, ясность лучше, чем неясность, лаконичность лучше, чем сложность… Они вдохновили множество подобных языков программирования zens, и я обнаружил, что эти пословицы применимы к дизайну фреймворков. Основываясь на своем опыте разработки фреймворка, я настоящим обобщаю и обобщаю то, что я считаю наиболее важной философией любого успешного фреймворка.
Чем проще, тем лучше
Общий дизайн самый плохой.
Единообразие
Явное лучше, чем неявное
Соглашение больше, чем конфигурация
Чем проще, тем лучше
Разработчикам никогда не бывает легко трансформировать новый фреймворк. Однако, когда разработчик выбирает фреймворк, он или она будет в значительной степени полагаться на него для инвестирования в текущие и будущие проекты. Кроме того, не желая использовать библиотеки классов – разработчики могут изучить API для его реализации – обучающие фреймворки требуют, чтобы разработчики полностью понимали правила фреймворка, прежде чем применять их на практике. Поэтому важно обеспечить, чтобы простая структура была разработана таким образом, чтобы ее было проще, интереснее и легче изучать, принимать и использовать.
Для достижения простоты структура должна обеспечивать соблюдение определенного количества правил ограничения; в то же время эти правила должны быть единообразно разработаны и хорошо документированы. Фреймворк реализует больше правил и крутую кривую обучения, что затрудняет принятие разработчиками. Когда правила согласованы, разработчики могут изучать их быстрее. Без документации структура бесполезна. Потому что никто не тратит время на перепроектирование своих правил.
Express.js хорошим примером является разработка правил грамматики маршрутизации фреймворка, очень популярного фреймворка сервера веб-приложений. Маршрутизация является важной концепцией в веб-приложениях, которая определяет, как приложения отвечают на запросы клиентов для определенной конечной точки (метод HTTP и URI). Express.js вводится простое правило для определения маршрута. app.МЕТОД(ПУТЬ, ОБРАБОТЧИК) , МЕТОД Является методом HTTP-запроса (например, GET, POST) ПУТЬ Это путь URI на сервере. ОБРАБОТЧИК Это выполняется, когда маршрут функции обратного вызова совпадает. Следующий фрагмент кода показывает, как выразить. Выглядит код маршрутизации JS.
var express = require('express');
var app = express();
// accept homepage request
app.get('/', function (req, res) {
res.send('Hello World!');
});
// accept POST request at /user
app.post('/user', function (req, res) {
res.send('Got a PUT request at /user');
});
// accept DELETE request at /user
app.delete('/user', function (req, res) {
res.send('Got a DELETE request at /user');
});Приведенный выше код самоочевиден, потому что он похож на то, как увидеть HTTP-запрос. Поэтому разработчикам не требуется особых усилий для изучения грамматики маршрутизации и применения ее практичности в своих собственных проектах.
Общий дизайн самый плохой.
Термин “целое” здесь относится к структуре, основанной на тесно связанной кодовой базе. Когда веб-фреймворки впервые стали популярными, они, как правило, были единым целым, потому что их главной целью было обеспечить полный спектр быстрой разработки веб-приложений. Постепенно люди поняли, что с общей структурой было много проблем. Например, даже если изменение является небольшой частью фреймворка, которая совершенно не связана, все приложение должно быть повторно протестировано и выпущено, что приведет к перестройке фреймворка приложения. На самом деле, связывание кода в общей структуре очень затрудняет поддержание обратной совместимости различных версий. Например, профессиональные кэши, журналы, базы данных, люди становятся менее склонными быть привязанными к единой общей структуре.
Современные фреймворки часто представляют собой слабо связанные архитектуры. Фреймворки с полным стеком (такие как Spring) превратились в фреймворки, в которых слабо связанные компоненты можно использовать отдельно или обмениваться ими с третьими сторонами. Конкретные платформы имеют четкие контракты для поддержки лучшей совместимости, что делает приложения независимыми от конкретных платформ. Например, очень популярная структура веб-маршрутизации характеризуется так называемой “структурой типа Синатры”, такой как Sinatra, Express.js и Мартини. Эти платформы используют следующую архитектуру конвейера промежуточного программного обеспечения для поддержки маршрутизации запросов и обработки веб-приложений. Сама платформа очень мала, но открытая архитектура позволяет им иметь бесконечное разнообразие компонентов промежуточного программного обеспечения.
Единообразие
Согласованность означает структуру, которая придерживается единообразного дизайна, соглашений об именах, стиля кода, организации кода и так далее. Согласованная структура снижает пороговое значение, поскольку пользователи могут изучить один аспект структуры и применить тот же шаблон для быстрого изучения других структур. Согласованность также может помочь пользователям снизить вероятность неправильного ввода или неправильного использования функций фреймворка.
Например, при разработке построителей запросов для фреймворков Yii мы используем согласованность в качестве руководящего критерия. Построитель запросов позволяет программно создавать независимую от базы данных инструкцию SQL, чтобы избежать атак с использованием SQL-инъекций. Чтобы помочь пользователям легче запомнить его API, мы представили интерфейс цепочки и метод именования соответствующих ключевых слов SQL. В следующем фрагменте кода показано, как использовать инструкцию SQL для запроса проекта конструктора.
(new Query())
->select('id, email')
->from('user')
->orderBy('last_name, first_name')
->limit(10)
->all();Приведенный выше код генерирует и выполняет объявления MySQL следующим образом:
SELECT `id`, `email`FROM `user`ORDER BY `last_name`, `first_name`LIMIT 10
Как вы можете видеть, чтение кода очень похоже на написание инструкций SQL. Согласованность между построителями запросов и грамматикой SQL упрощает изучение построителей запросов.
Отображение больше, чем неявное
Есть две причины придерживаться этой философии написания собственного кода явно, а не неявно, и избегать чрезмерного использования “автоматической магии”. Во-первых, отображаемый код легче понять и поддерживать. Поскольку код не требует пояснений, сопровождающий может не быть первоначальным автором кода, и нет необходимости перескакивать назад и вперед, чтобы найти фактически выполненный код. Во-вторых, отображаемый код не подвержен ошибкам. Хотя для отображения может потребоваться написать больше строк кода, это уменьшает кажущуюся простой и неявной ситуацию, в которой на самом деле скрыт важный код.
Посмотрите на следующие два кода ORM (Объектно-реляционное сопоставление) в PHP. Все они хотят достичь одной и той же цели-установить ограничения ссылок на внешние ключи между записями базы данных заказов и записями базы данных клиентов.
$order->link('customer', $customer);и
$order->customer = $customer;
Первая версия-это обычный вызов метода. Вторая версия выглядит круче, потому что сложные операции подключения к базе данных могут быть выполнены с помощью, казалось бы, простой задачи. Однако это иллюзия, что простота второй версии скрыта сложностью в другом месте. Например, пользователи должны изучить эту грамматику специального назначения с помощью какой-либо формы документа, чтобы использовать ее на практике. Поскольку операция связи выглядит как обычное распределение, пользователь может забыть о возможном исключении, вызванном этим, что приведет к сбою всей программы.
На самом деле, в ходе разработки Yii мы много обсуждали две версии и, наконец, выбрали первую версию, на которую поступило очень мало жалоб.
Соглашение больше, чем конфигурация
Концепция соглашения по конфигурации существует уже много лет. Идея заключается в том, что структура должна соответствовать соглашениям, сохраняя при этом масштабируемость за счет конфигурации. Цель принятия решений состоит в том, чтобы сократить количество вещей, которые разработчикам необходимо сделать для достижения философии № 1- простоты.
Соглашение о конфигурации впервые стало популярным в рамках Ruby on Rails. Rails предоставляет библиотеку ActiveRecord, которая сопоставляется между классами и таблицами в базе данных. Согласно соглашению, имена таблиц являются плюралистическими формами имен классов. Таким образом, у этого типа учетной записи будет таблица, называемая учетной записью. Если таблица не названа таким образом, пользователю придется явно настроить связь сопоставления между именем класса и именем таблицы.
Многие платформы MVC используют соглашения, превышающие запросы конфигурации, для маршрутизации к определенным фрагментам кода. Как показано на следующем рисунке, соглашения, используемые Sails.js рамки рамки являются /мы/скажем/привет Запрос URL будет направлен контроллерам/мы Класс контроллера контроллера SayController в каталоге hi Действие. В соответствии с этим соглашением разработчикам больше не нужно определять правила маршрутизации для поведения контроллера. Однако, если разработчики хотят использовать другое правило маршрутизации, они все равно могут явно привязать маршрут к действию контроллера.
Соглашение по конфигурации помогает уменьшить объем кода, который необходимо написать. Однако это влечет дополнительные расходы для разработчиков, которым необходимо соблюдать правила. В то же время это часто противоречит философии “показать больше, чем неявно”, обсуждавшейся ранее. На самом деле, хотя в более ранних версиях Spring framework использовались аналогичные паруса. Соглашения о маршрутизации JS, Spring теперь требует, чтобы разработчики явно указывали сопоставления с помощью аннотаций. Поэтому при принятии решения о том, следует ли вводить новые правила для поддержки соглашений в отношении конфигураций, следует принимать разумные решения.
резюме
Создание успешной платформы-это все о балансе между функциональностью и простотой. На протяжении всего процесса разработки часто необходимо придерживаться выбора, и приводятся примеры, иллюстрирующие, что вышеуказанная философия принимается во внимание.
Иногда вы можете столкнуться с ситуациями, когда одна идея напрямую противоречит другой. Является ли последовательность более важной, чем простота? Является ли соглашение более важным, чем доминирование? В этих обстоятельствах Имейте в виду, что конечной целью фреймворка является упрощение работы разработчика и процесса кодирования. Поэтому делайте это просто и прямолинейно. Если у них есть явный конфликт, потому что первый приносит скрытую сложность, они могут пожертвовать соглашением. Аналогичным образом, соблюдение последовательности может слегка нарушить строгость, что приведет к дополнительным осложнениям.
Опубликовано 15 декабря 2015 года…
Цян Сюэ
Ведущий Инженер-программист, Технический персонал
Первоначальный адрес: http://blog.forecho.com/successful-frame…