我正在开发一个（vb.net/asp.net）项目，该项目使用接口提供依赖注入。但对我来说，感觉就像代码的可维护性已经被扼杀了。当我想通读代码时，我不能简单地跳转到使用的相关类的代码。我看到的只是接口，所以我必须通过项目来找出哪些类正在执行实现。这真的伤害了我的工作效率。
是的，我知道我现在可以使用各种替换类来实现接口。但是，例如，我知道我不会很快更改我的数据源——我不需要启用将其换出的能力。所有这些依赖注入对我来说似乎都是多余的（事实上，它存在的唯一真正原因是支持用于单元测试的模拟类）。我实际上已经阅读了几个地方，状态 DI 实际上更利于可维护性。但这假设您已经知道所有内容在哪里，并且您知道需要更新哪个类。找出在哪里看是杀死我的部分。
所以，我的问题是：有没有更好的方法来遍历代码？有没有更好的方法让代码更易于维护？我们只是做错了吗？或者这是课程的标准杆？
DI 肯定有一些开销，尤其是当您的配置与代码分离时。虽然这是课程的标准，但随着时间的推移，它确实会变得更容易处理，并且随着您对代码的更好理解。
但是，有一些工具可以提供帮助——看看Resharper或CodeRush。两者都为 Visual Studio 中的代码导航体验提供了出色的改进。Resharper 具有出色的“转到符号”或“转到实现”方法，可以快速帮助您导航到接口的实现，无论它在哪里。
关于可维护性：通常，随着时间的推移，松散耦合的设计变得更加重要，因为会有变化。您的代码耦合得越紧密，在不影响整个应用程序的情况下进行小的更改就越难。这就是依赖接口非常重要的地方——无论您是否选择使用依赖注入。
可维护性是许多不同的东西。总体而言，它解决了您可以通过添加新功能来不断发展应用程序的程度。
是的，理解协作者是如何连接的可能会变得更加困难，因此可维护性方面可能会因引入松散耦合而受到影响。
但是，一旦您弄清楚了代码库的工作原理，您应该能够更好地添加新功能而不会放慢速度。从这个意义上说，松散耦合大大提高了可维护性。
不过，这不是灵丹妙药。松耦合是可维护代码的先决条件，而不是保证。