Answers:
即使您非常确定这是“基本设计缺陷”，也请记住您是局外人。它可能在那里是有充分的理由的。或者，根据项目的年代久远，可能由于当时的一个很好的理由将其放到那里，而由于历史原因，它现在仍然存在。
而不是“在邮件列表上爆炸”，请尝试提出问题。就像是：
“嘿，我只是遇到了X，对我来说这没有任何意义。似乎实现该目标的正确方法是Y，但是我又知道我是新来的，我不想得出任何结论。这是设计中的错误，还是我缺少什么？有人可以填写吗？谢谢。”
工程是世界上为数不多的几个仍将谦卑视为真正美德的地方之一，以这种方式提出有关“显而易见的问题”的问题是获得良好答案和学习新知识的一种非常好的方法。
其中的权力的48个法则：
通过行动赢得胜利，决不通过争辩
您认为通过辩论获得的任何瞬时胜利确实是一次痛苦的胜利：与任何瞬时的观点变化相比，您煽动的怨恨和恶意更强大且持续时间更长。让其他人通过您的行动与您达成共识，而无需说一句话，这将更加强大。演示，不要重复。
这是我经过许多毫无意义的争论之后才学到的艰难方法。
在这种特殊情况下，我建议您编写一段非常简单且特定的代码，该代码应该可以工作，但不会因为此设计缺陷而出现问题。俗话说：“您不能与编译器/解释器争论”。
另一件事是，要对一个小组产生影响，就必须将您视为该小组的成员。即使您已加入公司，但人们仍未将您视为该小组的成员。因此，最好与已建立的团队合作，直到他们学会将您视为其中一员为止。
您可能不会喜欢这个...但是，这里...
我正在修复一些错误，以使其进入“循环”并成为项目的常规提交者。问题是我认为我发现了一个基本的设计缺陷，该缺陷导致了我正在研究的错误之一。
不，不，你没有。如果您这样做了，您将不会因此而犹豫。您自己不确定“基本设计缺陷”这一事实，这意味着您尚未发现一个缺陷。当试图指出别人的错误时，并不会让您有任何朋友使用最高级的词（例如“基本”词）。
对于您遇到的问题，您可能发现的是稍微更好的设计。不过，您可能应该进行彻底的测试-由于您是该项目的新手，所以即使您根本不知道自己在说什么，也比没有机会做的更好。
但是我觉得，如果我在邮件列表上放开这个标签，我会变得自负
称其为“基本设计缺陷”肯定会很嚣张。因此，即使指出它可能是错误也不是最好的主意。如果您不知道某个事实（可以备份它）是一个问题，那么您需要谦虚地提出问题并进行研究，直到您完全理解为止。比您想要说服的人都要好。
...而我就此问题进行的一些讨论正在与一些人打交道。我应该怎么做？
停止。这不是道德问题，也不是杀死任何人（我认为）。如果您打算成为该项目的长期成员，则在质疑他们之前必须先获得信任。修复错误，对其进行出色的工作（通过小组的任何衡量标准），设计一些功能，并在桌面上赢得一席之地。
然后，在不用手指指或打断任何东西的情况下，谦虚地提出一个建议，以改进小组的设计。而且您最好仔细考虑所有后果和解决方案，否则您将因“天真”而被击落。准备好争论为什么您的设计会更好。准备好失去，并优雅地失去。
如果您的想法确实更好，那么它将最终被小组接受（尽管可能不会被原始设计师接受），小组不在乎或者小组变得愚蠢。在后一种情况下，无论如何，您为什么要成为小组成员？
...
如果您有能力，另一种选择是只对可恶的东西进行出色的编码，以至于他们对您的编码能力感到惊讶，别无选择，只能接受设计的优雅和永恒。开发人员确实尊重能力，但您必须小心-对无能（或无端的自大）的惩罚相当严厉。但是，由于您是在问这个问题，所以我认为辉煌而毫不掩饰的傲慢路线并不是一种选择。;）