Исправление ошибки при работе с другой частью базы кода

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

Что вы делаете в этой ситуации?

1. Исправьте ошибку и передайте ее вместе с текущей работой
2. Сохраните текущую работу в другом месте, исправьте ошибку в отдельном коммите, затем продолжите работу [1]
3. Продолжайте то, что вы должны сделать, передайте код (даже если он ломает сборку не проходит некоторые тесты), затем исправьте ошибку (и сборка сделать тесты) в отдельном коммите

[1] На практике это будет означать: клонировать исходный репозиторий в другом месте, исправить ошибку, зафиксировать / протолкнуть изменения, извлечь коммит в репозиторий, над которым вы работаете, объединить изменения и продолжить работу.

Изменить: я изменил номер три, чтобы отразить то, что я действительно имел в виду.

Я сделал 1 и 2, и, в конце концов, я думаю, что предпочитаю # 2. Это позволяет улучшить видимость исправления ошибки, что может быть важно для QA / примечаний к выпуску / других разработчиков.

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

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

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

Я делаю № 2. Использование таких инструментов, как git, упрощает разделение на несколько коммитов. Если вы не можете убедить свою команду перейти на более современные инструменты, git-svn даст вам приличную часть того, что вы использовали бы для решения этой проблемы. Этот пост в блоге дает хороший обзор рабочего процесса, который вы пытаетесь решить: The Thing About Git

Я выбираю неписаный вариант (4): разделите ваш проект на узкоспециализированные сборки / библиотеки, чтобы несвязанные ошибки всегда находились в другом месте в дереве управления версиями.

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

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

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

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

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

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

Краткий ответ: № 2. Вы действительно хотите, чтобы это исправление (с его примечанием в вашем трекере!) Было помечено в вашей истории версий как отдельная сущность.

Более длинный ответ:

• Наткнуться на ошибку
• Написать тест или более, демонстрирующие ошибку
• Сделайте тест пройден
• Зафиксируйте только это изменение и его тесты ( git add --interactiveили, darcs record -iкак это делает ваша VCS) (*)
• Вернись к тому, что я делал.

(*) В CVS (нет, правда) у меня иногда проверяется чистое дерево, а также копия, над которой я работаю. Затем я использую merge - в моем случае winmerge - чтобы просто вставить исправление в чистое дерево, чтобы я мог зафиксировать его отдельно. (Другой вариант - переименовать измененные файлы cvs updateи объединить их. Когда вы зафиксировали изменение, удалите файл и переименуйте перемещенные файлы обратно в их исходные имена.)

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

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

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

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

Я обычно делаю № 2. Сохранение моей текущей работы в другом месте: обычно это работает нормально, создав патч. Кроме того, некоторые IDE (IntelliJ) позволяют вносить изменения в полки, что именно так: сохранить текущую работу в другом месте.

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

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

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

Мы делаем № 1. # 2 звучит хорошо, но я не могу сказать, что у нас были проблемы с # 1, которые # 2 исправит.

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