聊聊写文档配图这事
我愿意给文档配图，尽管文档写的并不怎么样。
提升写文档的认知
以前有个不好的习惯，不喜欢甚至逃避写文档，觉得写文档的 ROI 很低、不值得投入多少时间精力。
不知道从什么时候开始（估计是看到别人写博客、文章都带有简单明了、色彩分明的配图 耳濡目染 了），我对写文档这事的认知逐渐提升了，变得愿意花不少时间写文档、花不少时间给文档配图了。
其中的转变，在于我对写文档的认知提升了：
1. 文档是写给自己看的，只是恰好别人也会看
2. 配图是为了更加直观地表述文档内容
文档是为了更好地诠释代码的前因后果、架构逻辑，毕竟代码只是一段纯粹的代码；如果没有文档描述，很难将代码理解透彻。特别是隐藏在代码背后的业务背景、需求考量、架构设计等，严重阻碍对代码的理解。
纯文字的文档，其实挺枯燥的；未来自己复习起来，也会觉得枯燥无味；更何况对文档内容不怎么了解的读者们。
因此，给文档配以简单明了、色彩分明的图片，能让文档鲜活起来。
比如，在博客 eBPF Talk: trace tailcall 程序？NO！ 里，核心就是那一张图（emm图画的有问题。。），其它文字都是围绕着这张图来讲解为什么 tailcallee 不能被跟踪。
给文档配图心得
看到别人写博客的配图，色彩分明地将各个部分区分开来，便学了过来。
我现在使用 Excalidraw ，是受到陈天老师「“程序人生”公众号作者」的影响。在上手之后，便不愿意再使用 draw.io, ProcessOn 等“枯燥”的画图工具。
在给文档画图时，谨记一点：
不同部分赋予不同的颜色，最好是恰当的颜色。
比如上图，左侧绿色指正常的业务进程，右侧红色指异常的业务进程；想要表述的意思：异常进程 coredump 时尽量降低对正常进程的影响。
以上，与君共勉。
我愿意给文档配图，尽管文档写的并不怎么样。
提升写文档的认知
以前有个不好的习惯，不喜欢甚至逃避写文档，觉得写文档的 ROI 很低、不值得投入多少时间精力。
不知道从什么时候开始（估计是看到别人写博客、文章都带有简单明了、色彩分明的配图 耳濡目染 了），我对写文档这事的认知逐渐提升了，变得愿意花不少时间写文档、花不少时间给文档配图了。
其中的转变，在于我对写文档的认知提升了：
1. 文档是写给自己看的，只是恰好别人也会看
2. 配图是为了更加直观地表述文档内容
文档是为了更好地诠释代码的前因后果、架构逻辑，毕竟代码只是一段纯粹的代码；如果没有文档描述，很难将代码理解透彻。特别是隐藏在代码背后的业务背景、需求考量、架构设计等，严重阻碍对代码的理解。
纯文字的文档，其实挺枯燥的；未来自己复习起来，也会觉得枯燥无味；更何况对文档内容不怎么了解的读者们。
因此，给文档配以简单明了、色彩分明的图片，能让文档鲜活起来。
比如，在博客 eBPF Talk: trace tailcall 程序？NO！ 里，核心就是那一张图（emm图画的有问题。。），其它文字都是围绕着这张图来讲解为什么 tailcallee 不能被跟踪。
给文档配图心得
看到别人写博客的配图，色彩分明地将各个部分区分开来，便学了过来。
我现在使用 Excalidraw ，是受到陈天老师「“程序人生”公众号作者」的影响。在上手之后，便不愿意再使用 draw.io, ProcessOn 等“枯燥”的画图工具。
在给文档画图时，谨记一点：
不同部分赋予不同的颜色，最好是恰当的颜色。
比如上图，左侧绿色指正常的业务进程，右侧红色指异常的业务进程；想要表述的意思：异常进程 coredump 时尽量降低对正常进程的影响。
以上，与君共勉。