Регистрация «закомментированного» кода [закрыто]


94

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

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

Это вызвало некоторые трения, так как другой разработчик считает, что этот путь слишком ограничен. Этот разработчик хотел бы иметь возможность прокомментировать некоторый код, над которым он работает, но который не завершен. Тогда этот код никогда бы не был зарегистрирован раньше, а затем нигде не сохранен. Мы собираемся использовать TFS, поэтому я предположил, что отложить изменения будет наиболее правильным решением. Однако это не было принято, потому что он хотел бы иметь возможность отмечать частичные изменения, которые могут быть или не могут быть развернуты.

Мы хотим, в конечном итоге, достичь момента, когда мы в полной мере воспользуемся преимуществами непрерывной интеграции и автоматически выполним развертывание на веб-сервере разработки. В настоящее время не существует разрабатываемой версии веб-серверов или серверов баз данных, но вскоре все это будет изменено.

В любом случае, что ты думаешь? Считаете ли вы, что "закомментированный" код полезно иметь в репозитории?

Мне очень интересно услышать от других по этой теме.

Изменить: для ясности мы не используем частные ветки. Если бы мы это сделали, я бы сказал, делайте все, что вы хотите, со своей частной веткой, но никогда не объединяйте закомментированный код со стволом или какими-либо общими ветвями.

Изменить: нет веской причины, по которой мы не используем частные или индивидуальные ветки. Я не согласен с этой концепцией. Просто мы еще не настроили это таким образом. Возможно, это золотая середина. Пока мы используем стеллажи TFS.


3
Убедитесь, что вы полностью обучили своих разработчиков правильному использованию TFS. У моей рабочей группы были серьезные проблемы с TFS, что привело к потере кода для меня. Возможно, произошла ошибка «ID10T», но я все еще не доверяю TFS.
Джеймс Шек,

@John: Есть ли причины, по которым вы не разрешаете частные отделения? Это решило бы проблему, он мог бы с радостью отправить и сохранить что-нибудь там, и вас вообще не беспокоило бы в основной ветке.
Фрэнк

@null - как упоминалось в редакции, у меня нет проблем с ними, просто мы еще не сделали этого. Однако проблема в этом сценарии заключается в том, что мы не будем выпускать релиз из частной ветки, и он хочет, чтобы было развернуто частичное решение.
Джон


Ответы:


123

Могут быть и другие с другим опытом, но для меня проверка незавершенного кода - ужасная идея, и точка.

Вот принципы, которым я научился и которым стараюсь следовать:

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

Это означает:

  • Закомментированный код никогда не следует возвращать, так как он не работает.
  • Комментирование не является допустимой стратегией архивирования, поэтому, будь то код, который еще не завершен, или код, который удаляется, комментирование и проверка не имеют никакого смысла.

Итак, НЕТ! Если код не готов для перехода к следующему этапу (в зависимости от того, что вам подходит: IntTest / QA / UAT / PreProd / Prod), его не следует передавать в магистраль или ветвь с несколькими разработчиками. Период.

Изменить: после прочтения других ответов и комментариев я добавлю, что не думаю, что обязательно стоит запретить закомментированный код (в любом случае не знаю, как вы это сделаете). Я скажу, что вы должны убедить всех в вашей команде принять философию, которую я описал выше. Команда, над которой я работаю, безоговорочно принимает это. В результате система управления версиями - это беспрепятственный член команды, который помогает нам выполнять нашу работу.

Люди, которые не принимают эту философию, обычно вызывают разбитые окна и часто разочаровываются в системе контроля версий. В лучшем случае они видят в этом неизбежное зло, а в худшем - то, чего следует избегать; что приводит к нечастым проверкам, а это означает, что наборы изменений огромны и их трудно объединить, что усугубляет разочарование, делает проверки чем-то, чего следует избегать еще больше, и т. д. Это в конечном итоге вопрос отношения, а не процесс. Против этого легко воздвигнуть ментальные преграды; легко найти причины, по которым это не сработает, так же как легко найти причины не сидеть на диете, если вы действительно этого не хотите. Но когда люди действительно хотят это делать и стремятся изменить свои привычки, результаты впечатляют. Вы должны продать его эффективно.


2
Я согласен с вашим пояснением - никогда не регистрируйте код полуфинала в «стволе» или в другом подобном эквиваленте. Всегда должна быть ветка / магистраль, которая является версией «этот код всегда работает». Идите вперед и зарегистрируйтесь наполовину в частной ветке разработчиков, в локальном зеркале, на полке и т. Д.
Джеймс Шек

2
Комментарии @Eddie по определению не обязаны синхронизироваться с остальной частью кодовой базы. Они могут стать устаревшими и вводить в заблуждение и способствовать разбитию окон системы. Все это - риск для времени разработчика. У нас их уже достаточно. Этого достаточно легко избежать
Rex M

