Как сказать кому-то, что их модификация к моей программе не хороша?

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

Некоторые вещи, о которых следует помнить:

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

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

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

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

Мне кажется, что нужно меняться. Работайте с этими людьми, чтобы изменить код таким, каким вы хотите его видеть. С ними. Не пытайтесь заставить их это сделать. Просто сделайте это и расскажите им, что вы сделали и почему, и попросите предложения по дальнейшему улучшению, и учитесь друг у друга. Используйте опыт и сильные стороны друг друга. Только мои 2 цента.

Если у вас есть четко определенные стандарты кодирования для проекта, укажите, что код необходимо изменить, чтобы соответствовать этим стандартам. Список, который у вас есть, кажется вполне разумным (хотя по поводу № 3 много споров; я бы только настаивал, чтобы задокументировать действительно запутанные части, так как исправление трех других пунктов, надеюсь, сделает код менее запутанным).

Честно говоря, я думаю, что это политическая проблема, а не проблема кодирования. В частности ...

1. КТО СКАЗАЛ, ЧТО ЭТО ЛИЦО «ЗВЕЗДА»? Если это тот же человек, которого вы описали в другом вопросе, то у вас уже есть свой ответ: ЭТО ЛИЦО НЕТ «ЗВЕЗДА».

Итак, вы попадаете в другие эффекты политики .. .

1. Кто называет этого человека звездой? Почему нельзя просто сказать человеку «это чушь код»? Кто их защищает / защищает, если вы это сделаете? Сможете ли вы сделать это, или вас взорвут / понизят в должности / поставят в кучу «для увольнения»?

Вы задаете вопросы, на которые невозможно ответить изолированно. ЕСЛИ код хрень, то выбросьте и сделайте правильно сами. ЕСЛИ есть причины , по которым вы не можете этого сделать,

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

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

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

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

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

Удачи.

Я бы сделал следующее:

• Убедитесь, что он знает, что его тяжелый труд ценится (желательно, чтобы это было правдой)
• Спросите его, не возражает ли он сделать несколько
• Объясните проблемы, в том числе, почему они возникают, и предложите конкретные изменения, которые помогут ему встать на правильный путь.

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

Мы стараемся решить эти потенциальные «проблемы» проактивно:

• Каждому «большему» проекту, в котором люди работают вместе, назначается проект «codelead» (один из разработчиков). Это меняет каждый проект (в зависимости от предпочтений, опыта выполнения конкретной задачи ...), поэтому каждый может время от времени участвовать в ролях «вносить вклад» и «руководить проектом».
• Мы явно пришли к соглашению. который эти "лидеры" проекта могут решить все, что они хотят с кодом вклад других (своего рода как временная диктатура: изменение это, вносить предложения, просить людей переделывать вещи и т. д.). Код проекта "свинец" несет полную ответственность за совокупный код для работы.

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

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

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

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

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

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

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

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

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

Желательно представить и обсудить случаи, когда вы сами внесли аналогичный вклад код (или, что еще хуже), и что вы столкнулись с огромными проблемами из-за вашего собственного кода, так что теперь эти политики действуют для предотвращения таких проблем. Фактически говоря о своем плохом коде, вы можете быть очень субъективным.

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

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

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

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

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

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

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