[от Ригнахей]
Кто считает код-ревью важным? Кому нравится проводить код-ревью?
Скорее всего, ответы на приведенные выше вопросы будут примерно такими:
я! меня! меня! Я согласен! меня! я!| чирик-чирик *тишина* чирик-чирик.
Проверка кода иногда кажется рутиной в мире разработки программного обеспечения. Но достаточно взглянуть на код, написанный программистами с небольшим опытом работы в отрасли, чтобы понять, насколько он может изменить ситуацию.
Я чувствую, что написание чистого и поддерживаемого кода — это огромный прирост производительности; даже если вы в университете работаете всю ночь, чтобы выполнить задания. И вот я пытаюсь создать личный проект или группу для код-ревью. У меня нет опыта написания отличного кода, но я готов помочь в обзоре кода и дать общие советы по программированию по парадигмам, идиомам и т. д. Я надеюсь отточить свои навыки, делая это, и получать взаимные отзывы от людей.
Первая проблема, которую я вижу в этом, — это инструмент, который я могу использовать для проверки кода моих друзей и для проверки моего кода. У многих компаний есть свои собственные внутренние инструменты и расширения для проверки кода, но мне нужен общедоступный, в идеале бесплатный инструмент, который легко интегрируется с IDE и редакторами и имеет графический интерфейс с простым созданием, просмотром и разрешением комментариев.
Быстрый поиск в Google дал мне Gerrit; что кажется разумным решением вышеуказанных требований. Я постараюсь настроить и использовать его, а также задокументировать шаги, которые я предпринял, и проблемы, которые у меня были, в этом посте.
Я только что понял, что пока мы говорим о (почти) читаемом коде, я должен всем это сказать. ПОЖАЛУЙСТА, ИСПОЛЬЗУЙТЕ ФОРМАТЕРЫ КОДА. Нет причин не использовать их. Вы можете найти расширения или плагины практически для каждого редактора, который вы используете для написания кода (если только вы не используете блокнот, в этом случае убирайтесь из моего блога; я не хочу, чтобы такие люди, как вы, засоряли мое пространство). Обычно существуют предопределенные наборы правил, которые вы можете использовать для форматирования, такие как «clang», «google» и т. д., которые вы можете использовать, и вам не нужно ничего настраивать. Вы можете заставить их «форматировать при сохранении» и наблюдать, как волшебство мгновенно делает ваш код намного более читабельным.
—
Перерыв больше недели.
—
Хорошо, поэтому, глядя на то, как интегрировать Gerrit в то, что я уже знаю о git, я обнаружил, что вы можете более или менее проводить проверки кода с помощью функции запросов на вытягивание Github. Поскольку большинство людей знакомы с Github, а не с Gerrit или любым другим специализированным инструментом для проверки кода (а я ленив), я решил пока просто использовать запросы на вытягивание Github как способ совместной работы над кодом.