2
@Rex M: ИМО, комментарии являются важной частью кода. В любом поддерживаемом мной коде комментарии гарантированно синхронизируются с остальной частью кодовой базы. Код, в котором комментарии не синхронизированы, не работает. Вы просто можете этого еще не знать.
Эдди,

2
@John: Похоже, этот дефект был вызван недосмотром разработчика. Как запрет на регистрацию закомментированного кода помешал бы этому разработчику осуществить такую ​​оплошность? Запрет дает вам ДВЕ наказания вместо одной. Это не мешает надзору.
Эдди

9
Я почти проголосовал за это, но очень редко я получаю то, над чем я работаю, в состоянии проверки всего за один день работы. Я предполагаю, что возможно, что вы гораздо лучший разработчик, чем я, но я предпочитаю верить, что я работаю над более сложными вещами, чем вы. :-)
TED

44

«Никогда» редко бывает хорошим словом для использования в рекомендациях.

У вашего коллеги есть отличный пример того, когда может быть уместно возвращать закомментированный код: когда он неполный и может сломать приложение, если он будет возвращен в активном состоянии.

По большей части комментирование мертвого кода не требуется в хорошо управляемой системе с контролем изменений. Но не весь закомментированный код «мертв».


9
Я не согласен. Если код неполный, почему он в первую очередь проверяется. Современные системы управления версиями имеют механизмы для загрузки незавершенных функций без фиксации в магистрали.
Rex M

9
+1, иногда это самый подходящий поступок. Не всегда, но и не никогда . Сказать « никогда» не так просто, но это слишком ограничительно.
Эдди

@Rex Я не думаю, что в исходном посте достаточно информации, чтобы определить разницу между незавершенной загрузкой и фиксацией в основной строке.
Джейсон Коко,

Рекс - что это? Никогда не засчитывайтесь не полностью? Или никогда не заселение в багажник неполным? Это не одно и то же.
Джеймс Шек,

@Jason «разработчик хотел бы иметь возможность прокомментировать код, над которым он работает, но он не завершен». Похоже, он хочет проверить для меня функцию незавершенной регистрации.
Rex M

24

Закомментированный код никогда не следует возвращать для сохранения истории. Это точка управления версиями.

Здесь много говорят об идеалах. Может быть, в отличие от всех, мне приходится работать над несколькими проектами с множественными перерывами, а «реальный мир» иногда прерывает мой рабочий день.

Иногда на самом деле мне приходится проверять частично законченный код. Это либо риск потери кода, либо неполный код. Я не всегда могу позволить себе «закончить» задачу, какой бы маленькой она ни была. Но я не буду отключать свой ноутбук от сети, не проверив весь код.

При необходимости создам собственную рабочую ветку для фиксации частичных изменений.


4
@James, ваш последний бит - это ключ - если вы не можете проверить рабочий код, найдите другое место, чтобы его поместить. Будь то ветка, полка или еще что-нибудь.
Rex M

Если бы я мог проголосовать за это более одного раза, я бы сделал это. Мои настроения именно!
Ola Eldøy

23

Один случай, когда я оставляю закомментированный код:

// This approach doesn't work
// Blah, blah, blah

когда это очевидный подход к проблеме, но он содержит некоторый тонкий недостаток. Конечно, в репозитории это будет, но репозиторий не будет предупреждать никого в будущем, чтобы он не пошел по этому пути.


6
Если бы он был ограничен одной строкой, это могло быть исключением. Я бы предпочел увидеть краткий блок-комментарий (несколько строк вверху), в котором упоминаются причины выбора одного подхода по сравнению с другим. В таком случае я бы не стал считать это «закомментированным», но задокументированным.
Джон

3
+1. Я видел пример, когда что-то было сломано, потому что код установил soTIMEOUT. Исправление заключалось в его удалении. Если вы просто удалите строку кода, кто-то может позже повторно ввести ее, думая, что исправляет ошибку, сделав это, но на самом деле они повторно вводят ошибку.
Эдди

1
Да, это моя идея - убедиться, что ошибка не появится снова в будущем. Оставив реальный код, они увидят, что это не просто ошибка в написании оригинала.
Лорен Пехтель

В данном случае я не считаю это «закомментированным кодом», это документация.
hlovdal

1
это единственный пример, где я позволил закомментированному коду жить. в данном случае это не чья-то недоработанная идея, которая витает вокруг и сбивает с толку программистов по обслуживанию, это [надеюсь] законный, функциональный пример кода, который полностью сломает приложение, но в остальном это очевидный подход.
Worc

19

