Правила разработки в Яндекс.Здоровье

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

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

Disclaimer:

У стартапа есть свои особенности. Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью. При этом мы должны держать качество продукта на таком уровне, чтобы за него было не стыдно. [Место для флейма про отсутствующую у некоторых совесть]. Замечу, что высокая скорость доставки фич подразумевает в том числе поддержание достаточно высокого качества кода. Иначе продукт рано или поздно захлёбывается в багах.

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

Качество кода и архитектура

Мы минимизируем время доведения фичи до продакшна при сохранении приемлемого качества. Любая задача предполагает два решения: быстрое и правильное. Для любой фичи мы продумываем оба варианта так, чтобы была возможность апгрейдить быстрое решение до правильного, делая минимум ненужной работы «на выброс». Выкатив быстрое решение, некоторое время смотрим и понимаем, нужно ли правильное. Критично. Зачастую, разница по времени между тем, чтобы «решить первым попавшимся способом, забив костыль» и «решить красиво и аккуратно» – десять минут. Поэтому мы всегда думаем, перед тем как писать.

Читать дальше →