Этикет для рефакторинга исходного кода других людей?

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

Недавно я столкнулся с некоторыми рефакторингами, сделанными коллегой. Мой код выглядел примерно так:

public Person CreateNewPerson(string firstName, string lastName) {
    var person = new Person() {
        FirstName = firstName,
        LastName = lastName
    };
    return person;
}

Что было реорганизовано на это:

public Person CreateNewPerson (string firstName, string lastName) {
    Person person = new Person ();
           person.FirstName = firstName;
           person.LastName = lastName;
    return person;
    }

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

Мой вопрос: что такое (С#) программный этикет для рефакторинга исходного кода для других людей (как семантического, так и синтаксического)?

Ответы

Ответ 1

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

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

Определите некоторые базовые правила, некоторые анти-шаблоны (которые всегда могут быть реорганизованы вашими коллегами) и т.д.

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

Ответ 2

Я бы меньше беспокоился о вежливости и больше об экономике. Каждое изменение кода вызывает огромное количество затрат:

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Если я изменяю файл, принадлежащий коллеге, я стараюсь, чтобы изменения соответствовали их стилю. Таким образом, хотя половина наших файлов префикс "m_" для полей и полуприцеп "_" (среди других второстепенных вещей), по крайней мере один файл/класс является самосогласованным.

Ответ 10

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

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

Ответ 11

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

Это приведет к обсуждению, где, скорее всего, вы оба узнаете что-то друг от друга.

Ответ 12

Я думаю, что в этом конкретном примере (С#, который есть), вы должны просто следовать рекомендациям Microsoft. Согласованность с стандартами кода .NET Framework упрощает чтение структуры классов и кода.

Другое дело, что Visual Studio автоматически исправляет различные правила форматирования по мере ввода, которые помогут. Например, при закрытии скобки или завершении оператора.

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