Информация

Местоположение
Россия
Сайт
career.habr.com
Численность
2–10 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 8
Былу ребят на онлайн-собеседовании (неудачном для меня) — и это было лучшее собеседование за все мое время работы вообще. За два часа «потогонки» — создали о себе крайне хорошее впечатление.
Спасибо! Найм у нас открыт непрерывно, если захотите через год попытать сил с новым опытом, мы это приветствуем.
На мой вкус жутковатые они. Настораживает, например, библиотека с Кнутом и Чего-то там интроверта.

Но я доволен что ходил к ним на собеседование. Во первых они знают что хотят спросить, а не по опроснику из интернета вопрошают. Во вторых некоторые вопросы вскрыли мои белые пятна, задели самолюбие и в итоге инициировали повышение уровня.
Всем рекомендую к ним сходить.
На мастере еще раз прогоняют пирамиду тестов, и дальше конвейер едет через другие инструменты контроля качества, например канарейку.
То есть ручных тестировщиков у вас нет, и вместо них вы используете сторонних пользователей?

Мы стараемся минимизировать количество текста, потому что текстовое описание имеет свойство быстро устаревать, так как не связано с кодом.
Текстовое описание действительно может быть не связано с кодом, но только в одном случае: если его не обновлять.
Конечно нет, вместо ручного тестирования у нас автотесты, в том числе UI/UX (puppeteer). Ручные тесты по сценарию не поспевали бы за нашим релизным циклом (несколько десятков выкладок в день, в том числе несколько выкладок основного монолита).

С текстовой спецификацией ситуация похожая: код проверяется компилятором, тестами, людьми, работающими на стейджингах и продакшне. Текстовую спецификацию можно проверить только глазами, сравнив с кодом. Начиная с определенной скорости поставки такой подход работать перестает и заменяется другими, например spec-by-example либо автоматической генерацией спецификации кодом.
Благодарю за ответ.
Жаль, что в угоду скорости разработки вы жертвуете качеством.
Отсутствие ручного тестирования как класса и комментариев в коде разочаровало.
Скорость не достигается ценой качества, это частое заблуждение.

Некачественный продукт отнимает на свою поддержку все больше времени до тех пор пока все время разработиков не занимает поддержка и разработка остановлена.

Цель успешной продуктовой разработки — зафиксировать качество и раз за разом убирать препятствия чтобы уменьшить time-to-market новых гипотез. Часто по пути меняются инструменты и роли: в нашем случае изоляция контекстов, самоописывающий код, фиксация контрактов автотестами показали себя лучше текстовых комментариев, а исключение человека из конвеера доставки позволило выкладывать изменения малыми инкрементами. В купе с blue-green deployment, покрывающим мониторингом, канарейкой, механизмом быстрого отката через это контролируются ситуации, которые не протестировать руками.

В статье в блоге мы детальнее рассказываем про эволюцию разработки и процессов качества у нас.

Если вам интересно глубже разобраться в подобных процессах, хочу порекомендовать хорошие книги Accelerate и Google SRE book — про современные процессы devops и поддержки, метрики и инструменты качества.
Мне кажется, что год в названии поста ошибочный. Не 2021 имелось в виду?

PS. Понял. Это серия статей такая была. Тогда вопрос снимается. Но выглядит немного странно :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.