Встречайте Critic: система инспектирования кода в Opera Software

Внутренняя система инспектирования исходного кода Critic, применяемая в Opera Software, вчера вечером была выложена на Github под лицензией Apache License 2.0.

Иногда системы инспектирования кода ругают за то, что они совершенно не приспособлены к процессу коммерческой разработки. Это не про Critic. Critic опробован в процессе коммерческой разработки софта в больших проектах большой компании, и отлично себя показал. Очень рекомендую попробовать этот замечательный интсрумент и вам.

Скачать исходные коды Critic можно здесь: github.com/jensl/critic.

Critic был написан шведским разработчиком Opera по имени Jens Lindström. Его не устраивали существующие системы инспектирования кода, поэтому он решил написать свою. Кстати, Йенс знаменит не только этим. Те, кому интересно, могут поискать в инете его посты про JS-движок Оперы Carakan.

Critic писался под конкретные нужды и задачи Оперы. Автор этого инструмента был также и его пользователем. Он старался сделать инструмент практичным и полезным и для себя, и для остальных разработчиков. Как пользователь Critic, наблюдавший его взросление и обрастание полезными фичами, я думаю, Йенсу это удалось. Critic получился удобным и эффективным инструментом, экономящим время своих пользователей.

Critic представляет из себя Web-приложение и написан на Python. Critic тесно интегрирован с Git. Ваши коммиты добавляются в review, как только вы протолкнули их в Git репозиторий, за которым наблюдает Critic.

Цикл инспектирования происходит следующим образом:

1. Автор review коммитите свой код в Git-репозиторий, за которым наблюдает Critic.
2. В зависимости от способа коммита, review может быть создано автоматически при git push, или вручную через Web-интерфейс Critic.
3. Как только review создано — инспектора и наблюдатели за тем кодом, который подвергся изменению, будут уведомлены об этом по e-mail.
4. Инспектора и наблюдатели могут добавлять записи о проблемах и заметки к коду. Только инспектора могут помечать изменённый код, как проинспектированный. Проинспектированный код — не значит одобренный. Это значит, что инспектор проверил его и создал записи обо всех проблемах, которые нашёл.
5. Автор review участвует в обсуждении проблем и заметок, а также проталкивает в review новые коммиты, которые исправляют найденные проблемы. Новые коммиты помечаются, как непроинспектированные. Пункты 4-5 могут повторяться много раз.
6. Когда все коммиты проинспектированы и не осталось ни одной открытой записи о проблемах — review считается одобреным.
7. Одобренное review может быть переоткрыто, также как, например, баг в BTS. Закрытые записи о проблемы также могут быть переоткрыты. И конечно, можно добавить новые проблемы к уже проинспектированному коду. Философия — как в BTS. Есть определённый workflow, и ему обычно следуют, но если нужно — можно вернуться и на предыдущую фазу этого workflow.

Некоторые замечания:

1. Записи о проблемах могут относиться ко всему review, к коммиту или к определённым строкам кода. Эти строки кода могут и не быть частью коммита, т.е. могут быть частью «нетронутого» кода, например, когда коммит меняет поведение нетронутого кода. Если запись о проблеме относится к определённым строкам кода и эти строки исправлены в следующем коммите — проблема помечается как «адресованная» этим коммитом. Новый коммит, однако, помечается как непроинспектированный, так что всё review не может автоматически стать одобреным. Это одна из фич, которая экономит время при работе с системой.
2. Critic поддерживает «переписывание истории». Звучит страшно, но бывает полезно, особенно когда «переписывание» происходит на параллельной Git ветке через git rebase -i. Например, если ваше review разрослось до 50 коммитов, и многие из этих коммитов — мелочи вроде мелких багфиксов, фиксов компиляции, переименований переменных, редактирований комментариев и прочие «подчистки» — это замусорит вашу историю в VCS. В таких случаях бывает полезно «прилепить» все эти промежуточные фиксы к тем коммитам, которые они исправляют, прежде чем отдавать свою ветку на интеграцию в основной код проекта. Таким образом, в основной ветке проекта всегда будет красивая история, а не бардак. Ну, или почти всегда. Итак, если вы провели такую операцию и превратили 50 «плохих» коммитов в 5 «хороших», с тем же содержанием — Critic не будет просить проинспектировать этот код по второму разу. Чтобы всё получилось, суммарный diff 50 «плохих» коммитов должен быть 100% идентичен суммарному diff-у 5 «хороших» коммитов. Переписанная история будет опубликована в review.
3. Critic также поддерживает смену точки ответвления review. Предположим, вы ответвили ветку review от вершины основной ветки проекта. За время инспектирования основная ветка проекта ушла вперёд. И вашей ветке надо изменить код в соответствии с новыми реалиями основной ветки. Что же делать, создавать новое review и терять всю уже проделанную работу над этим review? Как бы не так. Critic поможет вам и здесь. Все коммиты можно скопировать на новую точку ответвления, с помощью того же git rebase, и указать Critic, куда именно вы перенесли точку ответвления. И он всё поймёт! И не станет просить проинспектировать тот же код второй раз. И не попросит проинспектировать тонны кода из основной ветки. Зато заметит, что вы разрешили merge conflicts, и попросит инспекторов проверить, правильно ли вы это сделали. Ну разве не молодец?
4. Critic поддерживает расширения. «Это же сейчас модно.» Расширения могут, очевидно, расширять функциональность Critic и ещё больше экономить ваше время. Расширения могут реализовывать различную специфическую функциональность, нужную не всем пользователям. Поэтому каждый пользователь сам устанавливает себе те расширения, которые ему нужны. Предположим, вы работаете над проектом Х. Фиксите баги. В review изначально был 1 коммит для багфикса, но инспектора попались очень строгие, и пришлось коммитнуть ещё 5 фиксов к фиксу, чтобы их удовлетворить. Наконец-то review одобрено. И вам предстоит немного простой, но нудной формальной работы по коммиту фикса. Кто-то с вашего проекта решил облегчить жизнь своим товарищам по команде и разработал расширение для вашего проекта. Расширение добавляет в Web-интерфейс кнопку «Интегрировать багфикс в проект Х». Теперь вы можете нажать сию волшебную кнопку, и Critic сделает для вас много полезного:
   
   • Соберёт ваши 6 коммитов в 1.
   • Предложит к нему комментарий от первого коммита.
   • Предложит поредактировать комментарий.
   • Проверит, нет ли merge conflicts с ушедшей вперёд основной веткой проекта, или веткой для багфиксов.
   • Закоммитит фикс в ветку для багфиксов.
   • Закроет review в Critic.
   • Напишет что-нибудь хорошее в BTS.
   • Закроет баг в BTS.

5. Critic не является оболочкой вокруг основного репозитория проекта, как, например, Gerrit. Поэтому Critic можно использовать как для pre-commit review, так и для post-commit review, как удобно вашей организации. Critic, однако, может подтягивать код из основного репозитория, или делить с ним один репозиторий. А также толкать код туда с помощью расширений, как показано в предыдущем пункте.