Канал с ответами на сложные вопросы: https://t.me/ctorecords

Простите, а ответ будет когда сколько лайков наберется? :)

Прежде всего я хочу сказать спасибо за это довольно необычный вопрос, фокусирующийся не на аспектах тестирования, как может показаться по-началу, а вопросах самой разработки и подготовки кода к тестированию! Тема интересная и неординарная, – я сделал для себя ряд неожиданных откровений в процессе подготовки ответа.

Увы, 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, уже стало просто. Это может сделать любой (вообще любой) разработчик.

Также хочу обратить внимание на самих разработчиков, – очень удобно их разбивать на пары старший-младший, когда от старшего опыт постепенно перетекает младшему. Один пишет тесты, другой код. Один разрабатывает архитектуру, другой реализацию. Один пишет, другой проводит code review. И постоянно при это меняются. Не всегда эта методика оправдана, но для повышения качества её удобно вводить хотя бы временно!

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

Все в курсе, что такое и для чего нужны системы CI и CD. В них в том числе принято встраивать автотесты, которые помогут поставить ещё один заслон перед багам. В целом такие системы называются системами непрерывных апдейтов. Есть специально книга про это Эберхарда Вольфа «Continuous delivery. Практика непрерывных апдейтов». Для общего развития рекомендую почитать её, чтобы лучше понимать происходящее в цепочке доставки продукта до енд-юзеров.

Также существуют системы постоянно контроля качества кода. Почитать можно здесь https://ru.wikipedia.org/wiki/SonarQube и https://habrahabr.ru/company/pvs-studio/blog/315422/ Это уже ближе к code review автоматизированному.

Прнимаю новые вопросы, друзья! :)

Относительно код-ревью - не скажу что у меня большой опыт, однако проблема с быстрыми CR есть. По моим наблюдениям, здесь еще вопрос в его значимости в точки зрения разработчика. В теории было бы интересно наличие каких-то рекомендаций по проведению ревью,  содержащих основные моменты на которые хорошо бы обращать внимания при его проведении. Это внесет дополнительную ясность и некоторые единообразие. Как вы думаете, насколько это может быть полезным/интересным?

Всем привет. По предыдущему вопросу. Мы делаем так, что разработчик вносящий правку в код пишет в тикете джиры примечание для тестировщика, какие части системы надо проверить. Ведь обычно разработчик может быстро посмотреть, где еще используется код, который он поправил. Т.о. тестировщики тестируют не только правку, но и связанный функционал. Если правка затрагивает много (правили базовый класс) или зависимости сложно отследить, то тестировщикам ставится задача провести полное или частичное регрессионное тестирование. У тестеров в свою очередь есть планы для таких тестирований, они проходят по ним и т.о. мы уверены, что если баг и просочился в продакшн, то он не затрагивает основной функционал. Конечно, иногда бывает необходимо выкатить правку в пятницу вечером, и тимлид в выходной день за клавиатурой все равно бывает.

Яростно плюсую! Кроме того, что сам совет весьма дельный, я ещё успел поработать вместе с Русланом над весьма непростым со всех сторон проектом, - к мнению Руслана прислушиваться must! :)

Но тут тема была именно про code review, как оказалось это довольно богатая тема :)

Сейчас попробую собрать воедино основные мысли :)

Руслан! А Ты сам по каким принципам проводишь code review?

С код-ревью у меня прохладные отношения, мы его используем редко. Частично из-за того, что мы используем методологию git flow и разрабостчики сами вливают свои коммиты в dev. Частично (и это более веская причина) из-за того, что несколько раз я пробовал его вводить и редко кто находит неэффективный или ошибочный код, зато многие предпочитают делать замечания к code-style.

Начинаются длинные обсуждения про длину строки, это неэффективно :)

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

Аналогично )) всегда так делал (оставлял комментарий), даже когда ещё был мидлом.

А недавно мы у себя в jira отдельное поле добавили, чтобы статистику собирать «что могло бы предотвратить это баг?»
-Более проработанные требования
-Кодревью
-аккуратность разработчика (поспешил/поленился)
И другое

При переводе бага в тестирование разработчик тыкает галочку-причину (это не отменяет комментария)

у нас gofmt решает частично вопрос по кодстайлу

как раз в статье "Code review по-человечески" есть про это

Спасибо, почитаю.

Вопрос №2. Коллеги хотел бы спросить вашего мнения. Что на ваш взгляд главная мотивация для разработчиков: деньги или интересность задач?

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

Ответ на вопрос №2

Огромное спасибо за вопрос, - он позволят посмотреть на сущетсвующие команды с несколько иной позиции. С позиции балансировки между опытом и молодостью :)

Интересные задачи - это обозначает, что сам продукт интересный и Ты работаешь на карму. Можно с ноги заходить к работодателям) А уж если влияешь на продукт - тем более.

Не будет работать на семейных, - им тупо нужны деньги. Не до понтов.

С другой стороны - просто бабло не стимулирует инициативности. Тут как правило скатываются в ремесленничество. Соответственно накапливается технический долг и проект через какое-то время отстаёт по технологиям

Так что обычный состав команды - баланс между молодыми, желающими понтов/новых технологий и опытными проводниками, уже протоптавшими свои тропинки на полях граблей.

Компенсируют молодые свои увлечения новыми технологиями тем, что они энерджайзеры. Сваливай смело на них годовой объём работы, - продуют за месяц.

С другой стороны опытные проводники по полям граблей - этим просто бабло. У них много знаний и опыта, - но меньше энергии.

Поэтому мотивация между интересными задачами и бабло - это регулирование состава команды. Хочешь двигаться быстрее - наращиваешь понты. Хочешь двигаться безопаснее - наращиваешь бабло.

Есть ещё один аспект этой темы - съесть вместе семь пудов соли: невероятно слаживает команду. Со слаженной командой можно брать сложные проекты. С неслаженный огромной риск все просрать, так как эта команда заходит на грабельные поля и протаптывает свои собственные тропинки. В этом случае надо молиться, чтобы тропинки были протоптаны раньше, чем закончатся деньги)

Слаженная команда (то есть команда, протоптавшая за счёт работодателя тропинки на полях граблей) - это большая ценность. Береги ее. Ценность заключается в том, что потеряв эту команду, Тебе придётся искать бабло для протаптывания тропинок новой командой. А кто-то сэкономит свои деньги на том, что украл Твою команду.