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

Обучать или не обучать UX-дизайнеров?

Обучать или не обучать UX-дизайнеров?


Давайте коротко про минусы и плюсы, а детально про то как это организовано, можно в статье по ссылке почитать.

Итак, плюсы — какие выгоды компании это даёт:
— На рынке готовых спецов практически нет, поэтому дотягивать по качеству и скиллам иногда единственный вариант прокачать команду и получить хороший результат проектов.
— Это большой плюс при найме — к нам больше хотят, потому что мало кто себе может такое позволить.
— Средняя экспертность команды растёт, постепенно все люди дорастают до уровня, когда им можно дать любые задачи, а не думать: «Он не справится с такой задачей, что бы ему дать попроще?»
— Удержание: для сильных людей программа развития становится очень индивидуальной, но так как процессы развития и обучения поставлены на поток, сильные не остаются в стороне, а начинают сильнее влиять на бизнес и команду.
— Качество и скорость задач и проектов растут.
— Появляется единое информационное поле: новые знания быстро распространяются и внедряются.
— Выявляются стагнирующие или неразвивающиеся люди, которые тянут кор-команду на дно и занимают очень много времени сильных людей. Что делать с этим — каждый решает сам, а система позволяет это увидеть и отследить.
— Организация и постоянный обмен обратной связью позволяет держать руку на пульсе настроения команды и каждого сотрудника и можно решать не только барьеры в работе, но и психологические проблемы конкретных членов команды.

А теперь самое сладенькое, бизнесовое, про минусы:
— Деньги. Это минус 500-700К рублей в месяц из расчёта часов команды и сильных спецов. Это на команду дизайнеров в 12 человек. Ну а чё поделаешь то…
— Всех не наймёшь: нельзя чтоб в команде было больше 25% джунов или новичков — процессы и качество рушатся, кор-команда стонет и не вывозит.
— Не все кто был в восторге от системы обучения на собесе, начнут учиться. Не все кто учатся — начнут применять знания в проектах. Появится много людей, которых тянуть за уши не надо ни в коем случае. Не надо пинать и навязывать — сильные останутся, слабые уйдут.
— К нам теперь идёт поток людей учиться: «Возьмите меня хоть бесплатно и учите, а я проекты буду делать». Надо понимать, что такие «бесплатные» люди стоят даже дороже джунов — самостоятельно они делать ещё ничего не могут, а времени сильных будут выжирать очень много.

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


Сотрудники и команда — основной ресурс, без них ничего бы не было. Они и есть компания, поэтому вкладываться в развитие стратегически важно:
http://bit.ly/3aLXqY1

Что-то все начали обсуждать выгорание

Хочу высказаться, предложив для начала перестать называть хроническую усталость новым и модным словом «выгорание». Потому что ничего нового в этом явлении нет. А еще потому, что слово выгорание не дает понимания, что делать дальше и как выйти из этого состояния. Итак, вы почти точно выгорели если:

— Работали несколько (!) лет в напряженном режиме.
— Регулярно работали 9 и более часов в день и в выходные.
— Вписались в несколько проектов: 2, 3, 4 и более.
— Совмещали работу с интенсивными спортивными тренировками.
— Добавили изучение языков или другое системное образование.
— Решили строить персональный бренд: много выступали и писали тексты по ночам.
— Решили, что нужно вставать в 6-7 утра и сразу в бой.
— Было много командировок с ломаным графиком.
— Злоупотребляете кофе или другими стимуляторами для поддержки работоспособности.
— Несколько раз сталкивались с головными болями после переработок.
— 2 и более лет не брали отпуск.

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

Решение вытекает из понимания сути проблемы (усталость): остановиться и признать тот факт, что вы не биоробот, а просто человек. Избавиться от обязательств и проектов, хорошенько отдохнуть, перестроить свой график и подходы к работе ... затем вернуться к работе. Если через два дня вы застали себя в исходном состоянии, ДЕЙСТВИТЕЛЬНО перестроить график и подходы.

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

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

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

И да, кто-то должен был это сказать: люди 35+ лет с опытом работы 15+ лет нервно подергиваются когда слышат разговоры о выгорании от совсем молодых ребят.

Вы должны побывать на «дне», чтоб было с чем сравнивать

Вы должны побывать на «дне», чтоб было с чем сравнивать

— Мониторы у вас излишне чёрные и недостаточно эстетичные
— Не хочется делать проекты для behance
— Не хочется ездить в офис на работу
— Ой, чё-то я прям не могу себя заставить за эту задачу взяться

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

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

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


Вспоминаю, как пришла работать в 1C:Битрикс.
По грёбаному дождю еле нашла их офис в какой-то вонючей(буквально) промзоне. Сначала час на вот этот текст на логику с шнусмумриками…

Потом задача на цикл, которая не хотела решаться. А в результате оказалась с ошибкой в условии. Какой-то прыщавый лид-программист, чьё ЧСВ было таким же жирным как и он сам.
Скептический настрой, только потому что ты девочка.
И вообще всё это нахер ему не надо. Эти тупые кандидаты, которые не могут решить придуманную задачу. «Господи, как же вы заебали» — читалось в его уставших красных глазах.


