分类原则

LincZero大约 3 分钟

个人总结原则

个人总结出来的一些原则，能够帮助更好的分类。必须遵守tag的需要严格遵守，否则建议遵守

不要提前分类。在东西还不多时不要提前分类，东西多了再分类。借用程序里的一句话就是 ”过早的优化是万恶之源“。哪怕后期需要重构 (只要重构及时)，也不会比一开始做很多优化多浪费太多的东西
不要过度分类。分类是为了提高效率，而不是为了你在这上面消耗精力
非归档工程不用太分类。从使用和存放角度上。工作区里简单分分就得了，工作区里同一时间使用的项目一般不会超过20个，如果太多了，就说明该归档了。工作区里如果像归档区分得那么详细，提高了项目深度，反而降低工作效率
归档保证项目完整性。从使用角度上。一个项目不要东一块西一块，要求别人拿到一个压缩包/文件夹后，可以继续完成里面的内容，而无需放在别处的其他素材。东西都绑一块就行了

对于一个新的东西究竟放A里还是B里

优化原则 (必须遵守)
- 例如：有Docs、CodeProject、SourceProject。他们往往并不只是在不同的文件夹那么简单，而是极有可能在存储设备上和管理系统上有所不同！
  Docs可以纯小容量U盘/SD卡放Kindle里看书，大的东西就绝对不能往里放。
  CodeProject可以用Git管理，二进制存储的SourceProject就绝对不能放里面去。
- 例如：一个项目即包含了三维项目、也包含游戏项目。根据优化原则，应该放游戏项目！三维管理软件 (如3D66) 无法管理这个项目，而游戏管理软件肯定是可以管理这个项目的。
包含原则 (必须遵守)
- 如果两个分类是纯包含关系，如Docs和MdDocs，当满足小的肯定是放小的那个（小类可看成是在大类里的一个文件夹的快捷方式，而且此时不用小类岂不是没用了）
优先级原则：规定冲突时的选择优先级，若无规定则再往下看
- 例如：我的Dev里有 Language、Platform、Type 三类，并规定了优先级 Platform > Type > Language。那么只要项目扯到一些跨平台的东西都应该放在多平台里
多人原则：分类到两个文件夹就像分派任务给两个人，且应尽力避免这两个人之间的交流。好好想想清楚他们各自的业务需要什么功能

(难题)

平等类
- 例如：一个项目脑子抽风没做分离，同时有 Java后端、Vue前端。而两部分是无论从什么角度上看都是平等，无重无轻
多类
- 例如：一个项目即包含了三维项目、也包含游戏项目。根据优化原则，应该放游戏项目！三维管理软件 (如3D66) 无法管理这个项目，而游戏管理软件肯定是可以管理这个项目的。
  但此时你无法在三维分类中找到对应的游戏所使用的那个资源。这是单类模式的必然性。
标签

有三大类是指导前几层的分类策略的，这类型通常会被放在分类开始根类里，而不是在很后面才去区分。

至于他们之间的优先级不作硬规定，视具体情况而定。

我觉得这里可以有个专有名词：Big3、ThreeRoot