Какие специальные методы вы используете при изменении существующего кода?Комментирование обслуживания
Например: скажите, что вы изменяете бизнес-правило внутри метода. Вы отмечаете измененный раздел специальными комментариями?
Какие-либо стандарты кодирования/комментариев, используемые при изменении кода?
Вы имеете в виду что-то вроде:
foo(); // changed by SecretWiz, 20090131
Я не рекомендовал бы это. Он загромождает файлы кода, и система управления версиями должна обрабатывать это для вас. Он отслеживает, кто что изменил. Использовать
svn blame
Нет, это действительно плохая идея. Ваш исходный контроль хранит историю всех изменений. Если вы хотите что-то еще, сделайте запись в своем инструменте отслеживания ошибок. Там нет необходимости комментировать старые участки кода или помет его с вещью, как:
// modified by A.B. on 11/23/99 to fix issue #123456
Я видел комментарии, как это в нашем коде, и они не имеют никакого смысла лет вниз по линии. Кто, черт возьми, А.Б., и что такое проблема № 123456? Если код все еще здесь, означает ли это, что кто-то планирует скопировать эти изменения в будущем?
Эти комментарии не имеют значения и служат только для загромождения кода.
Я думаю, что проблема с номером # не так уж плоха. У нас часто возникает ситуация, когда обоснование для некоторых однострочных изменений может быть сложным, и обсуждение в трекер-проблеме слишком длинное, чтобы скопировать-вставить в код (теперь *, который * загромождал его). Поскольку отслеживание проблем - например, управление версиями - никуда не денется, я считаю, что добавить ссылку. Даже после нескольких лет вы видите полное обсуждение, которое привело к этой конкретной строке кода. – Reunanen
Я бы предложил создать метод &, который вызывает это из кода, который изменяется.
Также назовите метод, предлагающий цель/цель метода.
например. GiveRebateIfValidCoupon();
«Какие стандарты кодирования/комментариев вы используете при изменении кода?»
Да. Создайте новые подклассы. Оставьте старый код в покое, за исключением редкого случая, когда вы не проверили его правильно и на самом деле ошибались.
Изменения требований означают добавление подклассов и новых тестов для обработки новых бизнес-правил.
Интересная идея, но я не знаю, будет ли она работать во всех случаях. Иногда бизнес-правила меняются FOREVER, и нет необходимости хранить этот старый код. –
Это звучит как рецепт жесткости –
Я чувствую запах некоторых подобных C++ технологий в фоновом режиме здесь? Если вы настаивали на том, чтобы так работать на моем проекте C#/java, я бы вы выгнали из проекта. -1 от меня. – krosenvold
Единственный раз, когда я добавляю специальные комментарии, является модификация, которая должна быть временной. В этой ситуации я отмечаю это стандартным ключевым словом (например, TEMPFIX), чтобы потом найти его. Конечно, вы должны помнить о том, чтобы вернуться и удалить код или внести постоянное изменение, но в некоторых проектах, которые мы применяли, используя макрос, который позволил нам указать дату истечения срока действия, после которой код перестает компилироваться.
Кроме этого, мы полагаемся на контроль источника.
Код должен соответствовать любым стандартам кодирования, которые у вас есть, или вашей организации.
Итак, нет, не должно быть никаких специальных комментариев о том, что код был изменен - все или, по крайней мере, большинство, код будет изменен рано или поздно.
Если есть код, который вы унаследовали, который не соответствует стандартам комментариев, то обязательно добавьте комментарии, как вы код refactor. Если код действительно старый и недокументированный, естественно, это означает добавление документации.
Полезно понять код, прежде чем изменять его (в порядке).
Обычно я просто изменю код и сделаю свои комментарии в моей контрольной панели управления. В выбранном инструменте отслеживания задач вы можете ссылаться на версию, в которой была выполнена задача.
Иногда я знаю, что определенные функции будут меняться взад и вперед, перемещаться, изменять имена и т. Д. В зависимости от того, как обсуждаются требования пользователя. В этом специальном случае я буду хранить старую версию там и просто прокомментировать ее. Тогда становится тривиальным, чтобы просто расколоть его позже, вместо того, чтобы проваливаться через контроль источника, ища старую версию. Это может также спасти чью-то задницу, если они должны будут поддерживать ваш код позже, потому что, когда пользователи передумают СНОВА, требование уже будет в коде, ожидая раскола.
Я должен согласиться с множеством других людей здесь, на SO. «Если вам не нужно что-то в вашем коде, удалите его». Особенно в производственном коде, последнее, что вам нужно, - это много беспорядка. Это может быть намного проще для кого-то выяснить, как ваши изменения работают, чем читать ваши комментарии по обслуживанию и, возможно, запутаться.
Раньше я использовал старый устаревший код в своих проектах, но со временем проект, который должен был иметь всего несколько тысяч строк, оказался более 10 000 и с трудом управлялся.
Если я делаю что-то вроде исправления относительно неясной ошибки, в основном ничего, где это не совсем очевидно, почему я написал код так, как я сделал, я обычно добавляю комментарий, чтобы объяснить это, так что я (или кто-то другой, если кто-нибудь еще изменит мой код ;-), он не удалит его позже.
Одна вещь, которую я всегда стараюсь сделать, - это ввести идентификатор ошибки (или идентификатор запроса функции) в систему отслеживания ошибок в комментариях кода, которые я делаю для этого изменения. Я добавляю что-то вроде «см. Комментарии к этой ошибке/функции в bugzilla для более подробной информации». Там я могу и обычно объясню обоснование этого изменения кода. Это означает, что все изменения или, по крайней мере, все важные изменения необходимо отслеживать с помощью идентификатора функции/идентификатора ошибки. Я неоднократно создавал ошибку, чтобы подробно объяснить бизнес-причины.
+1 Ударьте меня на секунду ... –
Действительно, это тоже меня заводит. – DavGarcia
Вы удаляете такие вещи, когда работаете над файлом, который другие украшают таким образом? – innaM