Я бы, конечно, настоятельно не рекомендовал проверять закомментированный код. Однако я бы не стал категорически запрещать это. Иногда (если редко) уместно проверять закомментированный код в системе контроля версий. Сказать «никогда так не делай» - слишком ограничительно.

Я думаю, что все мы согласны с этим:

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

Некоторые из них говорят, что есть другие категории, такие как временно удаленный код или инкрементное, но неполное улучшение, которое включает небольшой объем закомментированного кода в качестве документации о том, что будет дальше, или очень короткое (в идеале 1 строка) фрагмент прокомментированного код показывает то, что никогда не должно следует добавлять повторно. Закомментированный код ВСЕГДА должен сопровождаться комментарием, в котором говорится, почему он закомментирован (а не просто удален), и указывается ожидаемое время жизни закомментированного кода. Например, «Следующий код приносит больше вреда, чем пользы, поэтому закомментирован, но его необходимо заменить перед выпуском XXX».

Комментарий, подобный приведенному выше, уместен, если вы доставляете исправление, чтобы остановить кровотечение у клиента, и у вас нет немедленной возможности найти окончательное исправление. После доставки исправления закомментированный код является напоминанием о том, что у вас все еще есть что-то, что нужно исправить.

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

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

Рекс М сказал: 1) Проверяйте только полную функциональность, 2) [Если] задача слишком велика - разбейте ее на более мелкие выполняемые задачи.

В ответ: Да, это идеальный вариант. Иногда ни один из вариантов невозможен, когда вы работаете над производственным кодом и имеете немедленную критическую проблему, которую нужно исправить. Иногда, чтобы выполнить задачу, вам нужно на некоторое время поместить версию кода в поле. Это особенно верно для изменений кода сбора данных, когда вы пытаетесь найти первопричину проблемы.

Для конкретного экземпляра, о котором спрашивают в более общем вопросе ... пока разработчик проверяет закомментированный код в частной ветке, которую никто не увидит, кроме этого разработчика (и, возможно, кого-то, с кем разработчик сотрудничает), от этого мало вреда. Но этот разработчик (почти) никогда не должен доставлять такой код в транк или аналог. Багажник всегда должен строиться и всегда должен функционировать. Доставка незавершенного кода в транк - почти всегда очень плохая идея. Если вы позволяете разработчику проверять незаконченный или временный код в частной ветке, вы должны положиться на разработчика, чтобы он не забыл очистить код перед доставкой в ​​магистраль.

Чтобы прояснить в ответ на комментарии к другим ответам, если код закомментирован и зарегистрирован, я ожидаю, что код будет работать, если раскомментированные пропадут со временем, в течение которого код был закомментирован. Очевидно, что инструменты рефакторинга не всегда включают комментарии в свой рефакторинг. Почти всегда, если я помещаю закомментированный код в производство, он служит уточненным комментарием, чем-то более конкретным, чем проза, о том, что там что-то нужно сделать. Это не то, что должно иметь долгую жизнь.

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


4
@camh: система отслеживания проблем не будет предоставлять тот же контекст, что и напоминание в самом коде, в контексте, с кратким комментарием о проблеме. Отслеживание проблем не так глубоко интегрировано в IDE. Ваше предложение отбрасывает много информации ради догмы.
Эдди

1
@John: Нет, я работаю с миллионами SLOC и десятками тысяч исходных файлов. Если вы думаете, что комментарий, о котором я говорю, беспорядок, то это означает, что вы меня не понимаете и / или что я недостаточно ясно выражаюсь. Я говорю о крайнем случае, а не о частом явлении, как я много раз говорил в обсуждениях в ответ на ваш вопрос. И послушайте, разве ваш магазин не тот, в котором нет частных филиалов? Не надейся надо мной.
Эдди

1
@John: В качестве примера см. Мой последний комментарий к stackoverflow.com/questions/758279/… - и дайте мне лучший способ предотвратить повторное введение этой ошибки. Или @camh, расскажите мне, как система отслеживания ошибок может предотвратить повторное появление этой ошибки. Когда вы работаете с критически важным оборудованием 5-9, подобные вещи имеют значение.
Эдди

1
@John: Как мне не обижаться на «У меня сложилось четкое впечатление, что ты работаешь в основном над мелкими вещами»? иначе, я должен быть неопытным только потому, что мы не согласны в чем-то очень маленьком? Вы, конечно, всегда имеете право на свое мнение, и это нормально, что мы не согласны. Но заметьте, когда я не согласен с вами, я не критикую ваш уровень опыта только потому, что мы видим вещи по-другому. Фактически, я согласен с вами на 98% или 99%. Я просто не люблю абсолютизм.
Эдди

1
@Eddie - Текущее воплощение вашего ответа гораздо ближе к тому, что я считаю передовой практикой. Однако, как всегда, когда дело доходит до лучших практик, вы никогда не получите 100% согласия с тем, что что-либо является законным передовым опытом. Я не ожидал этого, когда разместил свой вопрос :)
Джон,

