Этикет для рефакторинга исходного кода других людей?
Наша команда разработчиков программного обеспечения состоит из множества опытных программистов с различными стилями и предпочтениями в программировании. У нас нет стандартов для всего, просто для того, чтобы предотвратить полный хаос.
Недавно я столкнулся с некоторыми рефакторингами, сделанными коллегой. Мой код выглядел примерно так:
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.