Этикет для рефакторинга чужого исходного кода? - PullRequest
15 голосов
/ 26 марта 2010

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

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

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;
    }

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

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

Ответы [ 12 ]

12 голосов
/ 26 марта 2010

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

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

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

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

10 голосов
/ 26 марта 2010

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

5 голосов
/ 26 марта 2010

Без руководящих принципов / правил в стиле кодирования он может даже не знать, что изменение вызывает раздражение.

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

5 голосов
/ 26 марта 2010

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

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

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

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

3 голосов
/ 26 марта 2010

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

3 голосов
/ 26 марта 2010

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

2 голосов
/ 26 марта 2010

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

1 голос
/ 26 марта 2010

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

1 голос
/ 26 марта 2010

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

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

0 голосов
/ 03 июня 2010

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

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

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

...