15

Я думаю, что никогда не бывает слишком сильным условием.

Я обычно комментирую, проверяю, запускаю тесты, думаю, а затем удаляю комментарии после следующего выпуска.


Если вы не запускали тесты, то пока не стоит проверять. Не проверяйте код, который не пройдёт тесты или иным образом нарушит сборку.
Джон Сондерс,

@John Saunders: Это зависит от того, что выполняет проверка в вашей системе управления версиями. Если вы используете что-то вроде ClearCase с UCM, то проверки всегда выполняются в частной ветке, и требуется отдельный шаг для перехода к эквиваленту «TRUNK».
Эдди

Точно, но, к сожалению, огромное количество разработчиков думают, что «фиксация» означает «внесение изменений в транк», я полагаю, благодаря CVS и SVN. К счастью, новые системы, такие как GIT,
обучают

@john, я имел в виду: закомментировать, проверить, проверить ..! Ты прав.
Fortyrunner

14

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

Я придерживаюсь убеждения, что код принадлежит компании или команде, и что вы обязаны упростить задачу для своих коллег. Проверка закомментированного кода без добавления комментария о том, почему он сохраняется, равносильна заявлению:

Я не возражаю, если вы в конечном итоге запутаетесь, почему эта фигня здесь. Мои потребности более важны, чем ваши, поэтому я сделал это. Я не чувствую необходимости оправдывать вам или кому-либо еще, почему я это сделал.

Для меня закомментированный код обычно воспринимается как знак неуважения со стороны менее вдумчивого сотрудника.


3
Последняя строка вашего сообщения неактивна. Хотел бы я проголосовать за вас больше одного раза
MikeJ

2
Иногда то, что вам удобно, - не единственное соображение. Конечно, одна из важных обязанностей разработчика - облегчить жизнь будущим разработчикам, но это должно вступать в противоречие с другими интересами. Глядя на что-то немного неудобное и сразу же предполагая, что это было добавлено только для того, чтобы разозлить вас, демонстрирует ваше очень высокомерное отношение с вашей стороны.
Эндрю Шеланский

7

Когда вам нужно добавить небольшую функцию или исправить ошибку, например СЕЙЧАС, в течение следующих 3 минут и вам нужно исправить файл, в котором есть наполовину разработанный код, я бы сказал, что это нормально, практические потребности преобладают над прагматическими идеалами на поле боя.


Как в этот сценарий вписывается управление изменениями? Я согласен с тем, что есть магазины, в которых всегда происходит большой пожар, но это не значит, что все должно происходить таким образом. Я также предполагаю, что это могло быть причиной проблемы. Недостаточный контроль над кодовой базой.
Джон

1
Я полностью согласен, что такого рода вещи СЛЕДУЕТ избегать, но по какой-то причине руководство, похоже, не соглашается :)
Роберт Гулд

6

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

Следующий разработчик, который увидит этот закомментированный код, не поймет, что это работа. Он свободен изменить это? Это мертвый код? Он не знает.

Если изменение вашего коллеги не находится в состоянии, в котором его можно зарегистрировать, ему необходимо завершить его и / или научиться делать небольшие, постепенные изменения.

«Регистрация частичных изменений, которые могут или не могут быть развернуты» - по-видимому, это также означает, что можно или нельзя тестировать? Это скользкий путь к очень сомнительной базе кода.


6

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

Я бы охарактеризовал последних как «тех, кто любит использовать свою систему контроля версий в качестве резервной ленты для бедняков», но это подсказывает мне, в каком лагере я нахожусь. :-)

Я предполагаю, что вы из лагеря "хорошего кода", а он из лагеря "рабочего кода".

[РЕДАКТИРОВАТЬ]

Судя по комментариям, да, я правильно понял.

Как я уже сказал, я с вами, но насколько я могу судить, это мнение меньшинства, как здесь, о stackoverflow, так и там, где я работаю. Таким образом, я не думаю, что вы действительно можете закрепить это в своих стандартах разработки как единственный способ работы. Нет, если вы все равно хотите, чтобы стандарты следовали. Одна вещь , хороший руководитель знает , что это никогда не приказывать им знать не последует.

Кстати: Хорошие редакторы помогут сохранить старые версии. Например, в Emacs я установил сохраненные старые версии и сохраненные старые версии равными 10, что позволяет сохранять около 10 последних сохранений моих файлов. Вы можете посмотреть на это как на способ подкрепить свой аргумент против толпы, использующей контроль версий как резервную копию. Однако вы никогда не выиграете спор.


