前言写C/C的时候大家都知道头文件分两种系统标准头文件还有我们自己写的头文件。不光CJava、Python、JS都可以套用这个思路。很多人到这里就止步了但我自己平时写项目会把我们自己写的代码再拆成两类业务专用代码 和 通用公共代码。而且这里面有几个很有意思的类比甚至还碰到过一个真实场景刚好对应编程里的悬空引用Dangling Reference今天随便聊聊我的这套理解。一、传统划分标准库 vs 自己写的代码拿C/C头文件举例系统/标准库头文件比如stdio.h、vector语言自带。Java的JDK、Python内置库、JS原生API都属于这一类。特点完全通用和业务没关系拿来就能用。自己写的代码项目里的头文件、类、模块。重点来了自己写的这部分还可以继续拆分二、自研代码分成两类业务专用 和 公共通用1业务专用代码专门服务某一个项目、某一套业务。比如订单结构体、业务状态枚举只有当前这个项目才看得懂。特点绑定业务换个项目基本没法直接拿去用需求一变就要改项目下线了这块代码也就跟着废弃生命周期完全跟着项目走只能放在当前项目目录里面不能放到上层给别的项目引用2公共通用代码不和任何业务挂钩就是纯粹的工具。日志封装、字符串处理、时间工具这类。特点里面没有任何业务名词不依赖业务逻辑改动很少很稳定多个项目都可以复用生命周期独立就算某个业务项目删掉了这部分代码还能继续用我给这个公共代码文件夹起名叫static。不是说里面全是C static关键字的变量我取的含义是稳定、静止很少改动。放在所有业务项目的同级甚至上一级目录多个项目一起引用。三、好玩的类比static目录 ≈ C静态成员这个比喻是我自己琢磨出来的感觉特别贴切每一个业务项目就像是new出来的一个实例。业务专用代码就是实例的成员变量。实例销毁成员就没了。static公共目录就像是类的静态成员。它不属于任何一个单独实例是所有实例共享的一份。不管新增多少业务项目都是共用这一份static底座。单个项目下线不会影响它。还有一个巧合Windows网络设置里也有公用网络、专用网络。专用网络家里局域网专属环境对应业务专用代码公用网络咖啡馆公共WiFi大家共用的基础设施对应static公共底座当然两者侧重点不一样Windows是区分访问权限代码这边是区分复用范围和生命周期。只是刚好可以拿来辅助理解。一条铁律业务代码可以依赖static公共库但是static里面绝对不能引入任何业务头文件。一旦反向依赖公共库就绑定业务不再通用了。目录结构大概长这样workspace/ ├─ static/ # 全局公共底座跨项目复用很少改动 │ ├─ log.hpp │ ├─ string_util.hpp │ └─ time.hpp ├─ project_order/ # 订单业务项目 │ └─ biz/ # 订单专属业务头文件、结构体 └─ project_goods/ # 商品业务项目 └─ biz/ # 商品业务代码四、真实踩坑案例活生生的 Dangling Reference悬空引用之前遇到一件挺搞笑的事。有个业务项目快要做完了项目里面一份业务专用头文件基本没人使用了。既然没人用我就在这份头文件上面随便折腾东改西改用来做自己的测试研究肯定不能放到正式环境。结果别的同事想拿这个头文件过去用这不就是典型的悬空引用吗这个头文件本身就属于这个业务项目的实例资源生命周期快要结束相当于一块马上要free掉的内存。别人还拿着引用打算继续使用。而且我还在这块“内存”上随便修改。就算现在文件还在仓库里看着能打开但是内容已经被我随便改动了。拿过去编译就算能过后续原项目下线删掉文件直接炸。很多人误以为文件还在仓库里就是稳定可用的代码。忽略了它绑定的业务上下文和生命周期。一句话总结业务私有代码生命周期跟着项目走。项目快要下线这块代码就属于濒危资源严禁别的项目拿来引用。五、最后总结三层结构语言标准库 全局公共底座(static) 项目业务代码只能单向依赖。业务代码属于实例独有公共底座属于全局共享类比类static成员。公共库一旦引入业务代码就废掉了失去复用价值。不要去引用别的项目里快要废弃的业务代码本质就是悬空引用埋大坑。这个分层思路不局限C/CJava、Python、JS都可以套用。小项目可能感受不到多项目共存的时候边界一旦乱掉后面维护会非常痛苦。讨论区你们项目里公共工具目录一般叫什么common、base、utils还是别的有没有碰到过有人把业务逻辑塞进公共工具库导致公共代码被业务污染的情况欢迎一起聊聊踩过的坑。
前言写C/C的时候大家都知道头文件分两种系统标准头文件还有我们自己写的头文件。不光CJava、Python、JS都可以套用这个思路。很多人到这里就止步了但我自己平时写项目会把我们自己写的代码再拆成两类业务专用代码 和 通用公共代码。而且这里面有几个很有意思的类比甚至还碰到过一个真实场景刚好对应编程里的悬空引用Dangling Reference今天随便聊聊我的这套理解。一、传统划分标准库 vs 自己写的代码拿C/C头文件举例系统/标准库头文件比如stdio.h、vector语言自带。Java的JDK、Python内置库、JS原生API都属于这一类。特点完全通用和业务没关系拿来就能用。自己写的代码项目里的头文件、类、模块。重点来了自己写的这部分还可以继续拆分二、自研代码分成两类业务专用 和 公共通用1业务专用代码专门服务某一个项目、某一套业务。比如订单结构体、业务状态枚举只有当前这个项目才看得懂。特点绑定业务换个项目基本没法直接拿去用需求一变就要改项目下线了这块代码也就跟着废弃生命周期完全跟着项目走只能放在当前项目目录里面不能放到上层给别的项目引用2公共通用代码不和任何业务挂钩就是纯粹的工具。日志封装、字符串处理、时间工具这类。特点里面没有任何业务名词不依赖业务逻辑改动很少很稳定多个项目都可以复用生命周期独立就算某个业务项目删掉了这部分代码还能继续用我给这个公共代码文件夹起名叫static。不是说里面全是C static关键字的变量我取的含义是稳定、静止很少改动。放在所有业务项目的同级甚至上一级目录多个项目一起引用。三、好玩的类比static目录 ≈ C静态成员这个比喻是我自己琢磨出来的感觉特别贴切每一个业务项目就像是new出来的一个实例。业务专用代码就是实例的成员变量。实例销毁成员就没了。static公共目录就像是类的静态成员。它不属于任何一个单独实例是所有实例共享的一份。不管新增多少业务项目都是共用这一份static底座。单个项目下线不会影响它。还有一个巧合Windows网络设置里也有公用网络、专用网络。专用网络家里局域网专属环境对应业务专用代码公用网络咖啡馆公共WiFi大家共用的基础设施对应static公共底座当然两者侧重点不一样Windows是区分访问权限代码这边是区分复用范围和生命周期。只是刚好可以拿来辅助理解。一条铁律业务代码可以依赖static公共库但是static里面绝对不能引入任何业务头文件。一旦反向依赖公共库就绑定业务不再通用了。目录结构大概长这样workspace/ ├─ static/ # 全局公共底座跨项目复用很少改动 │ ├─ log.hpp │ ├─ string_util.hpp │ └─ time.hpp ├─ project_order/ # 订单业务项目 │ └─ biz/ # 订单专属业务头文件、结构体 └─ project_goods/ # 商品业务项目 └─ biz/ # 商品业务代码四、真实踩坑案例活生生的 Dangling Reference悬空引用之前遇到一件挺搞笑的事。有个业务项目快要做完了项目里面一份业务专用头文件基本没人使用了。既然没人用我就在这份头文件上面随便折腾东改西改用来做自己的测试研究肯定不能放到正式环境。结果别的同事想拿这个头文件过去用这不就是典型的悬空引用吗这个头文件本身就属于这个业务项目的实例资源生命周期快要结束相当于一块马上要free掉的内存。别人还拿着引用打算继续使用。而且我还在这块“内存”上随便修改。就算现在文件还在仓库里看着能打开但是内容已经被我随便改动了。拿过去编译就算能过后续原项目下线删掉文件直接炸。很多人误以为文件还在仓库里就是稳定可用的代码。忽略了它绑定的业务上下文和生命周期。一句话总结业务私有代码生命周期跟着项目走。项目快要下线这块代码就属于濒危资源严禁别的项目拿来引用。五、最后总结三层结构语言标准库 全局公共底座(static) 项目业务代码只能单向依赖。业务代码属于实例独有公共底座属于全局共享类比类static成员。公共库一旦引入业务代码就废掉了失去复用价值。不要去引用别的项目里快要废弃的业务代码本质就是悬空引用埋大坑。这个分层思路不局限C/CJava、Python、JS都可以套用。小项目可能感受不到多项目共存的时候边界一旦乱掉后面维护会非常痛苦。讨论区你们项目里公共工具目录一般叫什么common、base、utils还是别的有没有碰到过有人把业务逻辑塞进公共工具库导致公共代码被业务污染的情况欢迎一起聊聊踩过的坑。
