Проверка кода с комментариями

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Я бы, конечно, отговаривал, сильно, когда-либо проверял код с комментариями. Однако я бы не запретил это. Иногда (если редко) целесообразно проверять код с комментариями на исходный код. Говорить "никогда не делай этого" слишком сложно.

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

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

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

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

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

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

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

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

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

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

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

Ответ 6

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

Я стараюсь прокомментировать, проверить, запустить тесты, подумать, а затем удалить комментарии после следующей версии.

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

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

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

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

[EDIT]

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

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

Эта практика будет противоречить вашей заявленной цели внедрения непрерывной интеграции.

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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

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

Ответ 17

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

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

Ответ 18

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

/* 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

(вы получаете идею)

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

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

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

Ответ 19

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

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

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

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

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

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

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

Если вы комментируете код, потому что "что-то не работает", тогда FIX IT! Общий сценарий "сломанные тесты" или "todo's" . Если у вас есть это, вы сможете сэкономить много времени, исправив их или просто избавившись от них. Если их можно "сломать" в течение определенного периода времени, они, скорее всего, будут разбиты навсегда.

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

Ответ 20

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

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

Ответ 21

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

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

Ответ 22

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

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

Ответ 23

" Scar Tissue - это то, что я называю кодом с комментариями. За несколько дней до широкого использования систем контроля версий Code Monkeys оставил код комментария в файле, если им нужно было бы вернуть функциональность.

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

• Если у вас есть частная ветка и
• У вас нет времени для компиляции кода без ошибок и
• Вы отправляетесь в длительный отпуск и
• Вы не доверяете своей VCS, например, если используете Visual Source Safe ИЛИ.
  [EDIT]
• У вас есть тонкая ошибка, которая может быть повторно введена, если неправильный код не останется в качестве напоминания. (хорошая точка из других ответов).

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

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

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

[EDIT] Я бы добавил, что необходимо выделить два основных сценария:

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

Просто скажите "NO" шрам-ткани!

Ответ 24

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

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

Ответ 25

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 26

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

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

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

Ответ 27

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

Ответ 28

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

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

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

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

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

Ответ 29

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

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

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

Ответ 30

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

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