Комментарии 19
На вопрос который задали в начале так и не ответили. В итоге насколько это реально сеньоры? И главное, что такое сеньор? Я видел много разрабов с многолетним стажем, при решении задач они используют все возможные паттерны, бест практики и из-за этого получает куча кода, когда задачу можно было решить проще и понятнее. Они считаются сеньорами?
Паттерны и бест практики используют для будущего расширения и безопасности, а не для простоты. Для простоты можно писать процедурно — будет очень просто и понятно.
Вот из-за "будущего расширение" довольно часто страдает код. Многие программисты начинают решать проблемы которых нет. Для этого даже термин придумали: оверинжиниринг.
Писать просто — трудно. Не важно в какой парадигме.
Для простоты можно писать процедурноКатегорически не согласен. Просто писать — возможно, но вот читать потом такой поток сознания это очень сложно (непонятно).
То, что написано без усилий, читается без удовольствия
Понятия сеньора, мидла и джуна — это субъективное мнение каждого, у меня градация такая:
Джун — безответственный, тот за кем нужно присматривать
Мидл — ответственный, тот за кем не нужно присматривать
Сеньор — берёт ответственный других на себя, тот кто присматривает за другими
Мне всегда казалось, что эта градация мало полезна, хотя для руководства — это ориентир в вопросах зарплаты. В целом считаю каждый человек со своими плюсами-минусами, с этим нужно уметь/учиться работать, а зарплата и другие плюшки должна зависеть от персонального подхода к каждому человеку отдельно
1) Руководитель
2) Аналитик
3) Программист бэк
4) Программист фронт
5) Дизайнер интерфейсов
6) Тестировщик
7) Девопс
8) Админ баз данных
9) Админ прочей инфраструктуры.
Позиции 3, 4, 6 можно умножать под нагрузку.
Верно? или я что-то упустил?
Итого, руководитель+аналитик+тестировщик, программист+девопс или админ+девопс+DBA. И даже возможно хватает двоих. Более того, программист вполне может выполнять роль аналитика. А если у вас в команде всего двое — нафига вам руководитель?
То есть, как насчет одного человека? Ну хорошо — трех (все-таки, тестировать код лучше не автору, а отдать другому человеку, со свежим взглядом)?
Короче, вариантов полно. Все очень сильно зависит от масштабов и сложности.
Дизайнер сгодится приходящий. Не так много там дизайнить надо.
Аналитик аналогично. Целый человек. Да нет там столько работы.
Тестировщик тоже один на несколько проектов. Ну нет там столько работы.
Фронта очень хочется подсократить хотя бы наполовину. Но ладно оставлю уже. У внутренних проектов часто ужас с интерфейсами. Отдаем чтобы ужаса не было. Так что пусть будет полный.
Итого
Руководитель. Он при этом может руководить несколькими командами.
Бек
Фронт
Приходящий тест
Приходящий дизайнер
Приходящий аналитик
Все. 3 человека. До 2 урезается легко. Проект можно делать. Дальше по росту проекта уже.
У меня одного дежа вю?
Есть курьер. У него приложение отдающее координаты типовым способом для Андроида.
Значит эти координаты уже есть в некой БД.
У пользователя есть приложение. Надо просто передать эти коррдинаты в это приложение.
Связь пользователь-заказ-курьер тоже где-то точно уже есть.
Значит или читаем прямо из той БД в которой эти координаты уже есть или через любой не менее типовой транспорт (Кафка ок) перекладываем в соседнюю базу и читаем из нее. Историю не храним, сверх надежности и гарантий не надо. Делаем самый простой at least once. Небольшие потери и погрешности в этом месте нас устроят.
Взять координаты из таблички и переложить в джейсон примитивно.
Нагрузка легко шардируется по районам или ресторанам или вообще по пользователям.
Я бы по ресторанам пошардировал. Немного сложнее чем по пользователям, но обеспечим локальность данных. Пригодится потом. На самом деле пользуемся текущим шардированием.
Код пишем в сервисе работающем с клиентским приложением. Рядом со всеми остальными. Изменение не трогает текущий функционал, развалить ничего не должны. Сложность остального кода в общем не имеет значения.
Если уже микросервисный ад с микросервисами размером в пару методов, то пишем рядом аналогичный. Подключаем опять же как все остальные.
Ужасов с вызыванием других микросервисов стараемся избегать. База получается не очень большой. Миллион заказов в неделю. Пусть с мега ростом миллион в день. Это максимум сотни тысяч активных заказов. С огромным запасом. Ерунда. Все влазит в любую базу и не требует особо железа. Я бы взял Редис, но в общем дело вкуса.
Не было глупых вопросов, не было вопросов про знание SOLID, сложности алгоритмов и т.д. Была интересная задача на проектирование.
Молодец, что смог масштабировать свой подход.
У нас кросснациональные продуктовые команды
Неплохо, но в 2к20 уже не достаточно — внедряйте кроссрассовость и кроссориентационность!
По теме: воронка выглядит слегка незаконченно без шага «оффер — согласие».
Пару вопросов
- Какой процент из 50 синьоров прошел испытательный срок?
- Сколько нужно синьоров, что бы ресторану было легко и непринужденно добавить исправить блюдо в меню (сталкивался с 2 заведениями которые имели на я.еде 100 позиций в деливери 50 на вопрос почему так были озвучены нехорошие слова о добавлении и изменении меню)
- Сколько нужно синьоров, что бы при фокапе на 2 разных заказа в день было выделено 2 разных промкода.
Как нанять 50 синьоров за 43 дня и быстро включить их в процесс разработки?