有没有办法预测将哪些内容重构为程序集以最大程度地提升 .NET 编译器构建性能？
假设项目的构建时间很长。因此，我想计划一个重构项目，将其中的某些部分作为单独的组件来避免重新编译。现在，我可以尝试重构很多东西，因此最好能够确定那些可以最大程度减少构建时间的模块。
那么我该怎么做呢？我可以根据粗略的人类可计数指标（例如行数或方法数）进行预测吗？或者我可以使用某种编译器分析器来测量编译器处理各种模块的速度，甚至对哪些模块最需要重构做出明确的声明/建议？
suppose build time for a project is taking a long time. So, I want to plan a refactoring project to make some parts of it as separate assembly to avoid recompilation. Now, there are many things that I could try refactoring, so it would be nice to identify those modules that would give me the most build time reduction bang for the effort.
So how do I do that? Can I make predictions based on crude human-countable metrics like number of lines or methods? Or can I use some sort of profiler for compiler that would measure compiler's speed at handling various modules or even make oracular pronouncements/recommendations about which modules are most asking for refactoring?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我本身不会太担心构建时间。如果项目构建时间花费如此长的时间，并且如果减少单个程序集的大小会有所帮助，那么这可能意味着单个程序集中有太多不相关的类。
我首先会重构您的类，以确保它们具有单一职责。我还会确保您的类和类成员使用尽可能少的访问权限 - 不要将所有类设为
public，也不要将所有成员设为public或受保护。接下来，尝试找出哪些公共类是相关的。如果您对它们进行了适当的命名，那么您应该能够根据类的名称来执行此操作。
考虑每组相关类有一个程序集的可能性。希望每个这样的程序集都包含主要相互引用的类。对其他程序集会有一些依赖性。您必须清楚哪些新程序集真正需要访问哪些其他程序集。
使用 ReSharper（或其他此类工具）可以使此过程变得实用。
I wouldn't worry so much about build time, per se. If project build times are taking so long, and if reducing the size of individual assemblies would help, then it probably means you have too many unrelated classes in a single assembly.
I would first refactor your classes to ensure they have a Single Responsibility. I would also make sure that your classes and class members use the minimum access possible - don't make all of your classes
publicand don't make all of your memberspublicorprotected.Next, try to figure out which public classes are related. If you have named them appropriately, then you should be able to do this based on the names of the classes.
Consider the possibility of one assembly per set of related classes. Hopefully each such assembly will contain classes that mostly refer to each other. There will be some dependencies on other assemblies. You'll have to get clear on which of the new assemblies really needs access to which others.
Using ReSharper (or another such tool) can make this process practical.