总文档 :文章目录
Github : github.com/black-ant
前言 : 时间2021年4月 , 记录当前的一些想法 , 以待日后自审.
2021-04-01 记录
最开始对外发文档大概在4年前 , 当时是在CSDN , 当时为了避免 点开等于我看了 , 收藏等于我学了 , 所以要把学过的东西整合起来发布 , 来填补心中自我迷茫的窘境 .
但是发着发着 ,陷入了第一次迷茫 , 作为一名初级程序员 , 还是一名岗位是全栈的初级程序员 , 发的东西和大杂烩一样 , 什么东西都有 ,而什么都不精 .
现在看来, 还都标着原创 , 真的臊得慌~~~~
陆陆续续写了一年多 , 也就停下来了 , 还记得当时的想法有好几个 :
- 没啥深度 , 写来写去就是那些
- 太基础 , 网上一查一大片 , 写的还比自己好
- 写完除了让我以后查找方便 , 没啥大用处
还有其他的也没记下来 , 要是记下来 , 应该对此时的迷茫能起一些帮助吧 .
2021-04-03 记录
从开始工作以来 , 反而有了记笔记的习惯 .一直以来我记笔记的原则都是 :无论多久 , 我都能通过笔记在短时间实现这个功能 ,了解这个要点 , 尽管早期的文章很不好 , 不过它同样达到了这个效果 ,到现在我都能从中捡起一点什么 ,所以 ,这个原则还要保持.
后面发布就停了 , 因为当时想着深入技术 , 不能浮于用法 ,开始笔记本地化 , 开始往 Git 里面塞东西 , 拼命的塞 , 学到什么就塞什么 , 同时因为一些灵感乍现的想法 , 开启了一些开源的项目 , 尽管没人看 , 自认为也没作完 , 不过确实是沉淀技术的好方式 , 因此而度过了其中最迷茫的一段时期 .
到了一个月以前 , 决定继续发布文档 , 主要原因是 :文档太多了 ,太乱了 , typora 确实很适合写Markdown , 但是东西多了也尴尬 . 因此把知识系统化 ,文档化 , 我认为是能解决这个问题的
文档应该有什么特性 ?
- 服务自己 , 提升自己
- 总结知识 , 分享知识 , 记录知识
- 可二次学习 , 减少学习成本
博客也好 , 文档也好 ,其最大的服务者都是自己 . 发布出来 ,除了讲知识共享 , 其目的还在于能在写的时候回忆梳理思路 ,在发布后 , 其他人可以给你指正其中的错误 , 一个能把复杂点讲简单的文档 ,才是好文档.
这两年一直在考虑一个问题 , 如何用文档驱动开发?
我不期望一个常用的操作也好 , 一个框架的搭建也好 ,消耗二次的时间 , 所以我的笔记中会把一个业务的搭建完整的记录下来 , 会把碰到的问题记录下来 , 这样下次我使用 ,就能再最短的时间把环境搭建好 , 在我看来 , 搭环境最烦人了....
但是 , 这也引出了我新得迷茫...
这段时间文档很高产 , 主要的消耗源是这2年的积累 , 写着写着我发现 , 这些积累只解决了我该怎么用 , 源码也好 , 步骤也好 , 我只能通过文档解决我该如何用它 , 它或许可以帮我解决我该怎么传参 , 我哪里是不是搞错了....
但是 ,我认为文档驱动开发还有更多的挖掘空间 , 我期望我的文档能再开发中做到什么?
- 快速找到问题
- 快速实现功能
或者...
- 我该怎么去定制化我的功能?
2021-04-04 记录
我该怎么去定制化我的功能?
写 Security 系列的时候就在想 , 我都已经把源码的流程记下来了 , 我是不是可以把其中可以定制的点记下来 ? 这些记下来了 , 那岂不是以后爽翻天 ? 想怎么作就怎么作 , 想怎么玩就怎么玩?
可是面对了一个问题 , 写不出来 , 因为它会消耗太多的时间和精力 , 而且不一定回有回报 , 可能100个业务点里面 , 也就会碰到一次 , 成本太高了
那么我该如何去实现高效率的分析?
- 基于官方开发文档 -> 补充源码文档 -> 扩展定制文档
- 源码的分析应该是和开发文档走, 由常用的功能 , 去分析常用的扩展定制
- 用伪代码替换真实代码 , 减少代码长度 , 便于二次学习
- 但是这样记录的文档会遗漏细节 , 是否合适?
- 使用本地的那一套标记 ,同时配合源码 ?
- 标记方式表达流程 , 源码展现细节
- (可以试试)
文档里面还要什么?
- 流程图 : 插件 Seqence Diagrams
- UML 类图 : IDEA -> Diagrams -> show
总结 :
基本上思路就清楚了 , 后续要试试这些模式 , 看看能不能让自己的文档水平再次提高.
留此文档作日后点评 , 学海无涯 , 勿忘初心.
自创标记语言记录
I 实现接口
E 实现抽象类
C 类
SC 内部静态类
PC 普通内部类
PVC 私有内部类
PUC 公共内部类
IC 内部接口
F 属性
SF 静态属性
MC 构造函数
SM 静态方法
M 方法
P 参数
S 静态代码块
B- 逻辑boolean 判断(B->)
FOR-
Else- else 逻辑
// ELSE-
// E-
- 正常逻辑
- 1 有序运行逻辑
-> 内部运行逻辑 (方法内)
? 对上一句的作用解释
= 赋值操作
(param) 使用操作
// 案例 :
C- DefaultResourceLoader
MC- DefaultResourceLoader
- ClassUtils.getDefaultClassLoader();
MC- DefaultResourceLoader(@Nullable ClassLoader classLoader)
M- addProtocolResolver(ProtocolResolver) : 自定义的 Resolver 加入 Spring 体系
M- getResource(String location)
- 首先，通过 ProtocolResolver 来加载资源 , 成功返回 Resource
- 其次，以 / 开头，调用 #getResourceByPath() 方法, 返回 ClassPathContextResource 类型的资源
- 再次，以 classpath: 开头，返回 ClassPathResource 类型的资源
- 通过#getClassLoader() 获取当前的 ClassLoader
- 然后，根据是否为文件 URL ，是则返回 FileUrlResource 类型的资源，否则返回 UrlResource 类型的资源
- 最后，返回 ClassPathContextResource 类型的资源
// 要是有人能给我更多灵感就好了~~~
