Главная боль — пройденные абы как code review, где никто никаких ошибок не заметил, а в результате тимлид ночью в выходной чинит сборку.
Происходит следующая цепочка действий: разработчики исправляют баг, pullrequest проходит абы как, мержат, собирают, сборка собралась, QA проверяют что конкретно этот баг исправлен, ставят галочку, сборку отдают на объект и в результате оказывается, что исправлением сломали что-то ещё. Тимлид садится за консоль, достаёт огнетушитель и всю ночь тушит пожар.
Продукт в общем то организован так, что разные модули слабо зависят друг от друга и такие случаи редки. Но когда случаются, становится жарко всем.
Раньше мы были подписаны на code collaborator и там была полезная фича «подписываться на изменения в каких-то определённых проектах» и когда кто-то правил часть кода, которую ты хорошо знаешь — приходило оповещение и автоматически ты становился ревьювером. Сейчас пользуемся битбакетом, а там с интерфейсом pull request нет того удобства, как в code collaborator.
Даже если ботом рассылать напоминания в слаке — это не гарантирует того, что придет ревьювер которого по ошибке или по остаточному принципу назначили на ревью кода в котором тот не разбирается, быстро глянул, ткнул аппрув, в результате сборка сломана в пятницу вечером или еще хуже сломано поведение у клиента.
Увы, code review не может стать гарантом отсутствия ошибок, хотя с ним конечно улучшается качество кода, находятся «глупые» ошибки и опечатки в реализации и повышается степень совместного владения кодом. Гарантией отсутствия ошибок занимаются тестировщики, которые на каждый подобный выкат должны поинтересоваться, какой функционала «потрогали», провести смоук-тест основной фикса и всего затронутого функционала.
Отличное подспорье при этом автотесты «чёрных» и «белых» ящиков. Чтобы разработчики совсем уж не расслаблялись, в чатиках во время обсуждения этой проблемы рекомендовали ввести метрику kpi «возврат кода из тестирования».
Кстати, тестировщики после пропущенного подобного бага сами просто обязаны организоваться и провести свою собственную ретроспективу на тему «а как же мы так облажались-то?» Тестировщики очень смышлёные и их нельзя не дооценивать!
Как известно, самый главный рецепт совершения ужасной ошибки — это попытаться быстро-быстро исправить незначительную ошибку.
В книге Катрин Пассиг и Йоханнес Яндер «Программирование без дураков» подробно расписывают процесс поиска ошибки: в основном он состоит из попыток наобум что-нибудь изменить и попробовать, не заработает ли сейчас. В голове программиста при этом крутится нечто вроде: «Результат какой-то слишком маленький, сложная штука это исчисление процентов. Может, стоит всё-таки в конце умножить на сто? Да, так лучше. Ура, рабочий день закончился!»
В геймдеве, когда случился факап и все рвут на себе волосы и все в панике, а руководство обрывает телефоны с воплями «исправьте немедленно!», есть принцип: успокоится. Обдумать, что случилось и собрать всю необходимую информацию, что не ошибся и только после этого, окончательно убедившись, что нужное решение найдено, применить его.
Когда в продакшн сыпятся аффектированные ошибки (то есть в одном месте исправили, а в другом вылезло что-то новое), то скорее всего что-то не так с основной архитектурой. И пока не устранишь корень проблем они будут сыпаться и не всегда их отловят на code review или даже на тестировании.
Попросите сеньоров посмотреть на место внимательней. Когда такой баг пришёл, можно заткнуть его костылём, но нужно выбить у руководства время на то, чтобы после релиза сесть и спокойно докопаться до истины. Это позволит приучать свою команду мыслить системно. Она, как часть продукта, улучшается таким образом сама и улучшает сам продукт.
На эту тему есть отличная переводная статья «Code review по-человечески» Мишеля Линча: https://habrahabr.ru/post/340550/ и https://habrahabr.ru/post/342244/ (вот тут можно прочитать оригинал на английском: https://mtlynch.io/human-code-reviews-1/ и https://mtlynch.io/human-code-reviews-2/). Там как раз пишут про то, на что хорошо бы обращать внимание при code review.
Немного скажу про инструментарий Bitbucket. Atlassian давно уже запустил возможность создавать плагины, встраиваемые в облачную часть Bitbucket, расширяющие его интерфейс и добавляющие новые возможности. Если раньше владельцы репозиториев были ограничены вебхуками и REST API, то теперь появилась возможность допиливать «под себя» и для других разработчиков непосредственно облачный интерфейс.
Запилить свой плагин, следящий за определёнными кусочками кода, уже обычная программерская задачка. Также можно также воспользоваться готовыми плагинами: https://marketplace.atlassian.com/search?product=bitbucket
Реализовать в своём плагине обычный вочдог, который следит, какие куски кода изменились и были поданы на code review, стало просто. Это может сделать любой разработчик.
Источник: https://t.me/ctorecords/8