Прежде всего я хочу сказать спасибо за это довольно необычный вопрос, фокусирующийся не на аспектах тестирования, как может показаться по-началу, а вопросах самой разработки и подготовки кода к тестированию! Тема интересная и неординарная, – я сделал для себя ряд неожиданных откровений в процессе подготовки ответа.
Увы, 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, уже стало просто. Это может сделать любой (вообще любой) разработчик.