大家好,我是桃翁,一个不止前端的前端工程师。
前几天在一个写作课里学习到一个写作技巧:文章 = 问题 + 答案。
大概就是说当你看到一个话题,想写成文章的时候,可以想一想你针对这个话题会有哪些问题。然后挨个回答一下这个问题,把回答组合一下,就成为一篇文章了。
我发现这个方法跟我有一些文章的方法很像,但是我并没有这样总结出来,而是在写的时候自然而然就这么去设计了。
以这篇用 husky 和 lint-staged 构建代码检查工作流 文章举个例,做一个实战教学,建议看下面的内容的时候先阅读一下这篇文章。
一、提问题
我要介绍的主题是:构建代码检查工作流。
针对这个主题,我想到了几个问题:
“注意:每个人想到的问题不一样,所以写的思路可能也不太一样。 如果想不到什么问题,我这里给到的建议可以提 what、when、why、how 这样的问题,这也是一种写作方法,后面再讲。”
根据以上的思路就可以把大纲列出来。
其实一般可以直接把这些问题当做大纲。
但是我这篇文章后面又考虑到怎么做代码检查东西比较多,只有在知道了最基础的代码检查方法之后,才可能推出要用 husky 和 lint-staged 这样的工具。
所以我最终还是以陈述的方式为大纲,一步一步的引导,最终把把代码检查做成工作流。
所以最终这篇文章的目录大概是这样的。
前言里面回答了什么是代码检查和什么情况下需要用到代码检查。
在最简单的方法这个大纲里就是怎么做代码检查。
最后的三个都是讲怎么把代码检查做成工作流。
三、回答问题
大纲做好了,就开始填内容了。
前言就没什么好说的了,主要是介绍背景,然后引出我们怎么做代码检查。
接下来就写了最简单的方法来做代码检查,再提出了两个问题。
其实这两个问题就是来解决工作流的问题。
下面的两个段落就是来解决这两个问题,看到没有,这又是问题 + 回答的模式,不仅大话题可以引发问题,还可以问题里套问题。
标题:通过 scripts 来解决如果检测工具多,需要多次处理,解决问题 1.
标题:通过 husky(哈士奇)来解决容易遗忘的问题,解决问题 2.
所以整篇文章都是以问题驱动,一步一步引导读者把小问题解决了,最终串起来就把大问题解决了。
总结一下,这种问题 + 回答的写作方式有什么好处:
最后再复盘一下这篇用 husky 和 lint-staged 构建代码检查工作流 我觉得不好的地方: