我目前正在开发一个可以与 RMI 服务器通信的 RMI 客户端（由我工作的公司的不同部门开发）。另一个团队拥有该接口，但 IMO 它过于复杂，有许多不同的类型来回传递，以及不必要的 (IMO) 复杂的异常层次结构。
我已经多次表示担心，这种不必要的复杂性肯定会在以后我们进行集成时引发问题，但我并没有得到太大的关注。 IMO 它将导致不必要的大量代码共享，而且我们共享的每一个不同的类都是一组额外的版本控制要求，需要注意。
有谁知道我可以用来支持我的论点的任何资源/论点。
或者，谁能说服我说我找错了树？
【问题讨论】：
首先，我想说您描述的问题不仅与 RMI 有关，还与组件的任何类型的接口有关，包括纯 Java 接口，尽管在 RMI 的情况下，糟糕的设计可能有额外的警告，例如性能。
不知道具体情况，只能看我的经历来猜测。接口的这种不必要的复杂性通常与为组件定义的业务需求无效或不足有关。如果是这样的话，将来其他部门的人可能不得不频繁地修改界面，试图赶上新的功能，这通常是组件用户痛苦的原因。虽然随着时间的推移，界面的变化当然是自然的，但在这种情况下，它们可能会导致深度重新设计。
此外，过于复杂的接口通常意味着作者公开了实现细节。不用说，这可能会由于实现的演变、切换到不同的技术，甚至只是优化而导致不必要的接口更改。
最后但并非最不重要的一点是，为用户提供超出他们需要的更多内容是让他们使用甚至不打算使用甚至不存在的功能的直接方法。将来，用户可能会以意想不到的方式调用接口。它使组件的维护成为地狱。
总而言之，简单接口的关键参数是：组件的清晰业务定义、改进的实现灵活性、可维护性。请记住，所有这些利润对组件开发人员和用户都有好处。
【讨论】：
你没有找错树，而是在不同的部门，你可能很难得到你想要的改变。你不可能赢得每一场战斗:-(
但是为你“打好仗”的道具。如果你有时间的话，我建议你向他们展示一个干净的界面版本。但除此之外，你可能只需要放手。
【讨论】：
您将通过数据来完成您正在做的事情。我同意 unforgiven3——这是一场精彩的战斗，而且你没有找错树——如果你现在提出更清洁代码的建议，没有弹药，它可能会被置若罔闻，甚至更糟；可以开始一场“我的马比你的马大”的比赛——没有成效。
只是我的建议；
开始记录错误或任何其他与低效界面相关或指向低效界面的问题
开始记录代码审查，放入一个 wiki（一个公司认可的 wiki——现在不要惹麻烦），现在就记录它——现在还不是通过判断的时候，你是只是收集数据。
当您从这 2 个方面获得足够的数据时，请说明由于设计决策效率低下而导致程序员生产力丢失或被滥用的案例——当涉及成本时，很难争论。
希望对您有所帮助。
【讨论】：