Pull to refresh

Comments 23

А как вы осуществляете переход на новое ядро Chromium при таком объеме кода?

Регулярно проводим мёрж со стабилизацией после него. Про это нужен отдельный БОЛЬШОЙ рассказ. Война войной, а мёрж по расписанию.

А мониторинг тестов у вас есть?
Я встречал в своей практике ассерт на true, который разумеется всегда срабатывал. Ревью коллег, которые пишут такие же ассерты, может не помочь.

Для таких тестов можно использовать мутационное тестирование, которое поможет выявить accert на true.

PIT мы пробовали прикрутить, но пока не взлетело. Тесты ведь проходят кодревью как обычный код. Статические анализаторы часть багов и тупняков в тестах подсвечивают, ревьюверы при некотором опыте их тоже видят.

А писать эти тесты будут авторы ассертов на true? Или их такие же коллеги?
Ну, как бы, мутационное тестирование не предполагает ручного написания тестов.
Берём кусок кода, который покрыт тестами и вносим в него мутации. Автоматом.
Те тесты, которые не упали считаются неправильными или избыточными. К ним, как минимум, стоит присмотреться.
Я с гордостью могу сказать, что у нас время от создания pull request до попадания кода в репозиторий сейчас составляет около 30 минут.


Привет! Не очень понятно, если у вас 30 минут — это время сборки, то как за 30 минут вы успеваете всё это вмёрджить? Я имею ввиду, чтобы 2 разрабочтика провели ревью кода, нужно довольно много часов, наверное (пока программисты найдут у себя время, пока скажут своим замечания, пока код будет поправлен). Или я что-то упускаю?
Это минимальное время. Сборка, тесты, статический анализ. Меньше этого времени не получится.
Пока идёт сборка, тесты и анализ, ревьюверы могут успеть посмотреть ПР, если изменения компактные, а ревьюверы оперативны.
Главное — не фиксить старые баги, а следить за тем, чтобы не было новых

Вот поэтому сейчас весь софт и глючит, обидные баги, которые можно за пять минут пофиксить — годами висят. Главное что тесты проходит все приложение. А эти минорные баги — подождут, довольно часто до смерти продукта.

Вы вырываете фразу из контекста. Речь шла про баги в старом коде, найденные статическими анализаторами. Обычный пользователь такие "баги" не увидит никогда. При этом чинить их просто вредно, т.к. можно сделать настоящие баги вместо мнимых.

UFO just landed and posted this here

Попробуйте прогнать статический анализ кода на своем проекте. Если раньше не гоняли и не исправлял, вам найдут 100500 проблем, большая часть которых будет False Positive по разным причинам. Их чинить не надо. True Positive же разделятся по важности, от неизбежно приводящих к ошибкам и крешам (blocker) до предложений по улучшению кодстайла. Блокеры мы обязательно все исследуем и чиним. Не блокеры почти всегда чинить нецелесообразно, это будут изменения ради изменений. Люди не любят таким заниматься

Когда поломается — тогда и починится, а тратить N часов на фикс бага, который можно отловить только статическим анализатором — спорное решение, имхо
Поправьте ссылочку на Yandex QA Tools. Спасибо
Хорошая, интересная лекция. Ещё одна хорошая попытка Яндекс, но нет.
Ох))) Неужели никто не замечает как начинает тормозить телефон после запуска яндекс.браузера, если у тебя установлено ещё штук 5 приложений от яндекса?
Кейс такой — Едете вы на работу в метро, открываете яндекс.браузер и тут бац, параллельно запускаются карты, навигатор, парковки и такси.
В результате 50% CPU телефона занято непонятно чем, все начинает тормозить, музыка в наушниках подвисать, а Вы тут хвастаетесь успехом в разработке?)))
История о том как покрывали тестами код реально тронула!
Мы на проекте тоже решили покрывать тестами и пока еще стонем от этой боли, но вера в то что все будет хорошо пока живет)

Как вы имплиментируете новый функционал? Вы используете TDD, или разрабатываете функционал, а потом покрываете его тестами, или тесты пишутся строго в отведенные 30% каждого месяца?

TDD не используем. Некоторые коллеги в таком стиле пишут фичи, но в целом — нет.
Тесты пишутся одновременно с кодом и в пулреквестах ревьюверы требуют их наличия и качества
У нас есть test smells, отдельная страничка, где фиксируются типичные проблемы, которые возникают при написании тестов в режиме «так плохо, а так было бы хорошо»

А насколько специфична данная страничка? Есть там общие моменты в области написания текстов? Ее можно причесать и выложить на Хабр? Было бы очень любопытно взглянуть.
Sign up to leave a comment.