language-agnostic - 如何告诉某人他们对我的程序的 mod 不好？

Question

G'day,

这与my question on star developers有关并到 this question regarding telling someone that they're writing bad code但我正在考虑更具体的情况。

也就是说，我如何告诉“明星”他们对我编写的程序所做的更改做得很差并且实现不一致，而不仅仅是听起来像我对某人“玩弄我的东西”感到恼火？

添加的新功能被故意排除在此 shell 脚本的原始版本之外，以使其尽可能简单，直到我们了解我们将在系统负载下看到的错误为止。

基本上，我认为尝试再次猜测所有错误情况是不可能的，实际上可能会让我们在完成大量工作后走上完全错误的道路。

在看到需要添加的内容后，有人潜入并进行了添加，但不幸的是:

逻辑不一致

变量名不再描述它们包含的数据

几乎没有评论

变量的使用方式不容易遵循，并且大大降低了可读性，从而降低了可维护性。

我总是尝试从 Damien Conway 的角度进行编码“始终编码，就好像您的系统将由知道您住在哪里的精神病患者维护一样。”也就是说，我尽量让它容易被关注，而不是作为我自己才华的广告。 “这段代码有什么作用？”练习很有趣，最好留给混淆竞赛恕我直言。

任何建议都非常受欢迎。

干杯，

Answer 1

我会说实话。您不一定需要指出错误的每个小细节，但值得举出几个您将要提出的一般性观点的示例。您可能想要对在第一个简短反馈中没有提到的其他示例做笔记，以防它们挑战您的推理。

尽量确保反馈完全是关于代码而不是人。例如:

好: foo() 中的参数验证似乎与 bar() 中的不一致.在 foo() , NullPointerException如果调用者传入 null 则抛出, 而 bar()抛出 IllegalArgumentException .

不好:您的参数验证到处都是。你扔NullPointerException在 foo()但是 IllegalArgumentException在 bar() .请尽量保持一致。

即使是“请”，第二种形式也是在谈论开发人员而不是代码。

当然，在许多情况下，您不必担心如此小心，但如果您认为他们会对此非常敏感，那么努力是值得的。 (仔细阅读你写的内容，如果是书面反馈:我不小心在第一个版本中包含了一个“你”:)

我发现大多数开发人员(无论是否是 super 明星)都非常合理地接受“不，我没有实现该功能，因为它存在 X 问题。”不过也有可能我很幸运。