Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Варианты документирования доработок

Варианты документирования доработок
Я
   Скользящий
 
01.09.20 - 10:42
Поделитесь пожалуйста опытом документирования доработок. Нужно, чтобы все было максимально просто, без излишеств, но в то же время, чтобы не в ворде все вести ручками. )
В первую очередь для небольшого проекта. Предположим, пара баз, где работают несколько программистов и вносят доработки посредством расширения.

Гугл, яндекс,  плюс общение показали примерно следующие подходы.

Кто-то говорит, что просто нужна система учета задач плюс в коде в обязательном порядке комментарии с номером задачи, по которой это сделано. Система учета любая, как оформлять тоже дело вкуса, главное чтобы было и то и то.

Кто-то просто в самой конфигурации в общем модуле или макете пишет, все что в конфе делали.

Кто-то использует СППР.  

Кто-то использует Git репозитарии для 1С кода, или 1C:EDT (Enterprise Development Tools).

Кто-то использует решения, делающие выгрузку из хранилища с историей всех изменений объектов /ConfigurationRepositoryReport

Кто-то просто пишет максимально читаемый код, плюс плюс описание экспортных методов которое потом можно превратить в документацию к ним плюс автотесты, которые генерируют документацию (vanessa-behavior, например).

Как вариант, еще просто демобаза (минимум данных но достаточных на примеры всех функциональностей) и документация в вики к ней (на движке MediaWiki, например).

Также вижу что используют сторонние разработки управления проектами, GitLab, Asana, Jira, Redmine.
Также фиксируют доработки в Evernote, Google Docs и т.д. и т.п.

Поделитесь, пожалуйста, своим опытом документирования доработок.
   ДенисЧ
 
1 - 01.09.20 - 10:48
Таск-трекер с обсуждением и фиксацией решения.
В коде - номер задания и краткое (на 1-2 строки) описание.
   acht
 
2 - 01.09.20 - 10:58
(1) > В коде - номер задания и краткое (на 1-2 строки) описание.

Только лучше номер задачи не в коде, а комментарии при помещении в хранилище. Потом по истории хранилища сразу виден весь набор объектов, измененных в рамках задачи, а конкретные изменения ловятся сравнением версий.
   Конструктор1С
 
3 - 01.09.20 - 11:07
(2) всё-таки лучше в коде. Иначе замучаешься листать версии чтобы выяснить, кто же последний изменял одну из ста процедур "популярного" общего модуля. GIT вроде бы умеет отловить историю изменения конкретного куска кода, а 1сное хранилище не умеет
   acht
 
4 - 01.09.20 - 11:43
(3) Умеет, только показывает очень неудобно - как набор коммитов, а для получения диффа надо еще кнопки жать...

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

В общем получается два подхода к анализу. Или от кода вверх к объектам, наборам изменений, релизам - тогда задачи в коде нужны. Или от релизов, наборов изменений, вниз к коду реализации - тогда не нужны =)
   trad
 
5 - 01.09.20 - 11:57
(4) к сказанному добавлю, что изменения не модулей получится комментить только в коммите
   Ботаник Гарден Меран
 
6 - 01.09.20 - 12:00
В конфигураторе не хватает режима просмотра модуля без комментариев.
Много доработок одной-двух типовых строк плохо смотрится.
   acht
 
7 - 01.09.20 - 12:03
(6) Прикрути свою любимую диффалку, указав ее в настройках, и будет тебе и без комментариев, и без пробельных символов, и без учета регистра - все что пожелаешь!
   fisher
 
8 - 01.09.20 - 12:14
Собственного опыта нет, но из стороннего опыта сложилось следующее впечатление про оптимальный вариант: интеграция таск-трекера с гитом (когда коммит имеет ссылку на номер задачи и наоборот, тогда при нормальной интеграции можно сразу из таск-трекера перейти к просмотру коммита).
Разработку при этом можно вести в хранилище, а в гит просто зеркалировать известной утилитой. Код при этом чистый - без комментариев "кто/когда/почему".
   ДенисЧ
 
9 - 01.09.20 - 12:17
(2) И в коде, и в хранилище.
   fisher
 
10 - 01.09.20 - 12:21
(8) + А у меня просто хранилище и комментарии коммитов, номер задачи из таск-трекера пишется в поле "метка". Т.е. когда прижмет - все "ходы" можно найти. Но так как команда маленькая и прижимает редко, то рука пока не поднимается на построение более человечной системы. Если бы приходилось чаще - пришлось бы задуматься и о гите и о более продвинутом таск-трекере.
   fisher
 
11 - 01.09.20 - 12:27
Только это все касается протоколирования доработок, а не написания документации к ним. Это же абсолютно разные вещи, ИМХО.
Ведение пользовательской документации - это совершенно отдельная тема.
   fisher
 
12 - 01.09.20 - 12:28
Документирование API (в т.ч. автодокументирование) - это тоже немного сбоку.
   Bigbro
 
13 - 01.09.20 - 13:11
в такс трекере - номер задачи, заказчик, постановка решение.
в коде - номер задачи, заказчик, дата, пояснения к изменениям.
   acht
 
14 - 01.09.20 - 13:13
(13) А размер ноги заказчика в коде почему не указваете?
   Bigbro
 
15 - 02.09.20 - 04:31
(14) подрастешь, расскажу почему. если сам не поймешь к тому времени.
   fisher
 
16 - 02.09.20 - 09:15
(14) Для этого нужно разрешение на хранение и обработку персональных данных.

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.