天，
这与我对明星开发人员的问题以及关于告诉某人他们正在编写错误代码的问题有关，但我正在研究一种更具体的情况。
也就是说，我如何告诉“明星”他们对我编写的程序的更改做得很差并且执行不一致，而不会听起来像我对某人“玩我的东西”感到恼火？
添加的新功能被故意排除在这个 shell 脚本的原始版本之外，以保持它尽可能简单，直到我们知道我们将在系统负载下看到的错误。
基本上，我认为尝试再猜测所有错误情况是不可能的，实际上可能会让我们在完成大量工作后走上完全错误的道路。
在看到需要添加的内容后，有人潜入并进行了添加，但不幸的是：
我总是尝试从 Damien Conway 的角度来处理编码“总是像你的系统将由知道你住在哪里的精神病患者维护一样进行编码。” 也就是说，我尽量让它易于追随，而不是作为我自己才华的广告。“这段代码有什么作用？” 练习很有趣，最好留给混淆竞赛恕我直言。
任何建议都非常受欢迎。
干杯，
我只想说实话。您不一定需要指出每一个错误的小细节，但值得举几个例子来说明您将要提出的任何一般性观点。您可能需要记录您在第一次简短反馈中未提及的其他示例，以防它们挑战您的推理。
尽量确保反馈完全是关于代码而不是人。例如：
好： 中的参数验证foo()似乎与 中的不一致bar()。In foo()，NullPointerException如果调用者传入，则抛出 a null，而bar()throws IllegalArgumentException。
坏：你的论点验证无处不在。你NullPointerException投入foo()但IllegalArgumentException投入bar()。请尽量保持一致。
即使是“请”，第二种形式是在谈论开发人员而不是代码。
当然，在许多情况下，您不必担心过于小心，但如果您认为他们会对此非常敏感，那么值得付出努力。（仔细阅读你写的东西，如果它是书面反馈：我不小心在第一个版本中包含了一个“你”：）
我发现大多数开发人员（无论是否超级明星）都非常合理地接受，“不，我没有实现该功能，因为它有问题 X。” 不过，我可能很幸运。
从另一个角度来看，我鼓励你换位思考。我将描述一个“假设的”体验。
需要记住的一些事项：
请记住这一点并与他们交谈。教他们。无需大喊大叫或小便比赛。请记住，他们并不是故意让您的生活变得困难。
我看到你问了很多关于如何与某些类型的开发人员打交道的问题。这似乎是你的共同话题。你一直在问如何改变你周围的人。如果这对您来说是一个持续存在的问题，那么也许您就是问题所在。
现在我知道你在问问题是为了学习如何与你觉得困难的人打交道，这很好，但是，你一直在问（并得到答案）关于如何改变人。
在我看来，你需要改变。与这些人合作，将代码更改为您想要的样子。跟他们。不要试图让他们这样做。只要去做，告诉他们你做了什么和为什么，并提出进一步改进的建议，互相学习。发挥彼此的经验和优势。只是我的2美分。
是的，尽可能保持反馈的赞赏性、专业性和技术性，用可能的“最坏情况”场景支持您的担忧，以便这些功能和/或此特定实现的缺点变得非常明显。
此外，如果这是关于非常具体且对大多数用户没有任何用处的功能/代码，请表达您对代码/使用比率的担忧 - 表明对增加的代码库复杂性等的担忧。
理想情况下，将您的担忧以开放式问题的形式提出——在某种意义上：“不过，我想知道这种方式是否可以长期有效，因为……”。这样您才能真正鼓励贡献者之间的积极对话。
邀请您的其他贡献者和用户就这些问题提供他们的意见，实际上询问其他人/贡献者他们对此添加的想法（在利弊、要求、代码质量方面），请声明您愿意如果其他贡献者/用户可以提供相应的见解，请重新考虑您当前的立场。
您基本上是在鼓励以这种方式进行非正式审查，要求您的社区也研究提议的添加内容，以便讨论优缺点。
因此，无论决定是什么，都将是社区支持的决定，而不仅仅是您做出的决定。
作为原始设计的架构师，您也可以很好地提供架构原因，说明为什么某些东西（尚）不适合包含/部署。
如果稳定性、复杂性或代码质量是一个真正的问题，请说明其他贡献如何也必须经过一定的审查过程才能被接受。
您还可以提及特定代码如何与您当前的设计不完全一致，或者它可能无法很好地随着您当前设计的未来扩展而扩展，同样您可以强调为什么某些东西被明确地遗漏了。
如果您真的喜欢这些功能或核心理念，请务必强调这些功能在正确实施和集成的情况下会带来的出色补充，但也要强调由于多种原因，现有实施并不真正合适。
如果可以的话，请提出具体的改进建议，提供如何更好地做事的示例，以及应该避免和表达您希望的事情，这可以在您的项目社区的帮助下进行修改以添加。
理想情况下，提出您实际接受此贡献的要求并提及您的要求背景，您实际上可能会说您自己讨厌其中的一些要求。
最好展示并讨论您自己贡献了类似代码（甚至更糟糕的代码）以及您最终因自己的代码而面临巨大问题的实例，以便现在制定这些策略来防止此类问题。通过实际谈论您自己的糟糕代码，您实际上可能非常主观。
强调您通常很欣赏这项工作本身，并且您愿意提供必要的帮助和指导，以使有问题的代码具有更好的形状和形式。此外，鼓励将来在您的社区内适当协调类似的贡献，以避免类似的问题。
始终考虑特性和功能（并提醒您的贡献者也这样做），而不是代码 - 将其想象成一个彻底的代码审查过程，最终提交/接受的最终代码可能与原来的实现。
这又是一个很好的可能性，可以展示您自己开发的代码最终在很大程度上被重新设计的示例，因此现在大部分代码都被更好的实现所取代。
同样，没有活跃维护者的代码总是存在问题，因此您可以轻松地建议您担心最终可能无法维护的代码，您甚至可以询问相应的开发人员是否愿意帮助维护该代码，可能在一个单独的分支中。
从同样的意义上说，总是要求新代码伴随着适当的注释、文档和其他更新。换句话说，添加新功能或更改现有功能的代码应始终伴随对所有相关文档的更新。
最终，如果您立即知道在不久的将来您不能也不会接受任何代码，您至少可以邀请开发人员分支甚至分叉您的项目，可能在您的存储库中并在您的帮助和指导下，所以您仍然对与您的项目合作表示感谢。
如果您已经为项目明确定义了编码标准，请指出需要更改代码以符合这些标准。您那里的列表似乎是相当合理的反馈（尽管#3 有很多争论；我只会推动记录真正令人困惑的部分，因为修复了其他三点，希望可以使代码不那么混乱）。
如果您的存储库中有该开发人员几个月前的任何其他示例，请向他展示一个并询问他正在做什么。（几个月后给他看这个）。当他不得不四处寻找变量中的实际内容并解构每一行代码以弄清楚它在做什么时。在那里参加代码审查/结对编程会议。一起重构和重命名，这样他就有希望自己开始明白为什么这些事情很重要。
坦率地说，我认为这是一个政治问题，而不是编码问题。具体来说...
那么你就会进入政治的其他影响......
您提出的问题无法真正孤立地回答。如果代码是废话，则将其丢弃并自己正确执行。如果有理由你不能这样做，那么你需要问问自己这个地方的好处是否超过了负面影响。
干杯，
-R
创建一个程序然后将其发布以供其他开发人员使用是很困难的。你把你的代码扔给别人的开发风格、编码约定等摆布。
在编写代码之后告诉那些开发人员他们的编码很糟糕，这是您能做的最困难的事情之一。最好在他们开始使用您的代码之前解决您的问题。这可以通过两种方式完成：维护详细的编码标准，要求提交的代码遵守此标准并维护开发路线图，不仅仅是概述新功能何时出现，而是创建依赖关系以避免此类事故。
对于您的情况，重要的是不要批评，否则可能会导致敌意和更糟糕的代码进入。也许您可以与该开发人员一起创建标准文档。您将能够表达您对标准应该是什么的想法，并且您将获得他们的意见，而不会引起任何不好的感觉。
总是指出他们代码中的好东西，并确保在讨论弱点时，你要指出它们对每个人（包括开发人员）都有利的原因，从不批评。
祝你好运。
我会做以下事情：
希望这次练习能帮助他更好地融入文化项目。
我们尝试主动解决这些潜在的“问题”：
有了这些正式的“线索”（以及不断变化的角色），我认为人们对他们贡献的部分的（建设性）批评问题较少。