Comments 8
UFO just landed and posted this here
Спасибо! Найм у нас открыт непрерывно, если захотите через год попытать сил с новым опытом, мы это приветствуем.
-1
На мой вкус жутковатые они. Настораживает, например, библиотека с Кнутом и Чего-то там интроверта.
Но я доволен что ходил к ним на собеседование. Во первых они знают что хотят спросить, а не по опроснику из интернета вопрошают. Во вторых некоторые вопросы вскрыли мои белые пятна, задели самолюбие и в итоге инициировали повышение уровня.
Всем рекомендую к ним сходить.
Но я доволен что ходил к ним на собеседование. Во первых они знают что хотят спросить, а не по опроснику из интернета вопрошают. Во вторых некоторые вопросы вскрыли мои белые пятна, задели самолюбие и в итоге инициировали повышение уровня.
Всем рекомендую к ним сходить.
+2
На мастере еще раз прогоняют пирамиду тестов, и дальше конвейер едет через другие инструменты контроля качества, например канарейку.То есть ручных тестировщиков у вас нет, и вместо них вы используете сторонних пользователей?
Мы стараемся минимизировать количество текста, потому что текстовое описание имеет свойство быстро устаревать, так как не связано с кодом.Текстовое описание действительно может быть не связано с кодом, но только в одном случае: если его не обновлять.
+1
Конечно нет, вместо ручного тестирования у нас автотесты, в том числе UI/UX (puppeteer). Ручные тесты по сценарию не поспевали бы за нашим релизным циклом (несколько десятков выкладок в день, в том числе несколько выкладок основного монолита).
С текстовой спецификацией ситуация похожая: код проверяется компилятором, тестами, людьми, работающими на стейджингах и продакшне. Текстовую спецификацию можно проверить только глазами, сравнив с кодом. Начиная с определенной скорости поставки такой подход работать перестает и заменяется другими, например spec-by-example либо автоматической генерацией спецификации кодом.
С текстовой спецификацией ситуация похожая: код проверяется компилятором, тестами, людьми, работающими на стейджингах и продакшне. Текстовую спецификацию можно проверить только глазами, сравнив с кодом. Начиная с определенной скорости поставки такой подход работать перестает и заменяется другими, например spec-by-example либо автоматической генерацией спецификации кодом.
0
Благодарю за ответ.
Жаль, что в угоду скорости разработки вы жертвуете качеством.
Отсутствие ручного тестирования как класса и комментариев в коде разочаровало.
Жаль, что в угоду скорости разработки вы жертвуете качеством.
Отсутствие ручного тестирования как класса и комментариев в коде разочаровало.
+1
Скорость не достигается ценой качества, это частое заблуждение.
Некачественный продукт отнимает на свою поддержку все больше времени до тех пор пока все время разработиков не занимает поддержка и разработка остановлена.
Цель успешной продуктовой разработки — зафиксировать качество и раз за разом убирать препятствия чтобы уменьшить time-to-market новых гипотез. Часто по пути меняются инструменты и роли: в нашем случае изоляция контекстов, самоописывающий код, фиксация контрактов автотестами показали себя лучше текстовых комментариев, а исключение человека из конвеера доставки позволило выкладывать изменения малыми инкрементами. В купе с blue-green deployment, покрывающим мониторингом, канарейкой, механизмом быстрого отката через это контролируются ситуации, которые не протестировать руками.
В статье в блоге мы детальнее рассказываем про эволюцию разработки и процессов качества у нас.
Если вам интересно глубже разобраться в подобных процессах, хочу порекомендовать хорошие книги Accelerate и Google SRE book — про современные процессы devops и поддержки, метрики и инструменты качества.
Некачественный продукт отнимает на свою поддержку все больше времени до тех пор пока все время разработиков не занимает поддержка и разработка остановлена.
Цель успешной продуктовой разработки — зафиксировать качество и раз за разом убирать препятствия чтобы уменьшить time-to-market новых гипотез. Часто по пути меняются инструменты и роли: в нашем случае изоляция контекстов, самоописывающий код, фиксация контрактов автотестами показали себя лучше текстовых комментариев, а исключение человека из конвеера доставки позволило выкладывать изменения малыми инкрементами. В купе с blue-green deployment, покрывающим мониторингом, канарейкой, механизмом быстрого отката через это контролируются ситуации, которые не протестировать руками.
В статье в блоге мы детальнее рассказываем про эволюцию разработки и процессов качества у нас.
Если вам интересно глубже разобраться в подобных процессах, хочу порекомендовать хорошие книги Accelerate и Google SRE book — про современные процессы devops и поддержки, метрики и инструменты качества.
0
Мне кажется, что год в названии поста ошибочный. Не 2021 имелось в виду?
PS. Понял. Это серия статей такая была. Тогда вопрос снимается. Но выглядит немного странно :)
PS. Понял. Это серия статей такая была. Тогда вопрос снимается. Но выглядит немного странно :)
0
Sign up to leave a comment.
Где работать в ИТ в 2020: Mindbox