目的
Unity默认是将代码放入工程，这样容易带来一些问题。
1. 代码和资源混合，职能之间容易互相误改。
2. 当代码量膨胀到一定程度后，代码的编译时间长到无法忍受。新版的unity支持通过asmdef来将代码分成多个dll工程，有所缓解。
所以，我们可以将代码全部挪到Unity工程之外，将代码编译成dll，然后把dll以managed plugin的方式放入unity工程。
实现
那么，我们怎么组织代码工程呢。先看下unity的vs tool自动生成的工程格式。
Assembly-Csharp: Scripts下的代码
Assembly-Csharp-Editor: Editor下的代码
Assembly-Csharp-firstpass: PluginsScripts下的代码 （一般还有个Csharp-firstpass-editor的工程，此工程下为Plugins/Editor的代码）
Unity.2D.Spritexx：这个是笔者导入的Sprite2D的package，由于此package为unity内置，实际存放目录在Unity安装目录的 Data/Resources/PackageManager/Builtin下。非内置的在Library/PackagesCache目录下。
查看工程settings
首先需要打开查看权限，visual studio-option-tools for unity-general，将Access to project properties改成True。
具体的compilation symbols很长，这里就不贴出来了。
此时，我们直接将此工程拷贝到项目外面，然后批量修改csproj里的文件路径，右键build，将dll放入原工程，触发unity编译后，会出现很多重复定义的报错，没关系，这是因为dll和工程内的代码重复了。
直接删吗？不急，先备份下工程。
删除代码，报错消失。点play，所有功能消失，一大堆script missing的warning。
原有脚本的meta都被删除了，难怪。没办法，用文本全局替换下guid。
原始脚本的meta 类似这样
而dll内的脚本meta 类似这样
其中fileID为dll的guid，而guid为dll内class的id（class名字不变的情况下，此ID不会变）
批量替换后，点play，一切恢复正常。（此批量替换过程，理论上完全可以自动化）
至此，工作是否已经完成？
没有。
这时候打包，会提示dll reference了 UnityEditor.dll，怎么办呢？ 查看project 的编译宏，果然有各种UNITY_EDITOR的宏。
看来需要在打包的时候，单独重新编译dll。
好在visual studio支持命令行打包dll，即msbuild。本地编译runtime的dll，命令行如下
Msbuild xx.csproj /t:Rebuild /p:DefineConstants=a;b;c;…
此处的defienConstants即为编译宏，覆盖了csproj里定义的define。依次将csharp和csharp-plugin编译。（Editor dll暂时忽略）
再次打包，成功。
但是此时 点击编辑器的play，你会发现有些功能发生异常（取决于代码），有些定义找不到了。原因是Editor的dll和Play的dll不兼容了（编译宏不一样）。所以为了编辑器运行正常，又得编译一遍play的dll。
此过程到此，感觉流程已经走通了。然而在发布到项目组正式开发流程之前，还有一些问题需要解决。
问题
- 代码调试问题
vs调试 managed dll时，需要mdb文件。所以我们在编译dll时，需要手动生成mdb。可以从google上下载一个pdb2mdb，在post build时，自动生成mdb，并将mdb和dll拷贝到unity工程。（隔壁项目组说将pdb和dll放入工程，unity会自动生成mdb，但尝试了n次均失败，遂放弃unity自带的mdb功能）。
- 编译宏问题
unity编译代码的宏，来自于几个地方：
a. Build setting defines
b. asmdef内的定义
c. unity内部的define（根据buildplayer传入的platform和buildoption来决定）
如果仅靠visual tools生成的工程里的define，显然不太实际。vs tools本身不负责编译dll，工程里的define仅仅为了方便代码编辑和代码自动补全。这部分可以查看 vs tools的源码（已经做成package了），vs tools是根据unity编译出的dll，去自动更新vs工程。而无代码化后的流程 其实是反过来了。
不过，通过查看 visual studio code editor源码，找到unity一个内部的接口
通过此接口，可以获取各个target和option的编译宏
- 引用依赖问题
Vs tools是将所有可能依赖的dll全部加到reference列表中，多的reference倒是无所谓，最终编译都只会包含真正需要引用的dll。但是ref dll的路径 需要处理下，默认为全路径，但每个人机器上unity安装目录都不一样，所以需要通用化。有两个方法：
a. 将dll拷贝到工程同级目录，将ref hintpath改成相对路径（不过，在unity升级后，此目录也需要升级，不适合unity需要频繁升级的项目）
b. 添加环境变量UNITY_PATH，修改csproj，示例如下
csproj的Condition可以很好的解决不同环境下的一致性问题
- Include scripts问题
由于涉及到多人协作，我们的csproj没有采取正则include，而是显式的include了每个代码文件，这样产生了两个问题
a. 所有人都需要提交csproj，而csproj默认是将新加的代码添加至末尾，所以在多人同时新加文件时，很容易产生冲突，而且不能自动resolve，需要手动合并。
b. 若引入了第三方的package，升级变得繁琐，要逐个检查是否需要include
为了解决这个问题，综合各个方面，决定使用终极方案，即根据代码文件/asmdef以及自定义的一些规范，自动生成csproj，这个过程跟vs tools类似。实现后，开发不再需要提交csproj文件，并且会自动检测代码文件的新增或删除，并自动修改，这样你的visual studio会自动提示reload（是不是跟原始的工作流程很像了？）。这个自动生成的过程，可以参考visual studio editor package代码，此处就不再做详细展开。
- Burst compile问题
Unity2019提供了burst功能，这个burst过程是在打包阶段发生的，它会自动扫描unity自动生成的dll（即Csharpt-xxx系列）内的代码，然后进行burst。但是此时我们的代码都在plugins下的dll里，所以扫描不到。此时需要修改burst package相关的代码，具体如何修改就不贴了，很简单。
总结
踩了不少坑，也对unity的编译环节有所了解。切换过来后，感觉是一种新的体验，有兴趣的可以试试。