7 важных факторов PHP-приложения

7 важных факторов PHP-приложения

Инженеры платформы Heroku (https://www.heroku.com/) на основе собственного опыта создали методологию (https://12factor.net/ru/) для разработки SaaS-приложений.

Эта методология учитывает три важных аспекта:
— расширяемость — развитие кодовой базы и функционала;
— сопровождаемость и возможность командной работы над проектом;
— масштабируемость.

12 факторов приложения стали шаблоном для многих разработчиков и Ops-инженеров, а мы постарались адаптировать самые важные из них для приложений на PHP.

Кодовая база (https://12factor.net/ru/codebase). Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.

Зависимости (https://12factor.net/ru/dependencies). Используйте менеджер зависимостей Composer (https://getcomposer.org/) и его основные операции install и update для манипуляций c composer.json (https://getcomposer.org/doc/04-schema.md) и composer.lock.

Конфигурация (https://12factor.net/ru/config). Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv (https://github.com/symfony/dotenv).

Параллелизм (https://12factor.net/ru/concurrency). Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ (https://github.com/rabbitmq).

Паритет разработки/работы приложения (https://12factor.net/ru/dev-prod-parity). Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.

Журналирование (https://12factor.net/ru/logs). Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog (https://github.com/Seldaek/monolog) или компоненты фреймворков.

Задачи администрирования (https://12factor.net/ru/admin-processes). Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console (https://github.com/symfony/console). Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения (https://www.yiiframework.com/doc/guide/2.0/en/tutorial-console) и команды.

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

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

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

Иногда мы испытываем недовольство ситуацией в проекте, или у нас есть какие-то опасения, которые мы боимся или стесняемся высказать всей команде. Мы замалчиваем такие вещи или делимся с парой человек, но формально они остаются скрытыми от команды. В результате с каждым днем мы все дальше сдвигаемся от идеального пути. И только когда уже все становистя совсем плохо, начинаются разборы в духе «Я знал, что так и будет».

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

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

Интересно было бы посмотреть на запись какого-нибудь реального чек-ини, но сходу найти не удалось. В целом, можно по разному относиться к этой практике, но выделение 4 базовых эмоций для описания своего текущего состояния, кажется рабочей штукой.

Вы можете даже сами с собой зачекиниться прямо сейчас, попытавшись описать свое текущее состояние по поводу вашей работы/проекта/ситуации, выделив те из 4 эмоций, которые испытываете и подумать, почему именно они выделились сейчас.

Насмотренность - Напользованность

Если хочешь делать продукты с хорошим пользовательским опытом — развивай свой личный пользовательский опыт.

Очень часто пиарят важность насмотренности: ходи на Бехансы и смотри, что крутые рисуют.
Это, конечно, лучше чем не ходить, но в бою с хреновым UX пригодится слабо.
Смотреть как штангу тягают или самому потягать — разные ощущения и опыт.

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

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

В общем, хватит только смотреть — больше пользуйся.

Продолжение про питч. Компоненты.

Основные вопросы, на которые отвечает питч: что делаем, зачем делаем и почему это стоит делать. Вокруг этого уже разбрасываются дополнительные уточнения.

Чтобы было проще жить, питч давно разбили на понятные компоненты. В приближенном (и почти полностью укомплектованном) виде это:

1. Purpose
Компания одной фразой.

2. Problem
Проблема, которую компания/продукт адресует.

3. Solution
Решение проблемы обозначенной сверху.

4. Why now
Почему именно сейчас? Чем хорош момент? Почему нельзя было раньше?

5. Market
Цифры (абсолютные) про рынок, подтверждающие валидность истории.

6. Competition
Другие зайцы на районе. Можно подчеркнуть похожести или отличия, что релевантнее.

7. Team
Хвастовство командой (если есть чем).

8. Revenue model
Очень упрощенная бизнес модель из который становится понятно, откуда идут деньги кроме инъекций от фондов и инвесторов.

9. Traction
Первые пользователи, договор с бизнес-партнером, существующие инвестиции или другой прогресс — все, что увеличивает силу сцепления.

10. Ask / Financials
Запрос на ресурс (напри. Финансы) в виде конкретной цифры и короткий план (с временной рамкой) выхода на самоокупаемость.

11. Vision
Почти то же самое, что первое — но с заделом на 5-15 лет вперед.

12. Appenix
Детали-слайды в кармане, уготованные на случай Q&A. Никогда не пробовал, но могу придумать ситуации, где это полезно.

Шпаргалка продакта: жизненный цикл задачи

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

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

Как это работает

Сверху в шпаргалке стадии, под ними вопросы. Еще ниже инструменты, которые помогают на эти вопросы ответить.

Берёте задачу и прогоняете по вопросам. Находите то, о чем не подумали. Думаете, дополняете. На выходе получаете проработанное решение и план действий.
Пользуйтесь