2010-03-26 1 views
15

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

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

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

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

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

+3

Вы должны сделать это сообщество wiki. –

+1

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

+0

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

ответ

5

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

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

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

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

3

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

5

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

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

0

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

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

2

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

3

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

+0

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

+1

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

0

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

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

10

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

12

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

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

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

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

+0

+1: Хорошо, сэр. – LBushkin

1

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

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

1

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

0

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

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

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

 Смежные вопросы

  • Нет связанных вопросов^_^