Image

Разработка в Google // Roman Kirillov - Google+

Разработка в Google // Roman Kirillov - Google+: https://plus.google.com/u/0/108749575809157765086/posts/doMx7i1u4hh

на  #404fest  многие люди спрашивали меня про особенности процесса разработки в Google. Великая тайна (которая, на самом-то деле, не тайна и вовсе) заключается в том, что какого-то единого процесса разработки нет - каждая команда может сама решать, как ей удобнее работать. Есть только некий очень общий набор рекомендаций, который, в сочетании со здравым смыслом, обычно дает неплохие результаты.

Рекомендации эти, в принципе, очень просты, и крайне неформальны. Если попробовать их сформулировать, то это:

1. Код важнее всего, но документация должна быть. Когда начинаешь проект, нужно написать дизайн документ хотя бы крайне приблизительно - велика вероятность, что ты перепишешь примерно 150% этого документа (т.е. некоторые места не по разу), но даже черновик позволяет отловить массу глупых логических ошибок.

2. Когда написан черновик, иди и создавай прототип. Не сильно парься по поводу тестирования на этом этапе - скорее всего, ты все перепишешь, но пиши юнит-тесты: они не занимают много времени, но позволят тебе его сэкономить на этапе переписывания.

3. Релизь часто, раз в две недели или чаще. Разработка должна быть итеративна, твое видение продукта будет уточняться с каждой итерацией.

4. Дизайн-документ тоже должен обновляться с каждой итерацией. Тесты с каждой итерацией должны становиться все более детальными, так, чтобы к моменту беты у тебя было 100% покрытие как юнит, так и интеграционными тестами.

Легко видеть, что эте рекомендации очень легко совместими практически с любой методологией разработки (кроме чистого waterfall, разумеется). У нас есть команды, которые практикуют довольно формальный подход (как правило, это "корневые" продукты вроде search или ads), а есть те, процесс которых со стороны понять достаточно сложно (или они придерживаются крайне неформального подхода). Однако практически во всех случаях эти рекомендацию соблюдаются, и следы этого подхода можно найти как в абсолютно красноглазных проектах, которыми инженеры занимаются в свое 20%-время, так и в огромных монстрах вроде GMail и ему подобных (потому как вторые обычно вырастают из первых).