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