SS3D icon indicating copy to clipboard operation
SS3D copied to clipboard

Organise the code base into assemblies

Open stilnat opened this issue 3 years ago • 3 comments

Summary

as pointed out by @Em3rgencyLT , using assemblies will be beneficial for the project. Unity's doc about assemblies is pretty good : https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html

The advantages are :

  • Faster compilation time.
  • Easier testing.
  • Spotting unnecessary coupling between classes.
  • Improving code reusability.

To cite @Em3rgencyLT :

The tests require having their own assembly as per how Unity works. But this hides all other code from them, unless I reference the codes assemblies. This is a problem since our code is not split up into assemblies (but it really should be! There is no need to recompile all the files when doing only localized changes each time). As a temporary workaround I created an SS3D.asmdef in the assets folder and referenced all other required assemblies. Then I had the test assembly reference the SS3D one so they could function.

As a future change, we should slowly move each engine subfolder into its own assembly. This would help us spot unnecessary class coupling and force us to move logic into dedicated service classes which could be covered by tests.

The task is to put each engine subfolder into its own assembly. This is coherent with those subfolders representing systems, that can have dependencies of course, but that should not be completely entangled with other systems. This task might be enough work to require an independant task for each system.

stilnat avatar Dec 27 '21 12:12 stilnat

To add to this since it does talk about the entire project: All the other folders that also contain code (Ex. Content, Editor, Networking, etc) can probably just have a single assembly each from what I've seen of their structure.

The way to perform this task is probably:

  1. Delete SS3D.asmdef (and ignore the broken tests, maybe even comment them out while working on this)
  2. Add assembly definition to your engine folder of choice
  3. Resolve any issues until everything compiles, clean up stuff, decouple classes, etc (the hard part).
  4. Rinse repeat steps 3 and 4 for as long as you are comfortable or until everything is done
  5. Add references to the required new assemblies you just made to fix tests

Em3rgencyLT avatar Dec 27 '21 12:12 Em3rgencyLT

Do we actually need that first step? I think it will work even if you leave SS3D asmdef in there, because the asmdef in the engine folder will override it for scripts in that folder.

Ryan089 avatar Dec 27 '21 19:12 Ryan089

You're right that it will work, but it defeats the purpose. It will always compile everything since SS3D encompasses everything. You won't notice any bad code coupling for the same reason.

Em3rgencyLT avatar Dec 27 '21 20:12 Em3rgencyLT