1
Об этом здесь тоже говорилось. Однако я считаю, что репозиторий не является средством предотвращения потери данных. Это система контроля версий. Поскольку мы используем TFS, он может использовать стеллажи для резервного копирования неполного кода. Он также мог использовать инструмент резервного копирования или поместить код в резервную копию.
Джон

1
Резервные копии IDE не защищают от потери данных. Корпоративные системы резервного копирования не всегда соответствуют требованиям потери данных кода. Контроль версий - это система, которая может легко удовлетворить обе потребности. Относительно легко разработать политику, которая отвечает потребностям обоих лагерей, а не исключает то или иное.
Джеймс Шек

Каким образом мои резервные копии Emacs не защищают меня, Джеймс? BTW: Я полностью согласен с вашим последним предложением.
TED

Резервные копии Emacs предназначены для возврата к предыдущему состоянию конкретного файла. Направление файлов резервных копий на файловый сервер по умолчанию отключено и требует, чтобы я попросил системного администратора освободить место на файловом сервере. Если бы у меня была FS, я бы просто поставил весь проект в FS и покончил с этим. Кроме того, для меня важны «данные» полного «состояния» рабочего пространства / проекта. Emacs (и большинство IDE) не имеют механизма для его сохранения.
Джеймс Шек

@ ted.dennison: Глядя на оценки двух первых ответов, я бы сказал, что ваше мнение является мнением большинства о SO.
Эдди

4

По моему опыту, переключатели разработчика - это закомментированный код.

Иногда новые серверные компоненты создаются параллельно, а активирующие переключатели закомментированы в системе управления версиями.

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


4

Еще одна причина для отмеченного закомментированного кода:

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


5
+1: оставление закомментированного кода на месте - если и только если он краткий и ненавязчивый - не дает кому-то забыть «не делайте этого» и повторно ввести ошибку. ОСОБЕННО, когда исправление включает удаление строк кода, а не переписывание строк кода.
Эдди

Определенно об удалении строк кода. Неплохо подмечено.
thursdaysgeek,

1
Я не согласен. Оставить комментарий о том, чего следует избегать, необходимо, но не в виде кода, а не описывая это словами.
thSoft

3

Возможно, реальный вопрос здесь в том, следует ли разрешить разработчикам проверять неполный код?

Эта практика может показаться противоречащей заявленной вами цели реализации непрерывной интеграции.


3

Это зависит. Если это оставлено для иллюстрации, возможно. Возможно, это может пригодиться при рефакторинге. Иначе и вообще нет. Кроме того, комментирование незаконченного кода неизбежно приведет к сбоям и отнимет много времени. Лучше он разбивает код на более мелкие части и проверяет их, когда они работают.


3

Мое мнение: если разработчики работают над собственными ветками или в своей собственной песочнице, они должны иметь возможность проверять все, что захотят. Когда они проверяют код в общей ветке (функциональная ветка или ветка команды, или, конечно, MAIN / trunk), код должен быть как можно более чистым (без закомментированного кода, без FIXME и т. Д.).


3
В мире нет ни одного значимого проекта без TODO, FIXME или HACK в основном стволе. Мечтать.
Роберт Гулд

1
@Robert только потому, что это случается часто, не означает, что мы не должны пытаться этого избежать.
Rex M

2
Вау, это действительно мечта. Производственный код без FIXME? Он должен быть полностью функциональным, без ошибок и необъяснимого поведения. Ой, подождите, такого кода не существует! :)
Эдди

1
Да, явно мечта - я просто пытался сказать, что планка для фиксации в общей ветке намного выше, чем для фиксации в вашей личной песочнице / ветке незавершенной работы.
Жан

@jean: Да, мы полностью с этим согласны.
Эдди

2

Я считаю, что «никогда» - слишком строгое правило. Я бы проголосовал за то, чтобы оставить некоторую свободу действий относительно того, проверяют ли люди закомментированный код в репозитории. Конечной целью должна быть продуктивность кодировщика, а не «чистый репозиторий».

Чтобы уравновесить эту слабость, убедитесь, что все знают, что закомментированный код имеет срок годности. Любой человек может удалить закомментированный код, если он существует в течение полной недели и никогда не был активен. (Замените «неделю» на то, что кажется вам правильным.) Таким образом, вы оставляете за собой право убирать беспорядок, когда вы его видите, без слишком прямого вмешательства в личный стиль людей.


2

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

По моему опыту, когда программист проверяет закомментированный код, это происходит потому, что он / она не уверен, какое решение является правильным, и более счастлив оставить альтернативное решение в исходном коде в надежде, что это решение примет кто-то другой.

Я считаю, что это усложняет код и затрудняет чтение.

У меня нет проблем с проверкой наполовину законченного кода (так что вы получаете преимущество контроля версий), который не вызывается живой системой. Моя проблема заключается в том, чтобы найти разделы закомментированного кода без каких-либо объяснений, потому что дилемма привела к исключению кода.


