Ненаписанные правила переписывания кода другого члена команды [закрыто]

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

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

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

Вход и переписывание без предварительного общения - рецепт злой воли.

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

1. Вы абсолютно уверены, что говорите о переписывании, а не о рефакторинге? По определению, изменения стиля или структуры кода, которые приводят к улучшенной (или просто другой) реализации без изменений внешнего поведения, являются рефакторингом, а не переписыванием. Разбиение монолитной подпрограммы из 500 строк на набор из 50 подпрограмм может потребовать написания довольно большого количества нового кода, но это не переписывание. Термин « переписать» подразумевает выбрасывание всего продукта или функции и начало с нуля; это не то, что нужно воспринимать легкомысленно.

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

3. Знает ли менеджер / технический руководитель о проблеме, и если нет, то почему? Независимо от того, какой у вас процесс, за качество кода обычно отвечает менеджер по разработке. Он или она - первый человек, о котором вы должны спросить - очевидно, не в контексте «такого-то написанного дерьмового кода», а просто «Я думаю, что вижу здесь серьезную проблему, мы можем поговорить о переписывании?» Если это не гарантирует такого рода обсуждения, то, может быть, это и не требует переписывания?

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

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

5. Вопрос гласит, в первом абзаце any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. Переписать не будут делать эти вещи? Или это сделает что-то дополнительное - и если да, то что? По сути, то , что есть ваши причины для желающих сделать рерайт, и как вы уверены, что они будут приносить пользу продукта или команды? Вам не нужно отвечать за меня, но вам лучше иметь несколько объективных замечаний, если и когда вы решите обсудить это с командой.

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

Почему вы редактируете код?

Есть ли ошибки или это более фундаментальный недостаток дизайна?

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

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

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

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

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

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

• Это занимает значительное количество времени. Если кто-то еще работает над связанным изменением, вы не хотите тратить свое время.
• У других людей другая точка зрения. Даже если вы программируете 20 лет, кто-то другой может знать о взаимодействии с кодом, к которому вы редко обращаетесь.
• Другие разработчики являются «заказчиками» исходного кода. Исходный код написан для чтения другими разработчиками. У них могут быть требования к архитектуре, входные данные о стиле или запросы функций, которые они хотели в этом коде, но не успели. Вы не хотите завершать рефакторинг только для того, чтобы узнать, нуждается ли другой разработчик в рефакторинге другим способом.

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

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

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

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

Какова область этого?

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

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

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

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

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

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

Дополнительные комментарии делаются в заголовке пакета (как правило, обычно), указывая, какие функции / procs / SQL / etc. были изменены, с датой. Это облегчает поиск разделов, которые были изменены, и эти разделы имеют полную документацию.

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

Из моих наблюдений общая практика такова: никогда не удаляйте код. Просто закомментируйте это и сохраните.

Моя практика - комментировать его при замене. (В основном для справки.) Затем удалите его при окончательной фиксации рабочего изменения. (Это требует контроля версий и понимания того, как отменить изменения.)

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

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

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

Такие теги, как FixMe, ToDo, Bug и Hack, могут использоваться для обозначения кода, который можно изменить позже. (Допустимо помечать ограничения как ошибки и не исправлять их, если они не будут срабатывать при требуемых условиях.) Возможно, это будет ошибкой, если программа домашнего учета переполнена на 20 миллионов долларов, но я бы не стал тратить много времени на исправление Это.

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

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

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

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

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

• Новое требование к функции меняет ситуацию так, что целевое мини-переписывание подходит.

В этих случаях я бы не стал разговаривать.

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

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

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

В среде Team dev вы не должны (и, возможно, не сможете) общаться с оригинальным кодером, все должно быть ясно из кода.

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

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

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

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

Часто код пишется определенным образом по причине. Сообщение изменения автору всегда работает к лучшему.