我正在开发一个使用接口提供依赖注入的（vb.net/asp.net）项目。但对我来说，感觉代码的可维护性已被杀死。当我想阅读代码时，我不能简单地跳转到使用的相关类的代码。我所看到的只是接口，因此我必须通过项目来查找正在执行的类。这真的伤害了我的生产力。
是的，我知道我现在可以使用各种替换类来实现接口。但是，例如，我知道我不会很快改变我的数据源 - 我没有必要启用交换它的能力。所有这些依赖注入对我来说似乎有些过分（事实上，它唯一真正的原因是支持模拟类进行单元测试）。我实际上已经读过几个地方，说DI实际上更适合可维护性。但这假设您已经知道一切都在哪里，并且您知道需要更新哪个类。找出去哪儿看是杀死我的部分。
所以，我的问题是：是否有更好的方法来遍历代码？有没有更好的方法使代码更易于维护？我们只是做错了吗？或者这个课程是否相同？
答案 0 :(得分：5)
DI确实存在一些开销，特别是当您的配置与代码分离时。虽然这个 是该课程的标准，但随着时间的推移，它会更容易处理，并且您可以更好地理解代码。
但是，是工具可以提供帮助 - 请查看Resharper或CodeRush。两者都为Visual Studio中的代码导航体验提供了极好的改进。 Resharper具有出色的"Go To Symbol"或"Go To Implementation"方法，可以快速帮助您导航到界面的实现，无论它在哪里。
关于可维护性：一般来说，松散耦合的设计随着时间的推移变得更加重要，因为将发生变化。代码越紧密耦合，在不影响整个应用程序的情况下进行小的更改就越困难。这是取决于接口非常重要的地方 - 您是否选择使用依赖注入。
答案 1 :(得分：4)
可维护性是很多不同的事情。总的来说，它通过添加新功能来解决您不断发展应用程序的程度。
是的，了解协作者的联系方式可能会变得更加困难，因此通过引入松散耦合，可维护性可能会受到影响。
但是，一旦你弄清楚代码库是如何工作的，你应该better able to add new features而不会减速。从这个意义上说，松散耦合可以提高可维护性。
但是，这不是一颗银弹。松散耦合是可维护代码的先决条件，而不是保证。