Senior разработчик - 190 000 в месяц

[fortuneteller]

Требуется senior php разработчик

Обязанности:
Разработка кода для интернет-магазина, и обслуживающих сервисов - crm, систем управления рекламой, рассылками и других.

Знания:
- Крайне желательно знать что такое DDD и уметь думать в этой парадигме. Мы используем упрощённую версию. В крайнем случае мы научим, но придётся после работы читать выданную книжку(и) и первое время чуть больше напрягаться, чтобы освоиться с этим подходом. Зато потом станет легче гораздо. Понимать, что эффективный и надёжный код для описания сложной бизнес-логики не должен быть построен на работе с массивами и даже ActiveRecord.
- yii2 (и иногда yii1). На самом деле фреймворк не так важен, так как бОльшую часть времени вы будете писать максимально фреймворко-независимый код. А разобраться в том, как работают контроллеры или DI в yii, может любой senior разработчик. В yii1 мы используем DI контейнер - AuraDI.
- php 7.2, 7.4
- mysql, redis
- docker
- git
- очень неплохо, но необязательно, знать jquery, angular 1.5

Навыки:
- Умение писать чистый код, используя принципы SOLID. Не просто знать эту аббревиатуру, а уметь постоянно применять на практике каждый из принципов.
- Быть толерантным к легаси-коду - уметь в нём разбираться его постепенно заменять на качественное решение в тех случаях, когда придётся писать не совсем новый функционал, а стыковаться со старым кодом.
- Умение продумывать выполнение кода таким образом, чтобы максимально обрабатывать все сценарии. Код должен или работать, или завершаться с ошибкой.
- Умение и желание учиться новому.

Личностные качества:
- Умение спокойно воспринимать критику. Она никогда не бывает личной, критикуется только код и притом всегда аргументированно. Умейте так же аргументированно доказывать, почему ваш код лучше, почему вы правы.
- Быть ответственным. Код ревью будут, но желательно на ревью выдавать уже качественный код.
- Быть пунктуальным: работать предстоит по заранее согласованному графику. Идеально с 9 до 18 МСК или с 10 до 19 МСК, с часовым перерывом на обед. График можем подстроить под вас - сдвинуть часы/увеличить перерыв, но мы должны четко понимать, в какое время вы работаете, а в какое нет. Частая смена графика не приветствуется. Отлучки по форс-мажорным ситуациям, конечно же, допустимы. Недопустим вариант, при котором вы просто отрабатываете 8 часов, распределяя их по суткам на свое усмотрение.

Условия:
- заработная плата по часам из расчета 1100 руб/час, 8-ми часовой рабочий день (~190 000 руб в месяц)
- переработки возможны по вашему желанию, оплачиваются отдельно по стандартной ставке
- работа в государственные праздники - по желанию
- работать можно из дома либо, если вы живете в Москве/ближнем Подмосковье, у нас из офиса
- наличие у кандидата ИП будет плюсом
- нужен исполнитель, готовый работать на указанных условиях не менее года
- перед началом основной работы надо обязательно будет сделать тестовое задание, которое оплачивается по той же ставке 1100 руб/час. Мы выдаем задание, согласовываем оценку в часах, вы делаете, мы принимаем, оплачиваем и берем/не берем вас на фуллтайм.

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

Вопросы и предложения пишите на почту andrey.v.konst@gmail.com или в телеграм @andreykonst.

[goodfriend]

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

А что за книжки? Если не секрет.
Интересно почему вы на симфони не стали делать проект, там как раз уже с датамаппером и мудренькой архитектурой, а под yii, за все его время, так ничего и не появилось. Ни как по правильному делать с AR, ни как без нее. У всех свои "упрощенные версии" и они совсем друг с другом не стыкуются

[fortuneteller]

Спасибо за комментарий! Вы задали интерсные вопросы.

Книжки самые распространённые - Эванс, Вернон, Фаулер.

Почему не стали на симфони - потому что проект старый, в самом начале нам хватало yii, да и не сразу мы пришли к DDD. Наш сайт появился появился вместе с самой первой версией yii, вместе с ним и развивался.

DDD - это совсем не про фреймворк. Как уже было сказано, наибольшая сложность - в описании бизнес логики. Меппинг сущностей из данных - это наименьшая из проблем (да и вообще не проблема, а простая рутинная операция). В некоторых задачах мы используем AR просто как рабочую лошадку для удобного чтения и записи и меппим данные из AR в сущности при чтении сущности. А уровень предметной области будет работать и на yii и на симфони и ещё на чём угодно. Потому что он ничего не знает и не должен знать про фреймворк и про инфраструктурный слой приложения в целом.