2

Я думаю, что проверка закомментированного кода в системе управления исходным кодом должна выполняться с особой осторожностью, особенно если языковые теги, используемые для комментирования кода, написаны блоками, то есть:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Скорее, чем на индивидуальной основе, например:

// My commented code start here
// My commented code line 1
// My commented code line 2

(вы поняли идею)

Причина, по которой я буду проявлять крайнюю осторожность, заключается в том, что в зависимости от технологии вы должны быть очень осторожны с используемым инструментом сравнения / слияния. С определенной системой управления исходным кодом и определенным языком инструмент сравнения / слияния можно легко спутать. Например, стандартное сравнение / слияние ClearCase, как известно, плохо подходит для слияния файлов .xml.

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

Но если код проходит сборку, он может стать активным, когда его там не должно быть, и с точки зрения CM это может быть кошмарным сценарием. QA обычно проверяет, что должно быть там, они не проверяют код, которого там не должно быть, поэтому ваш код может оказаться в производстве, прежде чем вы это узнаете, и к тому времени, когда он будет реализован, код есть, когда он не следует, затраты на обслуживание многократно увеличились (поскольку «ошибка» будет обнаружена в производстве или заказчиком, в худшем месте или в любое время).


Да, я согласен. Мы также специально запретили стиль комментирования / * * / во всех наших программах на C #.
Джон

2

Идея позволить истории системы управления версиями иллюстрировать «старый способ» выполнения чего-либо вместо того, чтобы комментировать это и проверять комментирование вместе с объяснением, является хорошей идеей в теории.

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

Даже тогда, когда мы оглядываемся более чем на 3 версии, практически никогда не бывает.

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

Частично это сочетание человеческой натуры и потребностей коллектива. Если мне нужно что-то исправить, и я смогу исправить это за несколько часов, я вряд ли потрачу час на изучение старых версий кода, которые не были «живы» в течение месяца (что, когда каждый разработчик проверяет часто означает назад много изменений), если только я случайно не знаю, что там что-то есть (например, если я помню дискуссию об изменении чего-то, связанного с тем, что я делаю сейчас).

Если код удален и возвращен, то для всех намерений и целей (за исключением ограниченной цели полного отката) он перестает существовать. Да, он нужен для резервного копирования, но без человека в роли библиотекаря кода он затеряется.

Моему дереву управления версиями в моем текущем проекте около 10 недель, в команде всего около 4 инженеров, и существует около 200 списков зафиксированных изменений. Я знаю, что моя команда не так хорошо справляется со своей задачей, как должна, - проверять, как только есть что-то твердое и готовое к работе. Из-за этого довольно сложно полагаться на чтение истории кода для каждой части кода, чтобы уловить каждое важное изменение.

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

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

Если задача займет достаточно много времени, возможно, стоит создать ветку, над которой мы двое работаем (хотя это противоречит политике моей организации - инженеры и отдельные руководители групп не имеют необходимых разрешений на сервер управления версиями). В конечном счете, это компромисс, поэтому мы стараемся не вводить слишком много правил «всегда» или «никогда».

Я бы, вероятно, отреагировал на такую ​​политику без комментариев кода, сказав, что это было немного наивно. Возможно, с благими намерениями, но в конечном итоге вряд ли достигнет своей цели.

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


Почему так мало людей согласны с этими аргументами?
pabrams

2

Я думаю, что закомментированный код считается «пустой тратой».

Я предполагаю, что вы работаете в команде. Если вы работаете самостоятельно и закомментируете код «todo» и вернетесь к нему, то это другое дело. Но в командной среде вы можете с уверенностью предположить, что после того, как закомментированный код будет проверен, он останется и, скорее всего, доставит больше боли, чем удовлетворения.

Если вы проводите экспертную оценку кода, это может ответить на ваш вопрос. Если другой разработчик просматривает ваш код и говорит: «Почему этот закомментированный код пытается сделать« бла », то ваш код не прошел проверку кода, и вам все равно не следует его проверять.

Закомментированный код просто вызовет вопросы у других разработчиков, что приведет к потере времени и энергии.

Вам нужно задать вопрос " почему » код закомментирован. Некоторые предложения:

Если вы комментируете код, потому что «не уверены в бизнес-правилах», то, вероятно, у вас проблема с «ползанием области видимости» - лучше не загрязнять кодовую базу требованиями, которые «было бы неплохо иметь, но у нас нет времени для реализации »- держите его в чистоте с помощью ясного кода и тестирования того, что на самом деле есть.

