随着软件变得越来越复杂,我们需要结构化代码以使其更易于理解的方法。 例如,函数,类,闭包,文件,目录,存储库,名称空间,包和服务。 但是,代码在这些结构中的分组方式并不总是与各部分如何协同工作。
Eunice旨在帮助您在了解实际依赖关系的情况下探索和定义结构。
![](https://i-blog.csdnimg.cn/blog_migrate/65d2b02c3577111ad00d216f6f1f4003.png)
这篇文章是对早期案例研究的后续报告,该案例研究通过在JavaScript库React上使用Eunice来调查和演示Eunice的功能:
深入研究React体系结构:结构和依赖关系(壮举Eunice)
在React中,最重要的结构范围似乎是其存储库根目录中的packages子目录 。 在案例研究结束时,我根据现有目录结构和Eunice显示的依赖关系为包定义了潜在的堆栈。 但是,这种结构及其依赖性计数看起来并不是特别简单:
![](https://i-blog.csdnimg.cn/blog_migrate/5de19b86449b88548a8e9408b3152db9.png)
软件包目录中有足够的项目和级别,因此很难记住所有依赖关系是什么。 可以通过对共享概念和依赖关系的项目进行分组来改善这一点。
下面突出显示的六个子目录均与devtools相关,其依赖项计数不需要在堆栈中分布,因此可以分组:
![](https://i-blog.csdnimg.cn/blog_migrate/6e43ef195bb9c6659ed5d47b8bd759d0.png)
要调查这种情况,可以修改packages目录中的Eunice堆栈文件。 我添加了一个名为react-devtools-group的新项目,并在其中移动了六个相关项目:
- - existing
- - id: react-devtools-group
dependencyPermeable: true
items:
- [ react-devtools, react-devtools-shell ]
- [ react-devtools-core, react-devtools-inline ]
- - react-devtools-extensions
- - react-devtools-shared
- [ react-art, react-interactions, react-refresh ]
- - react-test-renderer
- [ react-dom, react-native-renderer, react-noop-renderer ]
- [ legacy-events, react-reconciler ]
- [ create-subscription, jest-mock-scheduler, jest-react, react-cache, react-is, react-stream, use-subscription ]
- [ babel-plugin-react-jsx, eslint-plugin-react-hooks, react, react-debug-tools, scheduler, shared ]
我已将YAML中的新项目标记为dependencyPermeable,这样即使在代码的import语句路径中未指定Eunice的依赖关系解析,它也将在其中查找。
重新运行分析并重新加载网页表明,这使得packages目录堆栈更加简单,而没有添加任何不匹配的依赖项:
![](https://i-blog.csdnimg.cn/blog_migrate/bbf660bfd245d18fa92feb57e8330dc7.png)
选择新的react-devtools-group将显示其堆栈:
![](https://i-blog.csdnimg.cn/blog_migrate/94bfeaaa0ae95e3a2f280a3da89a53e2.png)
为了使该分组更加永久和明显,可以在代码中将新的Eunice堆栈替换为新的子目录。
上面的示例是一个显而易见的小组,要使用已定义的共享概念(devtools)来创建其项目内的高凝聚力,并与系统的其余部分建立简单关系。
为了在其他地方获得相同的效果,可能需要直接在代码中进行更详细的工作,以便从系统的许多部分中移走一些小片段。 希望Eunice仍然有用,即使所需的工作更加繁琐。
( 披露 : 作者是Eunice的创作者 )
From: https://hackernoon.com/grouping-code-with-eunice-explained-pycx3zba