У всех свои "упрощенные версии" и они совсем друг с другом не стыкуются.

DDD - это не некий стандарт, которому нужно следовать, не набор библиотек или протоколов, это способ мыслить о проблеме. Это помощь разработчику, чтобы не мешать то, что относится к предметной области, то что относится к сервисному слою, и то что отностится к инфраструктурному слою приложения. DDD - это набор подходов, приемов. И авторы DDD явно озвучивают - не всем нужны все подходы. Некоторые, например CQRS, нам не нужны - мы их и не используем. Так что я не понимаю, что значт "друг с другом не стыкуются". Всё что мы хотим - чтобы в кажой новой задаче разработчик думал над тем, как разделить доменные, сервисные и инфраструктурные вещи.

Так что мы не пытаемся "замудрить" архитектуру) Наоборот, мы пытаемся сложные вещи разделить на простые - так удобнее и надёжнее.

[anton_z]

У всех свои "упрощенные версии" и они совсем друг с другом не стыкуются

А во всех крупных проектах всё индивидуально, это же не конвейер простых сайтов. Даже если на sf + DDD дать делать проект разным командам, то результат будет отличаться. Если бы я присоединился к подобному проекту, я бы сначала поговорил, что из DDD и как используется, почему. На Yii, даже на 1.1, можно DDD (я делал, прикрутил DI от zend ), если без фанатизма, а понимая что и зачем, для каких целей. И правильно люди сделали, что не стали сломя голову на sf все переписывать, это чревато провалом, если проект большой и старый, а разработчиков не так много. Своими мозгами все продумывать и аргументировать это сложнее, чем с нуля на sf, потому и ставка такая.

[fortuneteller]

Совершенно верно.

Нет абсолютного зла или абсолютно правильного подхода. Для всякой задачи нужны свои средства. Я не хочу сказать, что AR - абсолютный антипаттерн и нужно всё бросать или переписывать. В главном репозитории у нас сотни AR (>300) и переписать это всё будет стоить очень много денег, а смысла в этом нет. Поэтому подход - мне разонравился AR - давайте перейдём на симфони, для нас неприменим (К тому же позволять, чтобы какая-то часть фреймворка влияла на то, отказываемся от фреймворка целиком - не очень хороший. Мы не должны быть заложниками фреймворка и можем делать что захотим и как захотим в любом фреймворке). К тому же AR хорош именно для тех целей, для которых он создавался - для простых CRUD операций.
Мы и сейчас, при использовании DDD, кое какие данные вносим через AR. Например, настраиваем условия скидок по промокоду - простой CRUD, обычные AR c обычной валидацией - зачем тут сущности и сложный меппинг данных? А вот когда промокод применяется, т.е. когда начинается хардкорная бизнес-логика - уже нужен хорошо спроектированный доменный агрегат с контролем сценариев использования и легко понимаемый разработчиками и изменяемый\дорабатываемый. Чтобы либо логика работала, либо выбрасывались какие-то эксепшны. То есть, чтобы нельзя было привести агрегат в невалидное состояние в принципе. И сохранение этого агрегата уже делается строго в репозитории четко определённым способом (хотя бы потому, что агрегат часто хранится в разных таблицах), а не в любом месте кода сущность сама себя сохраняет, как в AR. И да, мы можем при сохранении или чтении данных на уровне репозитория использовать AR для удобства чтения, данных или записи. Но наружу из репозитория выходит только доменная сущность, все AR остаются внутри. Это инфраструктурный слой, обслуживающий. Я уже писал об этом выше, повторяю, потому что это важно.

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


Используя симфони, вы не начинаете автоматом использовать DDD подход. Так же как и используя yii1,2,3 нельзя сказать, что DDD подход неприменим или даже чем-то осложнён.

[samdark]

Звучит интересно вакансия.

Используя симфони, вы не начинаете автоматом использовать DDD подход

Ну не. Сервисы делать - да. DDD - нет.

[fortuneteller]

Звучит интересно вакансия.

Если есть кому предложить - предложи, пожалуйста. Буду признателен!

Ну не. Сервисы делать - да. DDD - нет.

Я вроде то же самое и написал Использование симфони НЕ приводит автоматически к тому, что человек начинает использовать DDD. Так же как и использование Yii не говорит о том, что DDD недоступно для разработчика.
Или я не понял, что ты имеешь в виду...

[fortuneteller]

Актуально