Процесс будет описан так, как это принято в Авито. В других компаниях он может отличаться, так как компании выстраивают внутренние процессы под себя, исходя из практического опыта. Полное описание процесса-TDR читайте в плейбуке компании. Модель зрелости проектных решений Рассмотрим упрощенную модель “зрелости” по реализации проектных решений разбитую на 5 уровней: Уровень 1 Пишем код Уровень 2 Пишем код -> Согласовываем Уровень 3 Согласовываем -> Пишем код Уровень 4 Согласовываем -> Пишем код -> Документируем решение Уровень 5➤ Читать полностью...

Надеюсь, все знакомы с этой задачей, но если нет, то можно прочитать статью для контекста и попробовать себя на литкоде (задача уровня easy). В феврале этого года я создал репозиторий fizz-buzz-world, который оформил так, чтобы в него можно было легко контрибьютить: написал несколько своих решений, добавил простых тестов на логику и организовал понятный ридми-файл с призывом добавлять свои реализации классической задачи. Цель была простая - собирать нетривиальные решения Fizz Buzz на Go.➤ Читать полностью...

Многие, переходя на Go, начинают искать простой и удобный способ по работе с базой данных. Разработчики так привыкли, и это нормально. Когда я писал на C#, то использовал Entity Framework Core - ORM для платформы .NET. А так как это был мой первый язык, то мне казалось это вполне естественным и об альтернативах я вообще не задумывался (возможно, на .NET тогда их и не было, не знаю есть ли сейчас).➤ Читать полностью...

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

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

Вчера было ровно 2 года с момента, как я работаю в Авито. За это время мне удалось качественно вырасти как специалист. У меня отличная команда, которая поддерживает друг друга, помогает достигать результата и готова разделить любой досуг. Конечно, есть ощущение, что не всем так повезло с коллегами и ситуации бывают разные. Но именно для этой цели существует финальное интервью (или фит-интервью), которых у меня при трудоустройстве было целых три. Если меня спрашивают куда лучше идти работать, часто призываю стремиться именно в крупные компании.➤ Читать полностью...

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

За всю карьеру не вспомню ни одного момента, когда я не думал о создании своего сайта/блога. Даже, когда был рядовым инженером, была идея завести свою страницу-портфолио, куда смогу публиковать проекты, над которыми работал. В этом году даже ставил себе одну из целей - завести собственный блог на отдельном домене. Шло время, но ничего не двигалось, так как я понимал, что нужны ресурсы на это: время и деньги для инфраструктуры. И, если то, что решалось деньгами (покупка домена и VPS) меня не пугало, то мысль о том, что нужно писать фронтенд, когда ты бэкенд - тормозила и заставляла откладывать эту историю.➤ Читать полностью...

Одной из важнейших компетенций, на которую смотрят при возможном пересмотре грейда, является “инженерная культура”. В Авито на уровень E5 (синьор) ее признаки обозначаются как: Улучшает общие инженерные инструменты компании. Тестирует сложные корнер-кейсы. Проектирует тестопригодные системы и исправляет те, которые сложно тестировать. Ищет неэффективные места в коде/архитектуре/тестовых моделях. Пополняет технический бэклог команды. Устанавливает и тестирует нефункциональные требования или привлекает для этого экспертов. Знает и использует безопасные подходы к реализации функциональности. Когда целишься в следующий грейд, то полезно время от времени сверяться с ожиданиями на нем, чтобы была возможность их продемонстрировать.➤ Читать полностью...

Вчера ставил расширение на VS Code, которое поддерживается коллегами для внутреннего удобства разработки. Простой плагин, который раскрашивает brief-файлы (корпоративный стандарт для описания контрактов по типу protobuf, подробнее почитать здесь), подкинул очередную задачку. В Больших компаниях принято писать документацию. Хорошо, когда она есть, но важнее, чтобы она находилась в актуальном состоянии, иначе никто ей не будет пользоваться. К плагину прилагалась простая инструкция: Скачать vsix файл: wget http://<extension-directory>.vsix Добавить его в VSCode: Extensions -> … -> Install from VSIX -> .➤ Читать полностью...