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