Если вы комментируете код, потому что «не уверены, что это лучший способ сделать это», то пусть ваш код будет рассмотрен коллегами! Времена меняются, вы посмотрите на код, который пишете сегодня, через 2 года, и подумаете, что он ужасен! Но вы не можете обходить стороной, комментируя фрагменты, которые, как вы «знаете», можно сделать лучше, но вы просто не можете найти способ прямо сейчас. Пусть тот, кто поддерживает кодовую базу в течение длительного времени, определит, есть ли лучший способ - просто напишите код, протестируйте и работайте и двигайтесь дальше.

Если вы комментируете код из-за того, что «что-то не работает», то ИСПОЛЬЗУЙТЕ ЭТО ! Распространенный сценарий - «сломанные тесты» или «задачи» . Если они у вас есть, вы сэкономите много времени, исправив их или просто избавившись от них. Если их можно «сломать» на какое-то время, то, скорее всего, они сломаются навсегда.

Все эти потенциальные сценарии (и те, которые я здесь не упоминал) - пустая трата времени и усилий. Закомментированный код может показаться небольшой проблемой, но может быть индикатором более серьезной проблемы в вашей команде.


1

Репозитории - это резервные копии кода. Если я работаю над кодом, но он не завершен, почему бы не прокомментировать его и не проверить в конце дня. Таким образом, если мой жесткий диск выйдет из строя в одночасье, я не потеряю работу. Я могу проверить код утром, раскомментировать его и продолжить.

Единственная причина, по которой я бы это прокомментировал, заключается в том, что я не хотел бы прерывать ночную сборку.


Я считаю, что репозиторий - это система контроля версий, а не инструмент резервного копирования.
Джон

@John: Многие разработчики увидят и то, и другое.
Эдди

@ Эдди, они будут, но это не так. Для резервного копирования есть много хороших вариантов, контроль версий на самом деле не один из них, не так ли?
Дэвид требует восстановить Монику

@ricebowl: Я не говорю, что согласен с этими разработчиками! Многие места не будут платить за резервное копирование ящиков отдельных разработчиков. Отправка незавершенной работы в частный филиал перед отъездом в длительный отпуск является достойным подспорьем для проделанной работы. Разработчики прагматичны.
Эдди

1

Очевидно, существует противоречие между 1) ранней проверкой и 2) постоянным поддержанием репозитория в рабочем состоянии. Если у вас больше, чем несколько разработчиков, последний будет иметь все больший приоритет, потому что у вас не может быть одного разработчика, который занимается всеми остальными для своего личного рабочего процесса. Тем не менее , не следует недооценивать ценность первого правила. Разработчики используют всевозможные ментальные опоры, а индивидуализированные рабочие процессы - это один из способов, с помощью которых великие разработчики выживают лишние крестики. Ваша задача как менеджера - не пытаться понять все эти нюансы - что вам не удастся, если только вы не гений, а все ваши разработчики - идиоты, - а скорее дать возможность своим разработчикам быть лучшими благодаря их собственному принятию решений.

В комментарии вы упоминаете, что не используете частные ветки. Мой вопрос к вам: почему бы и нет? Хорошо, я ничего не знаю о TFS, так что, возможно, на то есть веские причины. Однако после года использования git я должен сказать, что хороший DVCS полностью снимает это напряжение. Есть случаи, когда я считаю, что комментирование кода полезно, когда я создаю замену, но я теряю сон из-за этого, если я навязываю его другим. Возможность локального ветвления означает, что я могу сохранять значимые коммиты для своего отдельного процесса, не беспокоясь о временных беспорядках (или даже уведомляя) последующих разработчиков.


Причина, по которой мы не используем частные ветки, заключается в том, что мы совсем недавно начали использовать систему управления версиями. Я новичок в компании, и моя обязанность - помочь все это исправить. Я не не согласен с этой концепцией, но пока вместо этого мы используем полки в TFS.
Джон

1

Просто повторяя припев. Откажитесь от этого любой ценой. Это затрудняет чтение кода и заставляет людей недоумевать, что хорошего / плохого в этом коде, который даже не является частью приложения в настоящее время. Всегда можно найти изменения, сравнив ревизии. Если произошла серьезная операция и код был закомментирован массово, разработчик должен был отметить это в примечаниях к ревизии при проверке / слиянии.

неполный / экспериментальный код должен быть в ветке, которую нужно разработать до конца. голова / ствол должны быть основной линией, которая всегда компилируется и отправляется. как только экспериментальная ветка будет завершена / принята, она должна быть объединена с head / mainline. Существует даже стандарт IEEE (IEEE 1042), описывающий это, если вам нужна вспомогательная документация.


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

@Eddie - Я согласен с экспериментальным кодом, который необходимо время от времени доставлять. Но это не следует комментировать, когда, на мой взгляд, в этом больше нет необходимости.
Джон

