Добрый день.

Очень интересно, кто и как описывает изменения конфигурации (и, если описывает, то что именно - на реальных примерах). Самому интересна тема описания изменений и с удовольствием пообщаюсь в ветке по теме.

Отчет по хранилищу

(0) Всё просто!
1. Ты - чистый кодер: для вас описание изменений ограничивается ясными комментариями и версионированием объектов.
2. Ты - единственный (или почти единственный) программист: достаточно описаний в справке. Но описание должно быть подробным!
3. Большой штат, у пользователей есть процедура "вхождения в должность": корректируем регламент работы с информационной системой и пользовательские инструкции.

(0) Это понятно. Но тогда получается код - "вещь в себе" и непонятно, зачем, собственно, были внесены изменения (отчет по хранилищу отвечает на вопрос "Что?", но не отвечает на вопрос "Зачем?").

Сам стараюсь полученные формулировки задач дробить на требования (функциональности / эргономики / ограничений целостности). Например: http://gfile.ru/a8qNg .

(3) к (1)

(2) у меня ближе к 3 ситуации.

(5) Ну вот! Уже какая-то ясность, правда?
...но есть тоооненький такой момент, связанный с изменениями, которые не видны пользователям и не влияют на предметную функциональность. Рефакторинг кода, например.

(3) я обычно на листке, что то подобное пишу, удобно

//Программист № 1, попросила Мария Петровна
...мегасуперкод
//Окончание

(8) И дату обязательно!

(3) поставь редмайн, мантис, СППР, МС ТФС свяжи их с хранилищем и получай ответ на вопрос "Зачем" и что именно изменили.

Пиши комменты понятные к коду.Причем не ленись подробно.
Иначе через пару месяцев о своем собственном коде будешь думать - "какой м.дак это написал!"

Желательно сопровождать одинаковым уникальным каментам чтобы находить по всей конфиге. Я, например, сайт свой пишу. Если увидите - сильно не плювайтесь.
Дата желательна... и номер пункта в документации... да хотя бы так уже...

(6) Да, как наглядно учитывать такую ситуацию - это вопрос.
(7) Листки теряются... Либо, когда их становится много, поиск в них нужной информации затруднителен.
(9) Дата меня всегда убивала. Зачем она? Все равно потом не используется, но ее упорно ставят (да и хранилище конфигурации метки даты автоматом ставит при помещении, что делает ее бессмысленной).
(10) Получится трудозатраты на развертывание инструментария и ведение учета в нем превысят полезный эффект от его использования. Тяжеловесно... Хочу один инструмент и чтобы удобный :-)
(11), (12) Угу

В продолжение (0). Сделал микро-конфигурацию для описания изменений.

Что она умеет видно на этом скрине карты функциональности: https://yadi.sk/d/CdejFXZXTMug7

Еще скрины ее внешнего вида:
* Карточка изменения: https://yadi.sk/d/f09f9U46TMx4t
* Отчет "Проектное решение": https://yadi.sk/d/0leZmzydTMx7H
* Учет файлов: https://yadi.sk/d/KispVuF-TMx9B

Сама микро-конфа: https://yadi.sk/d/lIrQa0RBTN47C

Просьба ознакомиться, кому интересно. Жду мнения / замечания. Особенно, насколько такой способ описания удобен / нагляден.

(8)
//Программист № 1, Мария Петровна - ипанутая дура
...мегасуперкод
//Окончание

(14) :-)

(14) Дата где?

(0) описание изменений само по себе, как дисциплина спецолимпиады, вещь бессмысленная, как онанизм.
Тебе описание это для какой цели интересно? Например, для code review достаточно отчета по версиям хранилища + небольшая дрессировка кодеров на написание понятных каментов.

(17) Не не не, это важно, когда больше одного программиста работают или работали. В том числе, для "разбора полётов".

...А так, конечно, сравнить с конфигурацией поставщика - и всё станет понятно.

(0)нет времени на такую херню

(17) + внутренняя самодисциплина что ли: уже стараешься меньше объектов трогать - бить, как тот еврей молоточком за $100: $1 - за удар, а $99 - за то, чтобы знать, куда ударить.

(17) Согласен, скоповое описание всего подряд - бред. Но если не описывать ничего, через пару-тройку месяцев на код будешь смотреть с мыслями, как в (11) написали.

Лично я пришел к тому, что надо хранить требования под которые писался код и, желательно, ключевые механизмы в нем задействованные. Это позволяет через месяц повторно не напороться на ранее пройденные грабли и помнить, в каких местах при внесении изменения проверять, чтобы изменение не развалило уже созданное.

+(21) Когда хранятся требования, словами "Позвольте, у меня все ходы записаны!" можно обоснованно отвечать на претензии вида "Вы это обещали сделать еще полгода назад!" что на самом деле такого бизнес-требования ранее не было и что оно новое. В подтверждение показывая перечень полученных требований по функциональному блоку.