А работа в банке Русский Стандарт.
Более депрессивный, подставляющий друг друга персонал ещё поискать: тёлочки конкурировали друг с другом, рвали бумаги, вырывали клиентов друг у друга. Двухнедельное(с утра до ночи) бесплатное обучение всей системе рассчёта кредитных продуктов, страховок, выявления мошенников и поддельных документов. Страх отчисления, ежедневные чистки, унижения. Отсутствие эмоций и поток людей. Угрозыск, задержания, показания, золотые цепи на груди. Немые младенцы мошенников. Стопки налички из рук в руки под столом.


А у других это годы в компаниях, которые ни одну задачу их умственного труда ни разу не использовали.
Агентства, где все друг друга подставляют, и где к клиенту надо с придыханием и лизь-лизь.


Для 90% компаний, люди — это мясо, средство достижения цели.
На ваши эмоции плевать. Ваши идеи никому не нужны.


Иногда нужно побывать на «дне», чтоб было с чем сравнивать и научиться ценить.


С любовью ❤️ гав-гав

Защита

Самое время рассказать пару слов о защите. Вот несколько важных вещей, которые я понял на своем опыте.

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

Второе, нужно максимально упростить повествование не уходя в детали, потому что на выступление дается всего 10-15 минут. Было непросто выбрать логику повествования — когда ты работаешь над проектом полгода, становится сложно выкинуть какие-то части. Но чтобы вас поняли, это необходимо сделать, ваш рассказ должен понять даже ребенок. Мы выбрали одну самую большую боль пользователя и обернули её в историю этого пользователя — от момента, когда он сталкивается с проблемой, до её решения. Одна проблема — одно четкое решение, тогда вас точно услышат и осознанно оценят.

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

По возможности, попробуйте свое выступление в бою с микрофоном и зрителями. Может казаться, что вы супер готовы, знаете тему, у вас классная презентация, но на выступлении вы вдруг обнаруживаете, что микрофон странно передает ваш голос, вы начинаете нервничать и забывать текст. У меня так и случилось на последней защите — я так погрузился в подготовку материалов к презентации, что самонадеянно не репетировал речь, но когда вышел на сцену понял, что это совсем непривычное для меня состояние: микрофон жутко изменял мой голос, он становился гундосым, я начинал нервничать и думаю уже не о презентации, поэтому первые минуты моего выступления ушли на адаптацию к этим неожиданным условиям.

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

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

Перед защитой всегда очень волнуешься, так как относишься к этому со всей серьезностью. Особенно сильно переживаешь за то как тебя оценят. Когда мы готовились к защите, то чувствовали себя аутсайдерами из-за того, что долго и сложно работали над UI. Но по мере подготовки презентации я понимал, что у нас получается очень крепкая история. Так и получилось — пятёрку получили только две команды: мы и qlean. И нас обеих оценили в первую очередь за то, что мы нашли боль и осознанно попытались её решить. Вы можете сами оценить наш кейс, который сверстан практически в точности по сценарию рассказа презентации.

UX

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

Блок UX ведет Антон Вдовиченко — очень крутой специалист, вероятно приз зрительских симпатий нашей группы достался именно ему. Антон знает ответ на любой вопрос, но лично для меня общение с Антоном было ценно благодаря тому, что в его лице я нашел собеседника и единомышленника на тему UX и смог задать многие интересующие меня вопросы. Так, на некоторых занятиях мы проводили UX разбор какого-нибудь приложения, и это были одни из самых интересных занятий для меня — крайне интересно копаться в неровностях существующих приложений и обсуждать лучшие практики с профессионалом своего дела.

Если продолжать тему про любимые занятия, то в первом семестре Антон в начале каждого занятия давал нам прокачку, после которой я теперь не боюсь сталкиваться с поиском быстрого и креативного решения любой проблемы. В этих прокачках нужно было очень быстро, за 10-15 минут, придумать, нарисовать и сделать бумажный прототип конкретной задачи. Например, придумать приложение по разделению счета в баре, по поиску собутыльника, приложение для знакомства в общественном транспорте, для настройки фортепиано и т.д. Круто, когда через 5 занятий до тебя наконец доходит алгоритм по которому нужно действовать, и ты начинаешь играться этими кейсами в своё удовольствие, но это уже отдельная история.
___________

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

⁃определиться с парадигмой навигации (гамбургер меню, либо таббар);
⁃найти основную работу на которую пользователи нанимают наше приложение, воспользовавшись фреймворком JTBD;
⁃составить карту экранов;
⁃составить информационную архитектуру;
⁃нарисовать вайрфреймы экранов и собрать из них прототип;
⁃протестировать прототип;
⁃подготовить отчет по тестированию и внести правки.

После чего, в идеале, с протестированным прототипом и вайрфреймами мы должны перейти к блоку UI и начать поиск своего визуального языка…
___________

Но не все так просто. По ходу работы над вайрфреймами и прототипом очень остро встает вопрос какие ограничения у нас есть и какую конечную цель мы хотим достигнуть.

Проблема в том, что главный ограничитель наших требований — мы сами. Довольно сложно не уйти в частности и вовремя остановиться, расставив ограничения самим себе.

Например, в нашем приложении есть карточка заказа — как, без реальных бизнес метрик, определить какая информация важна, а какая нет? Нужен просто адрес или подробная карта? Как подать информацию об авторе объявления? Что из этого важнее и должно располагаться выше?

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

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

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

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

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

Подводя итог — на блоке UX каждая команда сначала придумывает бизнес ограничения, а потом героически их преодолевает.

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