«Кто это наваял?» — или использование задач в GitHub для ответа на вопрос кто, когда и зачем внес эту строку кода?

Это видео про сакраментальный вопрос «кто этот бред сюда добавил и зачем?» — когда смотрим на код и непонятно, откуда это и почему…

Как обычно разбираются с непонятным кодом?
Два варианта — «раскапывать» самому или смотреть комменты. Но:

• Комментируют не все. Прибежал кто-то с шаловливыми ручками, коммент не написал — и все: код есть, а кто, зачем и по чьей задаче внес его — загадка. Сиди гадай.
• Даже отличные комментарии — не спасение. Ну вот видим «по задаче 12382 от нач.транс. Иванько М.С. 29 окт. 2021…». Однако кто угодно может «улучшить» код, а комментарии не трогать, потому что «суть та же…» — и опять не с кого спросить.
• Хранить всю историю доработок в комментариях — кринж. Комментарии к комментариям к комментариям — это костыль. А когда из 1500 строк кода только 100 строк исполняемых — это а) нечитаемо, б) аналитика недостоверна, в) «кто и когда сделал, а зачем?» — недостоверно.

Проблема? — Да. Теряем время, совершаем ошибки.

Решаемая? — Да.

Есть абсолютно рабочая схема, когда:

1. Аналитики, внедренцы, пользователи и заказчики сначала формируют задания (issues) — что нужно изменить в системе, почему/зачем и кто инициатор.
2. Разработчик видит их и либо отправляет обратно на уточнение, либо ставит в очередь в работу.
3. Изменения вносятся в привязке к задачам.

И все! Можно ткнуть в строку кода — и понять, кто написал, когда и почему / под какую задачу. С ФИО и ссылкой на документы :)

Круто же : ) Ясность, порядок, прозрачность — все, как мы любим : ))

В видео ниже — все подробнее:

• Как создавать задачи на Github
• Как выполнять эти задачи с привязкой изменений к этим задачам
• Как отслеживать текущий статус выполнения этой задачи.

Мы создадим задачу, сделаем под нее ветку, выполним задачу и закроем ее. Здесь стиль разработки уже начнет отличаться от того, к которому мы привыкли, работая в конфигураторе.

Тайминг ключевых этапов видео:

1:10 — создание задачи
6:28 — создание ветки под задачу
12:20 — слияние веток при помощи GitHub Desktop

Надеемся, что было полезно, удачи Вам на проектах!

P.S.

Кстати, это настолько удобный механизм, что используется фирмой 1С как открытый багтрекер: https://github.com/1C-Company/1c-edt-issues.

Сам процесс разработки и привязку изменений к задачам Вы в нем, конечно, не увидите, а выполнена поставленная извне задача или еще «висит» — легко.

В общем готовьтесь, похоже EDT/Git скоро будут спрашивать на собесах стажеров :)