Этикет для рефакторинга исходного кода других людей?
Наша команда разработчиков программного обеспечения состоит из набора опытных программистов со множеством стилей программирования и предпочтений. У нас нет стандартов для всего, просто минимальные потребности для предотвращения общего хаоса.
Недавно, я врезался в некоторый рефакторинг, сделанный коллегой. Мой код, на который походят несколько это:
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;
}
Просто, потому что мой коллега должен был обновить некоторый другой метод в одном из классов, которые я записал, он также "осуществил рефакторинг" метод выше. Для записи он - один из тех разработчиков, который презирает синтаксический сахар и использует другую скобку placement/identation схема, чем остальная часть нас.
Мой вопрос: Каков этикет программиста (C#) для рефакторинга исходного кода других людей (и семантический и синтаксический)?
12 ответов
Этикет всегда должен соблюдаться на уровне команды. Так что поговорите об этом со своим коллегой, а затем поговорите со всей командой, чтобы определить правило.
Общие правила могут содержать запрет на изменение кода, если это только для улучшения и оспаривания стилей кодирования. Если кому-то в будущем придется поддерживать ваш класс, то, как правило, он может все изменить.
Определите некоторые базовые правила, некоторые анти-шаблоны (которые всегда могут быть переработаны вашими коллегами) и так далее.
Такие правила не должны быть очень строгими, поэтому расстановку скобок или подобных вещей определять не нужно. Но в этом случае никто не должен улучшать код, утверждает кто-то другой. Если у вас возникнет конфликт из-за чего-то, обсудите это всей командой, чтобы создать новое правило для этого случая.
Без руководств / правил стиля кодирования он мог бы даже не осознавать, что изменение вызывает раздражение.
Тем не менее, стиль довольно нестандартный, и на личном уровне я был бы раздражен «рефакторингом», который не меняет смысла кода, а служит только для того, чтобы запечатлеть его стиль кодирования на вашем лице. . Я не уверен, что это вообще можно назвать рефакторингом. Довольно эгоистично.
Создал ли он большую часть кода для рассматриваемого проекта? Если бы это было так, я мог бы понять, что он сделал. При входе в проект, который уже идет полным ходом, я стараюсь соответствовать форматированию, которое уже используется во всем коде.
Конечно, это может не относиться к вашей ситуации. Если какой-либо проект получил от всех в целом равный вклад, возможно, прислушайтесь к совету Мнемента и решите проблему.
Я бы меньше беспокоился о вежливости и больше об экономике. Каждое изменение кода влечет за собой огромные затраты:
- изменения кода должны проверяться QA
- изменения кода должны иметь наборы тестов, написанные для них разработчиками
- изменения кода, которые влияют на взаимодействие с пользователем, могут нуждаться в документировании
- изменения кода могут привести к ошибкам; это, очевидно, огромные затраты
- и так далее.
Я бы не мечтал о внесении незначительных изменений «только для эстетики» в любой код производственного качества, независимо от того, был он «моим» или нет. Выгоды от изменения даже близко не оправдывают затрат.
Вы можете подумать о том, чтобы напомнить своему коллеге, что вы занимаетесь кодированием, не для того, чтобы создавать красивый код, который вам всем кажется эстетически приятным, а для того, чтобы приносить прибыль вашей компании в условиях слабой экономики. Вы не художники, вы инженеры, поэтому действуйте как инженеры; все изменения должны быть оправданы бизнес-целью.
ИМХО, это не делает код чище, просто накладывает на него стиль кодирования другого парня. Вы должны обсудить это со своим коллегой (коллегами), действительно ли этот тип «рефакторинга» действительно необходим (и действительно ли у вашего коллеги нет лучших способов провести время: -)
Самым важным аспектом этого является согласованность. Ваша команда должна решить, следует ли использовать вывод типов и инициализаторы объектов, и записать некоторые рекомендации по кодированию.
Я считаю, что самое важное - уметь не соглашаться и брать на себя обязательства. У всех есть свои предпочтения, но изменение неважных вещей туда и обратно тратит время.
Безжалостно придерживайтесь стандарта. Если нет стандарта, то это ваша проблема, а не то, что другие люди могут и действительно изменяют ваш код.
Кроме того, прежде чем расстраиваться из-за изменений кода, вам нужно определить намерение. Было ли это злонамеренное или невинное изменение?
Я бы просто поговорил с вашим коллегой-разработчиком о том, что вы хотите рефакторировать и почему. Реорганизуйте код только в том случае, если вы с чем-то согласны.
Это приведет к дискуссиям, в которых, скорее всего, вы оба чему-то научитесь друг у друга.
Я верю в коллективное владение кодом , то есть этот код принадлежит проекту, а не отдельному инженеру. Так что у меня нет проблем с рефакторингом того, что я написал, если это соответствует стандартам проекта. Если в проекте нет стандартов кодирования, команда должна их определить.
Если я изменяю файл, принадлежащий коллеге, я стараюсь, чтобы изменения соответствовали их стилю. Таким образом, даже если половина наших файлов префикса «m_» для полей и половина префикса «_» (среди прочего), по крайней мере, один файл / класс является самосогласованным.
Я думаю, что в этом конкретном примере (то есть C #) вам следует просто следовать рекомендациям Microsoft. Согласованность со стандартами кода .NET Framework упрощает чтение структуры классов и кода.
Другое дело, что Visual Studio автоматически корректирует различные правила форматирования по мере ввода, что может помочь. Например, при закрытии скобки или завершении оператора.
Я лично считаю, что косметический рефакторинг выглядит некрасиво и снижает удобочитаемость, тогда как ваш код придерживается соглашений .NET.