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) и команды.

Заботливый менеджер

Классная черта любого лидера — умение подбодрить команду, когда тяжело, и отметить успехи, когда они были.

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

Внезапная забота — это не ожидаемо и всегда приятно.
Я помню, как на прошлом месте работы директор повёл нас в кафе после сдачи сложного госпроекта, к презентации которого готовились до 3 ночи. Это было лет 10 назад. Но я уже не особо помню тяжесть, с которой мы тогда столкнулись.

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

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

Почему так? Ответ есть у психологов 🙂 Даниэль Канеман, в книге «Думай медленно... решай быстро» описывал опыт про вспоминающее «я».

Перескажу кратко.
Подопытному надо было пройти три теста «холодная рука».
Поочерёдно левую руку опускали в один сосуд с водой, а правую в другой. Вода была холодная: 14 градусов Цельсия. Вызывает болевые ощущения, но не сильные.

Левая рука находилась в холодной воде минуту, а потом её доставали и вытирали.
Правая рука находилась в холодной воде тоже минуту, но потом незаметно в воду добавляли тёплой воды и рука ещё 30 секунд была в воде. Тёплая вода подогревала воду всего на 1 градус, но этого было достаточно, чтобы ощутить снижение болевых ощущений.

Потом подопытным говорили — какой же эксперимент ты выберешь третьим: тот, который был для левой руки, или тот, который был для правой? 80% среди тех, кто почувствовал снижение боли, выбрали эксперимент с правой рукой. То есть они были готовы терпеть столько же боли, что и левая рука, но ещё и 30 секунд с небольшим уменьшением.

👉 От внезапной заботы люди готовы сделать больше и лучше

Хочу вам сегодня рассказать про две книжки, которые недавно прочитала

Первая – "Принципы" Рэя Далио, вторая – "Creativity, Inc" Эда Кэтмелла.

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

Сразу спойлер: этически и идеологически мне ближе то, о чем пишет Эд, чем то, о чем пишет Рэй, и это определило мое восприятие этих книг. Это мое субъективное мнение, и для кого-то все может оказаться совсем наоборот.

