Файл: Методы организации работы в команде разработчиков. Системы контроля версий.pptx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.01.2024
Просмотров: 225
Скачиваний: 6
СОДЕРЖАНИЕ
Методы организации работы в команде разработчиков.
Системы контроля версий решают следующие проблемы:
Децентрализованные системы контроля версий
Современные системы контроля версий
Исследования программного кода
Методы анализа программного кода
Выделяют несколько методов анализа кода для его проверки:
Статический анализ (статистические анализаторы)
Динамический анализ кода решает ряд важных задач, в частности позволяет:
Механизмы и контроль внесения изменений в код
Механизм ветвления проекта в СКВ
Официальный сайт: https://empear.com/
https://www.visual-expert.com/EN/lp-ve-download-source_adv914ve.html?single
Официальный сайт: http://codebrag.com/
Официальный сайт: https://www.gerritcodereview.com/
Официальный сайт: http://codestriker.sourceforge.net/
Официальный сайт: https://rhodecode.com/
Официальный сайт: https://www.phacility.com/phabricator/
Официальный сайт: https://www.atlassian.com/software/crucible
Официальный сайт: https://www.veracode.com/
Официальный сайт: https://www.reviewboard.org/
Ревью кода системы средствами Git
https://github.com/oktend/system-review-example/pull/1/files
Теперь наши ветки выглядят примерно так:
В созданном merge request можно увидеть все собранные в ходе ревью замечания, даже обсудить их.
Состояние, для которого были выдвинуты замечания будет зафиксировано пока ветку явно не удалят.
Замечания можно делать как в отрыве от кода:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/foo.js
К ревью можно будет вернуться в будущем сохранив замечания и контекст, в котором они были выдвинуты.
Как правильно делать код-ревью
Codestriker имеет лицензию под GPL.
Официальный сайт: http://codestriker.sourceforge.net/
7) Родекод
ключевая характеристика:
Rhodecode-это инструмент управления открытым исходным кодом, защищенным и инкорпорированным корпоративным исходным кодом.
Rhodecode служит интегрированным инструментом для Git, Subversion и Mercurial.
Основными функциями Rhodecode являются совместная работа с командой, управление репозиторием и безопасность и аутентификация кода.
Rhodecode имеет 2 выпуска, Community Edition (CE) который является бесплатным и открытым исходным кодом и Enterprise Edition (EE) лицензируется на одного пользователя.
Rhodecode автоматизирует рабочие процессы для быстрого выполнения.
Официальный сайт: https://rhodecode.com/
8) Phabricator
ключевая характеристика:
Инструмент проверки кода от Phabricator suite называется “дифференциальный". Он используется для минимизации усилий, необходимых для создания кода наилучшего качества.
Phabricator имеет два типа рабочих процессов проверки кода, а именно “предварительный толчок”, также называемый “обзором”, и “пост-толчок”, называемый “аудит”.
Phabricator может быть интегрирован с Git, Subversion и Mercurial.
Официальный сайт: https://www.phacility.com/phabricator/
9) Тигель
ключевая характеристика:
Тигель гибкое применение которое приспосабливает обширный ряд подходов к работы и размеров команды.
Crucible-это легкий инструмент для проверки однорангового кода, который используется в обзорах до и после фиксации.
Обзор кода стал легким для SVN, Perforce и CVS и т. д. С помощью Crucible.
Официальный сайт: https://www.atlassian.com/software/crucible
10) Veracode
ключевая характеристика:
Veracode используется разработчиками при создании защищенного программного обеспечения путем сканирования двоичного кода или байтового кода вместо исходного кода.
С помощью Veracode можно идентифицировать неправильные зашифрованные функциональные возможности, вредоносный код и бэкдоры из исходного кода.
Veracode может просмотреть большое количество кода и сразу же возвращает результаты.
Для использования Veracode нет необходимости покупать какое-либо программное или аппаратное обеспечение, вам просто нужно оплатить необходимые службы analysis services.
Официальный сайт: https://www.veracode.com/
11) Наблюдательный Совет
ключевая характеристика:
Используя обзорную доску для обзора кода можно сэкономить деньги и время. Сэкономленное время можно использовать для концентрации на создании отличного программного обеспечения.
Обзорная доска может быть интегрирована с ClearCase, CVS, Perforce, пластиком и т. д.
В коде review by Review Board tool, код является синтаксис выделен, что делает его чтение быстрее.
Обзорная доска поддерживает обзоры до фиксации и обзоры после фиксации.
Официальный сайт: https://www.reviewboard.org/
Ревью кода системы средствами Git
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого Git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
Замечания могут устареть уже в процессе написания, так как разработка может продолжаться.
Сложно ссылаться на отдельные участки кода, так как приходится постоянно переключаться между документом и кодом.
В отрыве от кода документ затеряется с довольно высокой вероятностью.
Проблематика
Найдем состояние в репозитории для ревью (на момент ревью это был последний коммит в dev): https://github.com/oktend/system-review-example/commit/0514531a35edf19e7032eb49f45a98d019f83efe
Ветвим от выбранного состояния ветку для нашего системного ревью, например "system-review/1march2020-goodman": https://github.com/oktend/system-review-example/tree/system-review/1march2020-goodman
Метод ревью кода системы
Создаем от вновь созданной ветки еще одну ветку, в которой будем собирать замечания, например "1march2020-goodman-issues": https://github.com/oktend/system-review-example/tree/system-review/1march2020-goodman-issues
Вносим в эту ветку удобным нам способом наши замечания, как прямо в код, так и в отдельные документы.
Создаем merge request (может называться pull request) к ветке для ревью "system-review/1march2020-goodman-issues" -> "system-review/1march2020-goodman":
https://github.com/oktend/system-review-example/pull/1/files
Теперь наши ветки выглядят примерно так:
https://github.com/oktend/system-review-example/network
Результат
В созданном merge request можно увидеть все собранные в ходе ревью замечания, даже обсудить их.
Состояние, для которого были выдвинуты замечания будет зафиксировано пока ветку явно не удалят.
Замечания можно делать как в отрыве от кода:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/review-1march2020-goodman.md
так и в контексте кода:
https://github.com/oktend/system-review-example/blob/c80b03710059b235347ec781bf08dca9c0e68f7d/foo.js
Замечания можно просматривать в веб-интерфейсе github (или аналогов), в IDE, или средствами самого git.
К ревью можно будет вернуться в будущем сохранив замечания и контекст, в котором они были выдвинуты.
Как правильно делать код-ревью
CL: «changelist» — список изменений кода, отправленный в систему контроля версий на ревью.
Аналоги:
PR: «Pull Request» в GitHubMR: «Merge Request» в GitLab
Терминология:
1.1. Менторство
1.1. Менторство
1.2. Принципы
1.3. Разрешение конфиликтов
1. Стандарты код-ревью
2. На что обращать внимание в ревью
2.1. Дизайн (структура
2.2. Функциональность)
2.3. Сложность
2.4. Тесты
2.5. Наименования
2.6. Комментарии
2.7. Стиль
2.8. Документация
2.9. Каждая строчка
2.10. Контекст
2.11. Позитивные моменты
Итоги
Самое важное при проведении ревью:
Код хорошо спроектирован,
Функционал работает правильно,
Изменения в пользовательском интерфейсе требуют особого внимания: помимо чистоты кода необходимо убедиться в том, что для пользователя изменения выглядят как задумано,
Параллельно выполняемый код исполняется безопасно,
Код не переусложнен,
Нет надуманного и ненужного на данный момент функционала,
На код написаны тесты
Тесты хорошо спроектированы,
Использованы корректные имена для файлов, классов, методов, переменных и тд
Оставлены понятные и нужные комментарии, по большей части поясняющие причины решений, а не суть (суть должна быть понятна из самого кода),
Код задокументирован (g3doc),
Код соответствует нашим стайл-гайдам.