Альтернативы закомментированному коду в исторических целях
У кого-либо есть допустимая альтернатива для использования закомментированного кода, зарегистрировался в репозитории по причинам доступности для поиска?
Причина, которую я спрашиваю, состоит в том, потому что у меня было обсуждение с таким же разработчиком недавно при регистрации в коде, который комментируется. Моя позиция - то, что закомментированный код никогда не должен проверяться в наш VCS, так как это не технически часть кодовой базы и таким образом раздражающий хлам, который не заслуживает байтов, которые он поднимает, так сказать.
Его контрапункт был то, что часть закомментированного кода, в котором он зарегистрировался все еще, проиллюстрировала некоторую работу, которую он хотел бы зафиксировать в будущем (в этом конкретном указывать, что комментарий произошел 2 года назад, но это помимо точки). Он хотел сохранить его в кодовой базе, таким образом, он мог легко найти его, и даже при том, что это не будет в настоящее время компилировать, это все еще показало в глобальных строках корректный способ решить его.
В конце он согласился, вид, что закомментированный код не принадлежит. Но когда мы думали о возможных альтернативах его, мы подошли довольно короткие.
Единственные опции, о которых я мог думать, были:
- Вики: просто вставьте его где-нибудь на Wiki. Недостаток этого состоит в том, что это будет смешано с другим связанным с некодом содержанием Wiki, которое может мешать искать на нем.
- Индексируйте все изменения VCS: Это в основном теоретически для меня, но является там системами, которые делают кодовую базу и ее всю историю доступными для поиска?
Кто-либо знает о каких-либо альтернативах? Обе моих опции походят на большее количество работы, чем это на самом деле стоит, но это может быть скошено моим обоснованием, что закомментированный код бесполезен так или иначе. Я не хотел бы должным быть пойти "Эй, если у Вас нет времени для фиксации его теперь, не достаточно важно остаться в кодовой базе так или иначе" маршрут (но я буду, если не будет никаких жизнеспособных альтернатив).
Извините за ужасный заголовок я не мог придумать лучший
7 ответов
Ветвление может быть здесь полезно. Одна из моделей использования SCM - создать ветку для каждой функции. Это популярно, когда слияние ветвей безболезненно - легкость, которую не предоставляют все SCM ...: -)
Идея состоит в том, что каждая функция, над которой вы работаете, имеет выделенную ветку и работает полностью внутри этой ветки. Когда функция завершена, работает, протестирована, задокументирована и выиграет два олимпийских золота и т. Д., Ветвь будет объединена с основной веткой. В качестве альтернативы, ветка остается открытой на неопределенный срок, если функция никогда не завершается или не прекращается и т. Д. Но тогда код остается видимым, готовым к тому, чтобы кто-нибудь когда-нибудь его подобрал.
Это хороший способ сохранить «незавершенную работу» - поскольку код разветвлен, вы можете свободно проверить предварительный код. Его не нужно закомментировать, поскольку текущие изменения находятся только в этой изолированной ветке, и их даже не нужно компилировать, поскольку эти ветки обычно не переводятся в непрерывную интеграцию, пока они не достигнут уровня зрелости.
В отличие от закомментированного кода, эти предварительные изменения кода видимы и доступны для поиска, доступны для инструментов анализа кода, рефакторинга и т. Д.
В некоторых средах функция и ее ветвь могут также иметь связанный тикет на изменение или идентификатор отслеживания проблемы. Это гарантирует, что значительные изменения не будут потеряны, и предоставляет средства для расстановки приоритетов и организации различных функций, от исправлений для шоу-стопов до экспериментов по реализации чего-то иного, что, вероятно, никогда не увидит свет.
Что касается поиска, некоторые SCM имеют интерфейс поиска.Например, в SVN есть SVNSearch - http://sourceforge.net/projects/svn-search/ . Также существует svnquery , который может искать как в истории, так и в заголовке.
Я понимаю, что код больше не используется, но он содержит идеи, которые могут быть интересны в будущем.
Я бы сохранил его в системе управления версиями, но я бы сохранил его в отдельной папке, что-то вроде удаленный-код-для-проверки-позже . Затем я бы удалил его, пока просматривал.
В некоторых сценариях хорошей идеей является документирование решений некоторых сложных / уникальных проблем в справочных целях. Однако я не думаю, что это должно быть в коде. IMHO я думаю, что Wiki - это лучший вариант.
Если вы не использовали код в течение последних 2 лет, будете ли вы когда-нибудь использовать его, а если будете, то стоит ли использовать код двухлетней давности? Если вам когда-нибудь снова понадобится добавить эту логику в код, возможно, лучше написать его с нуля, так как, скорее всего, за это время все изменилось, вы многому научились, вам стали доступны дополнительные ресурсы и т. д.
Ваше утверждение «Даже если оно в настоящее время не компилируется, оно по-прежнему показывает в глобальных строках правильный способ решения».
<>
Ваше утверждение «мои рассуждения, которые комментируют В любом случае наш код бесполезен »
. Я не вижу вреда в том, чтобы оставлять комментарии, поскольку они часто дают будущим разработчикам представление о намерениях первоначальных разработчиков и любых текущих ограничениях в существующем коде. Хранение в другой системе увеличивает вероятность того, что они будут потеряны для будущих разработчиков. Байты дешевы, время, необходимое для воссоздания другого замысла разработчика, составляет $$$.
похоже, вашему другу стоит создать ответвление и опробовать свои "улучшения" там. Вы легко сможете провести различия между этой веткой улучшений и текущим исходным текстом, чтобы получить четкое представление об изменениях, которые он собирается внести.
некоторые из закомментированного кода, который он проверил, по-прежнему иллюстрируют некоторые работы, которые он хотел бы исправить в будущем
Затем он должен открыть низкоприоритетный тикет в вашем багтрекере, описав то, что он хотел бы исправить, и добавить закомментированный код в качестве комментария к этому тикету. Теперь он может назначить этот билет себе, и он больше никого не будет беспокоить.
Закомментированный код похож на любой другой комментарий: если он не поддерживается должным образом, он имеет тенденцию терять согласованность с кодом и, следовательно, свою полезность.
По моему опыту, самая большая причина для проверки закомментированного кода заключается в том, что разработчики настолько ненавидят печатать, что предпочитают держать неиспользуемый код под рукой на случай, если им когда-нибудь понадобится ввести аналогичный фрагмент. кода в будущем.
Ваш случай немного отличается, но я все равно говорю: «Используй или потеряй». Если закомментированное решение исправляет что-то важное, это будет хорошей мотивацией для его завершения. Легко потратить больше времени на объяснение того, почему что-то не так и «как у нас не было времени исправить это», чем на то, чтобы это сделать.
Этот последний пункт основан на утверждении, что время разработчика нелинейно, и что начало работы над тем, что вы мотивированы делать, приносит гораздо больше пользы, чем «Х часов, отведенных для проекта Y» каждый раз.
Существуют системы контроля версий, которые очень хорошо подходят для создания и объединения веток. Mercurial, git и т. Д. Будут способны на это. Даже если вы не используете одну из них в качестве основной системы контроля версий, ничто не помешает вашему коллеге создать локальный репозиторий для хранения своих экспериментов.