@ Эдди, я понимаю. но ветка является полной копией головной / выпускной версии на момент создания ветки. если вы делаете мод, он должен быть готовым для сборки / доставки. если вам нравятся изменения в ветке, вы объединяете их обратно в головную часть или держите ее под рукой для отладки / профилирования, когда это необходимо.
MikeJ

@John: Абсолютно согласен. Как только экспериментальный код больше не является экспериментальным, его следует оставить на месте или полностью удалить, в зависимости от того, что подходит. @MikeJ: Хороший ответ.
Эдди

1

Я бы предпочел, чтобы возможно сломанный, доступный код, который еще не использовался, но зарегистрированный, был полностью недоступен. Поскольку все программы управления версиями позволяют создавать некую «рабочую копию» отдельно от основной системы, лучше использовать эти функции вместо них.

Новый нефункциональный код можно использовать в стволе, потому что он новый. Вероятно, это не нарушит ничего из того, что уже работает. Если он действительно нарушает рабочий код, тогда он должен просто перейти в ветку, чтобы другие разработчики могли (если им нужно) проверить эту ветвь и посмотреть, что сломано.


1

« Рубцовая ткань » - это то, что я называю закомментированным кодом. В дни, предшествовавшие широкому использованию систем контроля версий, Code Monkeys оставляли закомментированный код в файле на случай, если им потребуется восстановить функциональность.

Единственный раз, когда допустимо регистрировать «рубцовую ткань», является

  1. Если у вас есть частный филиал и
  2. У вас нет времени, чтобы код компилировался без ошибок и
  3. Вы собираетесь в длительный отпуск и
  4. Вы не доверяете своей VCS, как если бы вы использовали Visual Source Safe OR .
    [РЕДАКТИРОВАТЬ]
  5. У вас есть незаметная ошибка, которая может быть повторно введена, если неверный код не будет оставлен в качестве напоминания. (хороший момент из других ответов).

Для №4 почти нет оправдания, потому что существует множество свободно доступных и надежных систем VCS, и Git является лучшим примером .

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

Поскольку это код, рубцовая ткань может отвлекать больше, чем хорошо написанный комментарий. По самой своей природе кода вы заставляете программиста технического обслуживания тратить умственные циклы процессора на выяснение, имеет ли рубцовая ткань какое-либо отношение к его изменениям. Неважно, возраст шрама - неделя или 10 лет, оставление рубцовой ткани в коде налагает бремя на тех, кто должен расшифровать послесловия кода.

[РЕДАКТИРОВАТЬ] Я бы добавил, что необходимо различать два основных сценария:

  • частная разработка, либо кодирование личного проекта, либо регистрация в частной ветке
  • Разработка сопровождения, при которой проверяемый код предназначен для запуска в производство.

Просто скажите «НЕТ» рубцам!


-1 Закомментированный код очень полезен для понимания назначения функции. В идеальном мире все оставляют об этом отличные комментарии. Но в реальном мире я обнаружил, что закомментированный код очень полезен, и Эндрю Шелански указал на причины, по которым я предпочел бы не искать его в системе контроля версий.
Брэндон Мур

0

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

Тем не менее, я вычеркиваю старый закомментированный код из предыдущей регистрации.

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


1
Может быть, вам нужны лучшие инструменты сравнения?
jw.

Одна из причин не делать этого - чтобы вы могли тривиально увидеть, кто написал исходную строку (например, git blame)
gtd

Ой. Для меня это было бы аналогично высказыванию «Я всегда смываю воду перед тем, как пойти в туалет. Но не после».
benjismith

0

Хороший компромисс - написать небольшой инструмент, который сбрасывает ваши проверенные / измененные файлы на сетевой резервный диск. Таким образом, вы можете изменять, сколько душе угодно, и иметь резервную копию своей работы, но вам никогда не придется возвращать экспериментальный или незавершенный код.


0

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

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

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

Также было бы хорошо знать, кто прокомментировал этот код, чтобы их можно было спросить, если необходимо какое-то обоснование.

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


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

0

Если разработчик закомментировал какой-то код, потому что он еще не завершен, то правильный способ «контроля исходного кода» справиться с этим состоял бы в том, чтобы этот разработчик оставил его в отдельной собственной ветке, пока этот код не будет готов для проверки. в.

С DVCS (например, git, bazaar или mercurial) это очень просто, так как не требует изменений в центральном репозитории. В противном случае, возможно, вы могли бы поговорить о предоставлении разработчикам их собственных веток на сервере, если они работают над определенными функциями, на что у них уйдет достаточно много времени (например, дни).

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


0

Очевидно, что разработчик, который проверяет закомментированный код, должен работать в отдельной ветке, при необходимости объединяя изменения из основной ветки.

Именно система VCS должна помочь разработчику в этом рабочем процессе (git - отличная система VCS, которая отлично с ней работает).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.