Подрядчик, изменяющий [закрытый] стиль кода

Как мне поговорить об этом с подрядчиком?

Вежливо: объясните, почему вы хотите минимизировать изменения в исходном коде.

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

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

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

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

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

Когда я вижу вещи, которые мне не нравятся в чужом коде, которые достаточно серьезны, чтобы требовать внимания, я сначала уточняю у владельцев кода. Даже если есть очевидные ошибки, s их кодекс и их решение об очистке, а не мое.

Везде, где есть оператор if и одна строка, они добавили фигурные скобки

Это и только это может быть полезно.

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

Эти не имеет смысла менять.

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

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

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

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

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

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

Пусть подрядчик отменит все свои изменения. Сегодня. И в его личное время.

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

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

В-третьих, заставьте его объяснить обоснование сделанных им изменений. Удаление var не дает никаких преимуществ в производительности.

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

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

Наконец, вам, возможно, придется просто перекусить пулю и ЗАПЛАТИТЬ ему за возврат. Да, это отстой, но поскольку вы совершили ошибку, не проконтролировав его, не уточнив заранее, чего вы хотите, и что ему не разрешается делать... Вы заплатите окончательную цену. Вы можете либо заплатить ему за это, либо заплатить кому-то другому за это, либо заплатить вам за это, либо жить с этим (и заплатить цену за испорченные диффы). При любом раскладе это будет стоить вам денег.

Внедрите FxCop - это должна быть ваша первая линия защиты. Также, если вы используете систему управления версиями (если вы не реализуете ее как можно скорее), обязательно используйте маркировку разработчика (только сборку для файла, который был помечен для сборки), и не давайте ему права перемещать метки на файлы. Таким образом, вы можете тщательно изучить его изменения и отказаться от маркировки его кода до тех пор, пока он не будет соответствовать вашим стандартам. Независимо от того, что он кодирует, он не попадет в QA, пока вы не переместите ярлык разработчика на соответствующую ревизию, так что он в значительной степени в вашей власти. Обратите внимание, что некоторые магазины не используют единую метку для своих сборок песочницы, им нравится применять новые метки даже к песочнице, так что вы, возможно, тоже захотите это сделать.

Как говорили другие, эти изменения просто для стиля кодирования. Если он хочет улучшить производительность, он зря тратит время на эти изменения. Если он не может указать, как эти изменения улучшат производительность, значит, его ОКР просто оплачивает счет.

Я бы сказал: «Я ценю ваши изменения в стиле кодирования, но позвольте сосредоточиться на нестилевых изменениях в областях кода, которые вызывают замедление».

Это довольно распространенное явление, когда люди не могут устоять перед "улучшениями", и вдруг вы обнаруживаете, что вам выставили счет за то, чего вы не хотели. Иногда я уверен, что это делается намеренно, чтобы получить более оплачиваемую работу, но в основном я думаю, что это разработчик, который зашел в тупик и не может справиться с оставлением "неправильного" кода. Это может потребовать некоторой борьбы, но в основном вам придется постоянно повторять: "Не меняйте ничего, над чем вас не просили работать". В зависимости от его характера, вам, возможно, придется просто попросить его один раз вежливо, или попросить кого-нибудь повыше заставить его.

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

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