Недавно возникла интересная проблема, и я думал о «лучшем» способе (для данного значения «лучший») реализовать это.
По сути, это одна из заметок по отслеживанию исходного кода. Примером, отмечавшим это, было исправление проблемы в прямом эфире в SLA, и как лучше всего этого достичь. Не вдаваясь во все подробности, все сводилось к поиску функции, которая используется в ряде мест, в которых могут быть или не быть ошибки, но проблема заключалась в том, что они сообщали только в одном месте.
Исправление для соответствия SLA состояло в том, чтобы просто добавить проверку в место, где была сообщена проблема, вместо того, чтобы настраивать общий код и проверять все, что касается этой функции.
Интересная тема для восходящего потока. «Правильный» метод будет тогда возвращаться и проверять исходную функцию, проверять ее правильность везде, где она вызывается, и затем вносить изменения «правильно», если определит, что библиотечная функция неверна.
Проблема в том, что для этого требуется время, поэтому восходящий поток может просто потребовать обходного пути и т. Д. Однако, если проблема возникает снова (скажем, через шесть месяцев) в другом месте, вызывающем ту же библиотечную функцию, простого способа связать две проблемы вместе. Вы можете выполнить поиск в базе данных отслеживания ошибок, но это не гарантировано, чтобы помочь - это зависит от того, была ли добавлена заметка, в которой говорится что-то вроде «эта библиотечная функция нуждается в более тщательной проверке, но сейчас нет времени на исследование».
Таким образом, вопрос заключается в следующем: в большой команде разработчиков (более 30 человек, разделенных на группы поддержки и продолжающейся разработки), какие методы вы используете для управления (что эффективно) «заметками» в отношении источника код, если не добавить комментарий к исходному коду подозрительной функции, говорящий «это может быть немного странно»?
Проблема с фиксацией комментария заключается в процессе: изменение - это изменение, поэтому фиксация изменения с нулевым изменением (то есть, когда добавляются только комментарии) не идеальна; разработчики могут допускать ошибки, даже добавляя комментарии (нажимать шальные клавиши или что-то в этом роде), поэтому всегда (IMO) лучше фиксировать только там, где внесены реальные изменения.
Теперь вики можно использовать для отслеживания заметок для каждого файла, но у нас есть как минимум четыре ветви и несколько сотен файлов (объекты SQL, исходный код, файлы XML и т. Д.), Поэтому вики будет получить довольно быстро.
Это то, что было бы неплохо, если бы SCM мог поддерживать биты метаданных с файлами, которые являются просто примечаниями, но не добавляются в историю версий SCM, - которые могут отображаться при выполнении (скажем) svn update, или просмотр вручную.
Возможно, уже есть решения - как вы управляете этим типом обмена знаниями?