随着Elm项目的规模越来越大，我开始注意到一些轻微的重复出现的情况：
- 我有一个Elm文件，它比屏幕上的代码还多。 我在文件的后半部分，我想知道我正在查看的函数是本地函数还是公开函数。 查找涉及到一直滚动到文件顶部，然后，一旦找到答案，就必须向下滚动并找到我的位置。
- 我想大致了解系统其余部分对特定功能的依赖程度。 找到该想法的最快方法是：突出显示功能，右键单击，选择Elmjutsu，选择“查找用法”，打开另一个面板，扫描该面板，然后返回到我的文件。
不要误会我的意思，Elmjutsu非常棒，“ Find Usages”非常有用，可以帮助我参考那些我不太记得放在哪里的参考。 但这是一个与我上面描述的根本不同的问题。 我希望能够一眼就知道我的系统有多少依赖于给定的功能，就像我希望能够一眼就知道该功能是公开的还是局部的。
我决定制作一个Atom包，以获取有关我希望一目了然的Elm功能的信息，我将其称为Elm Lens。 该项目的目的是提供代码可视化，以在使用大型Elm应用程序时实现最高的生产率。
在启用了Elm Lens的情况下打开Atom时，插件会在您的项目中扫描Elm文件，并开始在后台进程中对其进行解析。 Elm Lens几乎可以立即显示公开信息和本地引用，因为它只需要解析一个文件。 为了向您显示外部引用计数，必须分析整个项目，但是这些过程不会阻止您工作！ 当Elm Lens执行后台处理时，功能标记将更改为向您显示。
在Elm Lens的开发过程中，对我而言最激动人心的时刻之一就是它的引用计数足够好，我可以开始相信它了。 令我非常沮丧的是，我开始注意到项目中的孤立功能。 这些功能曾经是有目的的，但是它们的所有参考文献都已被重构，现在它们正在占用空间。
由于我现在可以轻松地检测到这种情况，因此我决定更改其标记以使其更引人注意：
内部引用为零的局部函数和外部引用为零的公开函数带有警告图标和亮红色文本。 这使得您很难错过可能要清理的碎片。
当然，我发现了一些极端情况。 有几次我们想使用零系统引用公开函数：
我决定了以下规则：如果函数的类型签名以Program开头，则它将忽略公开规则（并且还将获得特殊的标记！）。 您的单元测试也是如此。 这些功能在外部也未引用。 我们将它们暴露出来，以便我们的测试跑步者可以捡起它们。 具有Test类型签名的函数将具有如下所示的标记：
我应该向Mats Stijlaart大声疾呼。 没有Elm Lens出色的Elm语法库，是不可能的！ 他也足够执行一些更改以帮助我正确显示Elm Lens标记。
请尝试Elm Lens，让我知道您的想法。 要使用它，请打开Atom，转到“设置”，单击“安装”选项卡，然后搜索“ elm-lens”。
