前言
时至今日,大部分前端童鞋对前端的认知还不够深,更多的时候都被困在写业务代码的困局之中。所以当大家聊到前端这个词的时候,可能脑海中出现的就是 React、Vue、Webpack、Vite、组件库等。当谈及 复杂错误场景还原
、前端监控
、唤端
、XX指标体系等
、复杂数据处理能力
等,不少人甚至觉得这些都不属于前端范畴。
那么,回到本文正题。为什么写一份好的技术文章很重要呢?因为对技术人而言写文章是最好的沉淀经验的方式之一。工作中善于总结和挖掘,再将其进行深度沉淀,那你就真的在稳步成长!
切入正题,来看一些评论。
读者的分类
从上诉辣些评论里,你能总结出读者的分类大概 有哪些 吗?
这样一缕,是不是就感觉脑子里似乎懂了什么。
技术文章所具备的特点
- 专业性
- 内容深度不一
- 知识面繁多
- 需要背景依托
- 受众的水平不一
以上就是技术文章之所以 难写 的 客观原因 了。 为了做对比,我们来分析一下非技术类文章。
最近热播的电视剧《雪中悍刀行》,同名小说改编。那就拿它举例。故事梗概用一句话来描述大概就是是:主角从小白成长到最牛皮人物的心路历程。 现在你思考2个问题。
- 假如让你凭借这句话来丰富这个故事,你会怎么做?
- 你觉得那些人为什么会追剧?
如果你是作者,你大概不会取“雪中悍刀行”这个名字,因为现在标题党满天飞,凭啥“雪中悍刀行”就吸引人点击了?这又会有人说了,我一听主角是XXX饰演的,我就决定会追这部剧了。
同样的,剧播刚播10集,就有很多人喷,也有很多人捧。但,这都是热度。
话题切回来,总结一下,为什么这种虚幻类的小说就辣么受大众欢迎?
- 不需要专业性。都虚幻了,还要什么专业?
- 内容深度不存在问题。人家几十集的内容,什么内容播不完?
- 知识面也不存在问题。从0开始虚构总比从1开始解释容易。
- 故事背景去靠编剧编。
- 受众?10岁能看,50岁也能看吧?
所以,不管怎样,直接给你总结:我认为技术人写技术文章有3个目的。
巩固/完善自己的知识体系
让读者获得有效的知识
- 收获点赞、评论、粉丝 (提升影响力的直接表现)
如果说:
小说当中的故事背景 -> 业务背景
人物的丰满程度 -> 技术知识点的适用度
受众 -> 精准定位你的读者受众
然后你只需要满足了这一类人,是不是就算你成功了?
了解后,我们开始尝试写一篇技术文章
想好要写什么内容后,我们首先要来取个名字。那拿个什么样的例子来举例说明呢?
就拿 「 前端性能监控」
来分析。
开始了,我们从一个好的标题开始
我们来尝试着写几个标题瞅瞅。
- 《阿里淘系前端性能监控实践》
- 《千万PV商城的前端性能监控方案》
- 《年终终极KPI —— 前端性能监控的实践》
- 《原来各大厂子都是这样做前端性能监控的》
第一个标题,中规中矩,标题即100%点明了主题; 第二个,加了个主语(商城),主语又用了个副词(千万PV)来描述,给人一种“哇,好像很厉害,点进去看看”这种引导式心理暗示; 第三个和第二类似,只不过看起来走的路线可能不一样,KPI嘛,想引起读者少部分的共鸣; 第四个就是直接的兴趣暗示了,稍微有点标题党的嫌疑;
毫无疑问,这类标题都能用,但都需要你的内容能撑得住标题。 所以,我们总结一下写文章标题的注意事项。
- 必须点出你的主题
- 可以适当搞点标题党的嫌疑,但不能真的是标题党
- 理论上,技术文章的标题越短越好。
开始构思你要写的内容
这是个把你肚子里的货转换成你笔下文字的过程。 前者读者只有你,后者读者除了你。( 依旧就拿「 前端性能监控 」
来举例分析 。)
问题来了: 你觉得你在 「前端性能监控」
沉淀到了哪种程度?
-
level - 0 : 网络 上大家都知道的手段。 例如定几个常见指标,肯定有很多人不知道具体要怎么做,但绝大多数人都听过。
-
level - 1 :初步形成知识体系。 例如如何进行监控 指标的选取、系统架构、关键技术的调研过程并最终决策处理等等。 到达这一层,就开始往高级/资深方向走了。 那么如果你恰好停留在这一层,那就要先思考两件事情
- 文章受众就是处于 高级/资深 进阶 阶段的读者。
- 你如何能留下受众读者。
- 是否能启发水平尚且不足的读者
-
level - 2: 实战案例。 这层理解就简单多了。 例如你做了一次双十一项目,非常清楚业务背景、业务瓶颈,以及技术瓶颈。你做的前端性能监控 达成了什么样的目的 。 在此,你突破的东西就是含金量最高的知识财富。那么在着一层,你要考虑3件事情。
- 文章受众就是处于 高级/资深/专家 进阶 阶段的读者。
- 你如何能留下高于你水平的读者。
- 你如何能留下水平与你有差距的读者。
-
level - 3: 商业化解决方案 设计 。 这个词可能不是很好理解。 我们知道很多产品背后都是有行业标准的。例如 天猫双十一背后的技术人是如何撑住高并发量冲击,争对IOS、Android用户又是如何做的页面性能调优,蚂蚁的风险防是如何做的。 控个方式来理解,假如现在某家公司要聘用你去他们那支撑大促业务,你觉得你会设计一个怎样的方案能实施并且落地,最终达成老板要求的目标。 那么到了这一层,你只需要考虑一件事情。
如何尽量提升你的文笔。
因为你要是能写清楚,不管小白还是大佬都能不费力的看懂,你就真的成功了。实话讲,以我的经验,爆款文无一不是文笔牛逼。看你的文章就跟看小说一样,不仅学到了东西,还体验了一把高潮。
所以,你觉得你这篇文章打算写到哪种程度? 先思考,你掌握的某个领域的知识能否顺利的落笔。 想清楚,再落笔。
那问题又来了:我咋知道我能写到哪种程度呢?
依旧就拿「 前端性能监控 」来举例分析哈!我们来尝试列个思维导图
知识点…… 额,暂时列这么多。(毕竟只是个示例)
到这,你需要思考3个问题。
- 在不泄露公司XX的情况下,能否构成一份商业化的解决方案?
- 如果无法构成,那就假装构成。
- 请注意受众
思考清楚了,这里要敲黑板!所有技术文章都有个最大的通病:通篇技术累牍。
啥意思?知识点的思维导图都清晰的列出来了,那照着写呗。我们来mock一下:
标题:千万PV商城的前端性能监控方案
前言: 说明一下目的。
- 监控 指标的选取
介绍一下fmp 、fcp、…… 的含义,解释一下为什么选取它。
- 系统架构
- 描述一下 SDK 的作用
- 用到的日志云存储服务
- 处理数据的后端服务
- 数据报表,最终可视化方案
- 相关技术调研以及思考
- 感谢 & 不足 & 未来发展思考
文章写完了,你自己瞅瞅,如果你是读者,你得是什么样的读者才能通篇认真看完,并且真切感觉自己学到了东西?
所以,你觉得这篇文章的影响力能有多大? 你能通过这篇文章收获多少粉丝?
那新的问题又来了:那该怎么写?
先针对上诉mock内容做几点建议:
- 一定要交待全文背景
- 非常重要的词汇请尽量用业务背景和实际困难点去描述
- 遇到不重要的专业素语/名词 较多的时候,请用尽量短的话去介绍。
- 不要贴过于复杂的代码,但贴出去的代码一定要容易被读者读懂。(过于复杂,请在文末留下你的github 链接)
- 学会制造矛盾,适当使用写作手法。
根据这1、2、3,我们重新mock一次。
标题:千万PV商城的前端性能监控方案
前言
本文内容描述的是在大促季节(618,双十一…… 等)的背景下,为了支撑庞大的业务,我们团队针对前端性能监控 做出的一些优化以及重构的技术方案。欢迎新老童鞋前来食用!
- 监控 指标的选取
实际的大促场景下,业界最为在乎的就是 质量 和稳定性。 用户在尽可能短的时间里进入到大促会场的同时,我们希望尽可能少的出现异常。噢,也就是业界常提到的两个概念:秒开率 、 异常率 。
虽然目标是清晰了,但做过大促的人都知道,这些性能指标的计算成本是不能被忽视的。除此之外,适用性和具体的实用价值也算是能轻易卡住喉咙的存在。咱即使抛开技术不谈,能不能让老板满意……
好的。话说多了,别喷。
重新回到正题,我们在对以上提及的一系列问题点不断的进行了评估,并最终选取出以下指标:
介绍一下fmp 、fcp、…… 的含义,解释一下为什么选取它。
- 系统架构
- 描述一下 SDK 的作用
先逐一介绍一些比较核心的东西。
首先,你得有一个SDK。它的功能主要分两块:采集数据,以及上报数据。 这里,比较麻烦的当是一些持续性描述指标。例如:卡顿。 其实卡顿这词最多只能算是一种现象描述,具体的采集方法大致如下。
/*
利用 requestAnimationFrame 在一秒内执行 60 次(在不卡顿的情况下)这一点,
假设页面加载用时 X ms,这期间 requestAnimationFrame 执行了 N 次,
则帧率为1000* N/X,也就是FPS。
*/
/*但不同户客户端差异很大,需要考虑兼容性。
在这里我们定义 fpsCompatibility 表示兼容性方面的处理,在浏览器不支持
requestAnimationFrame 时,利用 setTimeout 来模拟实现。
在 fpsLoop 里面完成 FPS 的计算。
最后通过遍历 fpsList 来判断是否连续三次 fps 小于20。
*/
const fpsCompatibility = function () {
return (
window.requestAnimationFrame ||
window.webkitRequestAnimationFrame ||
function (callback) {
window.setTimeout(callback, 1000 / 60);
}
);
}();
const fpsConfig = {
lastTime: performance.now(), // performance 是一个浏览器提供的API
lastFameTime: performance.now(),
frame: 0
}
const fpsList = [];
const fpsLoop = function () {
const first = performance.now();
const diff = (first - fpsConfig.lastFameTime);
fpsConfig.lastFameTime = first;
const fps = Math.round(1000 / diff);
fpsConfig.frame = fpsConfig.frame + 1;
if (first > 1000 + fpsConfig.lastTime) {
const fps = Math.round((fpsConfig.frame * 1000) / (first - fpsConfig.lastTime));
fpsList.push(fps);
console.log(`time: ${new Date()} fps is:`, fps);
fpsConfig.frame = 0;
fpsConfig.lastTime = first;
};
fpsCompatibility(fpsLoop);
}
fpsLoop();
function checkFPS(fpsList, below = 20, last = 3) {
let count = 0;
for (let i = 0; i < fpsList.length; i++) {
if (fpsList[i] && fpsList[i] < below) {
count++;
} else {
count = 0
}
if (count >= last) {
return true
}
}
return false
}
checkFPS(fpsList);
// 如果连续判断 3次 FPS 都小于20,就认为是卡顿。
复制代码
(同理,书写其它的一些内容)
……
采集完数据,自然还得上报,要上报就得考虑真实的用户所处环境。我讲极端点,用户跑十万大山里旅游去了,彻底断网了可咋办?业务方希望你能对新增的一种业务场景进行定制化监控,你又要咋办? 最过分的是,总有刁民在一些恶劣的场景下把手机搞坏了,然后投诉你页面卡顿咋办?
……
- 用到的日志云存储服务
(什么日志云服务能支撑你 千万PV? 解释一下)
……
- 处理数据的后端服务
对已存储的日志进行数据处理,筛查、去重等,然后将处理好的数据存入DB数据库。同时,还得再次基础之上为数据报表可视化提供查询数据的接口。
(思维导图的内容加以叙述。千万PV,不遇到个数据高并发的问题,说不过去吧?)
……
- 数据报表,最终可视化方案
(可以展示一下大盘监控曲线,如果你还可以,你还能留一个悬念:下期具体介绍你们的可视化是怎么做的)
- 相关技术调研以及思考
(不要新开段落专门叙述,请将此融入具体情境,写在2里面。)
- 感谢 & 不足 & 未来发展思考
……
好的。。。 文章初步mock完毕。 此时你回头对比一下你就会发现: 其实内容都一样,但你可能更愿意看哪一种?
小结一下
技术文章通病:
- 晦涩难懂,自带劝退效果
- 排版不好,导致阅读感差
- 篇幅长,知识点枯燥。
- 交待不清楚读者能从你这收获哪些
总结一下我个人的写文观念。
- 技术文章首先是文章,最重要的是读者。
- 技术文章,其中任何叙述都是辅助,目的是为了突出记忆点。能让读者理解、领悟、记得住。
- 写技术文要沉淀,沉淀越深,文章质量就越高。 质量 + 读者交互 = 优质文。