Скорость не достигается ценой качества, это частое заблуждение.
Некачественный продукт отнимает на свою поддержку все больше времени до тех пор пока все время разработиков не занимает поддержка и разработка остановлена.
Цель успешной продуктовой разработки — зафиксировать качество и раз за разом убирать препятствия чтобы уменьшить time-to-market новых гипотез. Часто по пути меняются инструменты и роли: в нашем случае изоляция контекстов, самоописывающий код, фиксация контрактов автотестами показали себя лучше текстовых комментариев, а исключение человека из конвеера доставки позволило выкладывать изменения малыми инкрементами. В купе с blue-green deployment, покрывающим мониторингом, канарейкой, механизмом быстрого отката через это контролируются ситуации, которые не протестировать руками.
В статье в блоге мы детальнее рассказываем про эволюцию разработки и процессов качества у нас.
Если вам интересно глубже разобраться в подобных процессах, хочу порекомендовать хорошие книги Accelerate и Google SRE book — про современные процессы devops и поддержки, метрики и инструменты качества.
Конечно нет, вместо ручного тестирования у нас автотесты, в том числе UI/UX (puppeteer). Ручные тесты по сценарию не поспевали бы за нашим релизным циклом (несколько десятков выкладок в день, в том числе несколько выкладок основного монолита).
С текстовой спецификацией ситуация похожая: код проверяется компилятором, тестами, людьми, работающими на стейджингах и продакшне. Текстовую спецификацию можно проверить только глазами, сравнив с кодом. Начиная с определенной скорости поставки такой подход работать перестает и заменяется другими, например spec-by-example либо автоматической генерацией спецификации кодом.
Некачественный продукт отнимает на свою поддержку все больше времени до тех пор пока все время разработиков не занимает поддержка и разработка остановлена.
Цель успешной продуктовой разработки — зафиксировать качество и раз за разом убирать препятствия чтобы уменьшить time-to-market новых гипотез. Часто по пути меняются инструменты и роли: в нашем случае изоляция контекстов, самоописывающий код, фиксация контрактов автотестами показали себя лучше текстовых комментариев, а исключение человека из конвеера доставки позволило выкладывать изменения малыми инкрементами. В купе с blue-green deployment, покрывающим мониторингом, канарейкой, механизмом быстрого отката через это контролируются ситуации, которые не протестировать руками.
В статье в блоге мы детальнее рассказываем про эволюцию разработки и процессов качества у нас.
Если вам интересно глубже разобраться в подобных процессах, хочу порекомендовать хорошие книги Accelerate и Google SRE book — про современные процессы devops и поддержки, метрики и инструменты качества.
С текстовой спецификацией ситуация похожая: код проверяется компилятором, тестами, людьми, работающими на стейджингах и продакшне. Текстовую спецификацию можно проверить только глазами, сравнив с кодом. Начиная с определенной скорости поставки такой подход работать перестает и заменяется другими, например spec-by-example либо автоматической генерацией спецификации кодом.