Рэй Далио – создатель одного из самых успешных хедж-фондов Bridgewater Associates. Его книга – это, по сути, монолог о том, как он принимал решения, делал ошибки, строил компанию: первая часть – это его автобиография, вторая – принципы, которые он вывел для себя в течение жизни. Мне это напомнило книгу The Hard Thing about Hard Things (https://t.me/proproduct/681), где первая половина была утомительно детальной, а вторая – сугубо теоретической. Получилось, что эти финальные постулаты оторваны от доказательной базы, поданы как набор некоторых философских утверждений, многие из которых не особо оригинальны и уже не раз звучали в других книгах про менеджмент. Мне такое читать скучно: я не верю автору на слово, я хочу с ним живой дискуссии через книгу – а это создается через описание процесса мышления, проб и ошибок, через которые он прошел. Это частично есть в первой части, но с точки зрения структуры текста не соединено со второй.

Напротив, Эд Кэтмелл, президент Pixar и Walt Disney Animation Studios, рассказывает историю. Его размышления и принципы удачно вплетены в общую канву повествования, с большим количеством примеров из его работы в качестве руководителя. Изначально книга читается как документальный роман о создании Pixar, но в итоге ты остаешься с миллионом записей и мыслей о лидерстве. И, что было особенно важно для меня, о лидерстве в креативных индустриях. Многие книги о менеджменте написаны людьми, которые работали на производстве или пытались сделать его более эффективным. Да, конечно, креативность тут важна в верхах, но менеджмент в большинстве случаев сводился к оптимизации расходов/доходов. Люди в этих условиях – не больше, чем ресурс. Таичи Оно и его изобретения в Toyota, безусловно, гениальны, но стоит ли проводить аналогию с разработкой продуктов? Правда ли, что у нас такой же конвейер, и все сотрудники одинаковы и заменимы?

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

Рэй Далио пытается проанализировать все аспекты работы, свести все к метрикам и понятным фреймворкам. Это вполне естественное желание: нашему мозгу так проще, кажется, что все под контролем, – вспомнить про тот же тейлоризм. Эд Кэтмелл выводит нас на другой уровень и говорит, что менеджер должен осознать и принять – многие вещи не подвластны нашему контролю.

“If you’re sailing across the ocean and your goal is to avoid weather and waves, then why the hell are you sailing?”

Знайте про производственный менеджмент, учитесь креативному лидерству ^_^

Командообразование

В итоге, Саша Мемус провел с нами всего два занятия в этом семестре, и все его внимание было посвящено сплочению ребят внутри команды.

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

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

Внутри команды мы поделились на несколько ролей: менеджер, аналитик и дизайнер (нас как раз было трое). Аналитик мог пользоваться только браузером, дизайнер мог искать референсы и рисовать прототипы, менеджер не мог делать ничего кроме как говорить и координировать.

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

С каждой новой итерацией мы менялись ролями внутри команды и брифами с другими командами. Чтобы мы не расплавлялись Саша закручивал гайки: сначала на работу отвели 7 минут, потом урезали речь менеджера на защите до 3 предложений, а в самом конце от начала работы до презентации прошло всего три минуты.

Конечно, мало кто смог сразу продать идею заказчику, сначала все споткнулись на том, что не следили за временем, и дорисовывались все в последнюю секунду, многие говорили непоследовательно, забывали назвать какой-то из пунктов обязательных для презентации, например, показать референсы; очень часто забывали выполнить какое-либо из условий. Но совсем страшным грехом было, если команда говорила несуществующие факты, чтобы набить себе цену — с врунами никто никогда работать не будет, их репутация портится молниеносно.

Боязнь простых решений

Я часто замечал, что люди недоверчиво относятся к простым решениям.
Например, приносишь дизайн заказчику, а он: "Слишком просто, давайте добавим чего-нибудь этакого!"
Добавляют. Проект стартует, а ухаживать за "чем-нибудь этаким" довольно сложно.

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

"Мы предусмотрели в проекте 500 экранов! Если так, то такой экран и логика.
Если этак — такой экран и логика. Всё очень индивидуально."

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

Если вместо 500 экранов можно сделать 100 — надо делать 100. Пусть потеряется где-то индивидуальность, но решение не будет протухать.
У нас в Велвике такой принцип — если решение кажется сложным, то мы останавливаемся, отматываем назад и смотрим, где можно упростить.
Простое работающее решение придумать сложнее, чем нагородить кучу "если".

В общем, надо стремиться к упрощению.

Решительность и находчивость

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

Сегодня про решительность.

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

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

👎 Я проверил, но ты тоже посмотри, чтобы наверняка.

👎 Никто не говорил, что так можно делать.

👎 Я сделаю, но под твою ответственность.

👎 Я написал в поддержку, если не ответят за два дня, тогда позвоню.

👎 Обычно это делает Володя, поэтому я и не стал делать.

👎 Давайте соберёмся и обсудим.
...

Нерешительные коллеги могут порождать лишние итерации в работе: кто-то лишний раз смотрит, перепроверяет, ждёт. Создаётся дисбаланс и лишние трудозатраты. Если вы когда-либо сдавали дизайн или иную работу внешнему заказчику, то могли видеть, как нерешительность растягивает время. Если есть ЛПР, который решает — сдаётся быстро, а если есть коллективная ответственность — адская возня.

Задача лидеров направлять нерешительных коллег в решительное русло, выгонять их из зоны комфорта: сам проверь и подведи итог; а сам как думаешь?; позвони сразу в поддержку; Володи нет — сам сделай; не надо собираться — сам реши. Лидер должен решительно бороться с нерешительностью.

Я какое-то время писал статьи и публиковал их только в личный блог. Понятно, что мало прочтений (почти ноль), мотивация писать новое близка к нулю. Я не знал хорошо ли пишу или нет, но я знал, что есть только один способ это узнать — опубликовать статью в тематическом паблике. И вот в конце 2018 года я написал статью про способы onboarding пользователей и решился пригласить коллег из отрасли её почитать — запостил ссылку в UX club на Facebook.

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

Прокачивали свою решительность и многие известные (теперь уже известные) люди. Например, знаменитый физик Лев Ландау был очень стеснительным. Но решил бороться с этим: в юном возрасте он привязывал к своей шляпе воздушный шарик и гулял так по Невскому проспекту в Ленинграде. Это было в начале 20-го века. Возможно, не решись он на такую прокачку он бы и не стал учёным, который мог сформулировать и реализовать самые смелые идеи.

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

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