docs: update and reorganize the project specification document

1. rename "命名规范" to "通用命名规范"
2. adjust the order of naming specification items
3. add code writing specification, pattern style and node reference related content

SPEC.md

@@ -27,14 +27,13 @@
     - Manager/ 管理器，一般要和节点树交互，也可以不交互
       - [T]Manager.gd 类名就是class_name [T]Manager，只能继承Node（或者不继承），不能更深，否则请作为Statemachine
 
-## 命名规范
+## 通用命名规范
 
 1. 对于一切符号，用小驼峰命名法，就是写js用的那种，常量除外，采用全大写
 2. 对于游戏内容[T extends Character|Bullet|Menu|...]，其行为脚本的类名写成“内容名+[T]”，比如角色A的类名就是ACharacter
-3. 对于节点，场景根节点写大驼峰，下面的树写小驼峰
+3. 对于资源文件，用连字符命名
-4. 对于资源文件，用连字符命名
+4. 对于脚本文件，大多数情况下可以直接写类名，但是游戏内容`[N][T]`也可以写成N.gd
-5. 对于脚本文件，大多数情况下可以直接写类名，但是游戏内容`[N][T]`也可以写成N.gd
+5. 对于着色器文件，用小驼峰写清楚实现的特效是什么
-6. 对于着色器文件，用小驼峰写清楚实现的特效是什么
 
 ## 代码排序规范
 
@@ -67,6 +66,30 @@
 空行
 5. 方法
 
+## 代码编写规范
+
+1. 必须用静态类型声明，禁止动态类型或者是用`:=`的语法糖
+2. 少用`as`，如果你是已经确定一个对象的类型，但是编译器推不出来直接用if is，除非是编译器推断错了再用as
+3. 对于节点名字或者Signal的名字，可以用`StirngName`特化性能，比直接用`Stirng`好一点
+4. 缩进用Tab，不要用空格
+
+### 模式风格
+
+1. 对于一个函数有多个返回值通过数组或者字典返回，可以用Pattern Match(match data:[var a,var b])来解构，就可以少一点变量了
+2. 保持函数的纯度，尽量多写纯函数，少点副作用
+3. 解耦，这个很好理解，就是把数据逻辑和UI逻辑分离开之类的
+
+## 关于节点
+
+### 引用
+
+**注意**：我这里指的是狭义的`Node.get_node`方法或者`$`的速记写法。
+
+- 节点的命名规范：**场景根节点用大驼峰，下面的树用小驼峰，虽然可以用中文和连字符以及一些乱七八糟的其他字符，但是最好还是不要出现，就用英文字母+数字**。
+- 在脚本里获取节点
+  - 场景里原本就有的，仅唯一的节点，请给一个unique id，不要在@onready时用绝对路径获取，就是写成@onready var colorRect: ColorRect = $%colorRect
+  - 对于要出现很多次的节点，比如角色，那就不用unique id了，直接get_node
+
 ## Best Practice
 
 1. 所有直接继承Object或者没写继承的类不许去new，要么就继承RefCounted，不然会内存泄漏