在整体式干草堆中找到C针的更好方法

The problem

问题

Ever struggle to untangle a Big Ball of Mud? I have too. Too many times to count. Borne out of abject frustration and significant time spent reverse-engineering code, I’m excited to open source a tool I created, SourceCrawler, to help us all work through C# monoliths.

曾经努力解开一个泥浆大球吗？ 我也有。 数不胜数。 出于无奈的沮丧和花费大量时间进行逆向工程的代码，我很高兴将我创建的工具SourceCrawler开源，以帮助我们所有人通过C＃整体工作。

After I’d started my third position as a senior software engineer, specializing in C#, at an enterprise software company, I’d pretty much had it with digging through thousands of C# files for code affecting a given behavior and attempting to reverse-engineer the file to the project, solution, and assembly. I’d ask people about the location of the solutions, projects, and in which assemblies a particular file or bit of functionality contributed, but, if the individual who coded a given section was even still around, they — understandably — rarely had any memory of anything about the code in question.

在一家企业软件公司担任C＃专长的高级软件工程师的第三份工作开始后，我就通过挖掘成千上万的C＃文件来查找影响给定行为的代码并尝试进行逆向工程，从而完成了这一工作。文件到项目，解决方案和程序集。 我想向人们询问解决方案，项目的位置，以及特定文件或某些功能在其中组装的程序集，但是，如果编码给定部分的个人仍然在身边，那么-可以理解-他们几乎没有任何记忆任何有关代码的问题。

Every company was once a start-up and a practice of throwing in unreviewed code to douse the latest fire-du-jour was pervasive, and naming conventions from variables, through source and project files, to assemblies were barely-existent or inconsistent. The requirements (read: customer and market demands) changed dramatically during development and reliable refactor tools were either neither available nor sufficient, or just not used in the interest of speedily getting the code to production.

每家公司都曾经是一家初创企业，并且普遍使用未经审查的代码来散布最新的“ fire-du-jour”，并且从变量，源文件和项目文件到程序集的命名约定几乎不存在或不一致。 在开发过程中，需求(阅读：客户和市场需求)发生了巨大变化，可靠的重构工具既不可用也不充分，或者只是为了快速使代码投入生产而未使用。

I realized that a tool was needed for newbies to quickly locate functionality in C# monoliths. Not just to find where it might be in the source, but to find where it is in the hierarchy of solutions, projects and, ultimately, which assembly that file affected.

我意识到，新手需要一个工具来快速定位C＃整体中的功能。 不仅要找到它在源代码中的位置，而且要找到它在解决方案，项目和最终影响该文件的程序集的层次结构中的位置。

A utility is born

实用程序诞生了

My current company allows employees to switch departments with some regularity. I found myself between departments and started researching, designing, and writing the SourceCrawler during an afternoon of no particular deliverable for the department from which I would soon depart.

我现在的公司允许员工有规律地换部门 。 我发现自己处在部门之间，并在一个下午无法开始交付的部门的特定下午开始研究，设计和编写SourceCrawler。

Where the SourceCrawler adds value over directory ‘grep’ tools

SourceCrawler在目录“ grep”工具上增加价值的地方

I’ve used many grep tools (but I love Agent Ransack now). They have several things in common: they crawl an entire directory structure recursively, searching for text, or a pattern of text, in files matching a given pattern. Each search starts the crawl process from the root. While the speed does increase after the first search given Windows improvements in caching throughout the years, one will typically get little context other than the file’s location in the directory structure per “hit.”

我已经使用了许多grep工具(但是我现在爱Agent Ransack )。 它们有一些共同点：它们以递归方式爬行整个目录结构，在与给定模式匹配的文件中搜索文本或文本模式。 每次搜索均从根目录开始爬网过程。 多年来，由于Windows在缓存方面的改进，首次搜索后速度确实有所提高，但是通常，每次点击时，除了文件在目录结构中的位置以外，几乎没有其他上下文。

SourceCrawler is different in that it only searches *.cs files, and shows you in which projects, solutions, and assemblies that file contributes. Also, the directory structure and all source-file data is ingested into memory, yielding typically sub-1 second search times (depending on the things you already know about data magnitude, memory performance, etc., which increases search times). Once the directory tree is ingested, it can actually be deleted and you’ll still be able to search over the source.

SourceCrawler的不同之处在于，它仅搜索* .cs文件，并显示文件在哪些项目，解决方案和程序集中起作用。 同样，目录结构和所有源文件数据都被吸收到内存中，通常产生不到1秒的搜索时间(取决于您已经知道的有关数据大小，内存性能等方面的信息，这会增加搜索时间)。 提取目录树后，实际上可以将其删除，您仍然可以在源中进行搜索。

This is a double-edged sword, of course: when you change source on the disk, you’ll need to “recrawl” to get the latest code into SourceCrawler. A command-line option exists to run scheduled re-crawls via Task Manager, or after a source pull or sync.

当然，这是一把双刃剑：当您更改磁盘上的源代码时，需要“重新爬网”才能将最新代码导入SourceCrawler。 存在一个命令行选项，可以通过任务管理器或在源提取或同步后运行计划的重新爬网。

SourceCrawler in practice

实践中的SourceCrawler

I’ve been using this tool to help me locate and start solutions since the day I had a walking skeleton of it. Not a day goes by when I don’t use it to answer some typical developer question. A few others in my organization have used it also.

自从我开始使用它的那一天起，我就一直在使用该工具来帮助我查找和启动解决方案。 没有一天我不使用它来回答一些典型的开发人员问题。 我组织中的其他一些人也使用了它。

Starting solutions and opening command prompts or the Explorer from a given location has proven to be invaluable to save me from navigating through a maze of directories — which also can be redundantly or just badly named — on an almost hourly basis.

从给定的位置启动解决方案并打开命令提示符或资源管理器被证明是无价的，这使我免于在几乎每个小时的时间内浏览迷宫般的目录(也可以是冗长的名称或名称不正确)。

As a developer, you know that saving seconds once a day is not a big deal — but multiply that by 75 or 100 per day and the time savings add up. Not to mention the lower levels of frustration resulting from not having to navigate old, rotted, yet functional code.

作为开发人员，您知道每天节省几秒钟不是什么大问题，但是每天将其乘以75或100即可节省时间。 更不用说由于不必浏览旧的，烂而又功能强大的代码而导致的低水平的挫败感。

I look forward to your feedback and PRs.

我期待您的反馈和PR。

Download at: SourceCrawler

在以下位置下载： SourceCrawler

翻译自: https://engineering.salesforce.com/a-better-way-to-find-the-c-needle-in-the-monolith-haystack-65eed89a4f2c