Поскольку наш предыдущий топик с описанием процесса внедрения инспекций кода в нашей компании вызвал определенный интерес у хабрасообщества, мы решили написать внеочередное продолжение. Сегодня мы рассмотрим пример внедрения данной практики на конкретном проекте.
Рассмотрим внедрение инспекций кода на примере проекта и структуры проектной команды. В команду входят две группы: в одной из них два разработчика и руководитель, в другой — три разработчика и руководитель. Разработчиков будем обозначать буквой D (Developer), а руководителей групп буквой L (Lead).
Определим составы групп.
Группа 1: D_1_1, D_1_2, D_1_3, L_1.
Группа 2: D_2_1, D_2_2, L_2.
Закрепляем инспекторов за деревом проекта.
trunk/module_1 — отвечает группа 1.
trunk/module_2 — отвечает группа 2.
trunk/common — общая ответственность обеих групп, конкретных инспекторов назначает руководитель из числа членов собственной группы.
Разработчик пишет код, который затрагивает модули обеих групп
1. Разработчик D_1_2 решает какую-то задачу и в процессе решения пишет код, который затрагивает следующие пути: trunk/module_1/dev_1_1, trunk/module_2/dev_2_3.
2. D_1_2 создаёт инспекцию и добавляет следующих участников.
3. Руководитель L_2 назначает инспектором разработчика D_2_3.
4. Итоговая таблица участников инспекции выглядит так.
Разработчик пишет код в общий модуль
1. Разработчик D_1_2 решает какую-то задачу и в процессе ее решения пишет код в trunk/common.
2. D_1_2 создает инспекцию и добавляет следующих участников.
3. Руководитель L_1 назначает инспектором себя.
4. Руководитель L_2 назначает инспектором разработчика D_2_1.
5. Итоговая таблица участников инспекции выглядит так.
Конечно же, запустить процесс инспекции кода в рамках небольшой группы, насчитывающей 6—7 разработчиков, — это одно, а масштабировать процесс на большой проект, над которым работают десятки разработчиков, — гораздо более трудная задача, но все же выполнимая.
Комментариев нет:
Отправить комментарий