大家好,我卡颂。
最近,有个朋友出了门「前端状态管理」的课程。他的本意是想走我的路:
但课程反响平平,所以来咨询我的建议。
这篇文章是我给这位朋友的回答,同时也适合希望「靠写作建立影响力」的同学阅读。
上述「靠内容积累影响力,再靠影响力积累粉丝,最后为粉丝提供付费服务」路径的本质是「圈层生意」。
所谓「圈层生意」,就是长期经营一个围绕你的圈子,做好圈友的关系维护。圈友与你产生长期信任关系,基于这层信任关系为你的服务买单。
所以,圈层生意的根基是「信任」。当你活出一种让人向往的状态,其他人因为羡慕你的状态,关注你,靠近你,向你学习,这个过程就会产生信任。
对于程序员(或其他技术人士),如果你能让人产生「这个人在我关注的领域真的很在行」的感觉,就给了他一个关注你、靠近你、向你学习的理由。
很多人认为「在某一领域很在行」意味着你必须在该领域钻研的很深,其实并不是这样的。你只需要做到如下2点就行:
高一个抽象层级
的理解同一抽象层级
的理解即「目标领域追求深一级的理解,相关领域追求广泛(但不深)的理解」,而不是大家通常认为的「只追求在目标领域有深几级的理解」。
以我朋友的前端状态管理课举例,他当前的课程内容是:
让我们重新规划下课程内容,先看第一点 —— 纵向:在目标领域有比受众高一个抽象层级的理解。
比「状态管理」高一级的抽象是「前端业务开发」,从「前端业务开发」出发,可以从如下角度展开:
比如,从面向过程(用jQuery
)到声明式开发(用前端框架)过程中,状态管理为了适应开发模式的变化,是如何变化的?
比如,Facebook
为了应对自身应用的复杂性,提出了Flux状态管理架构
。
Dan
发现当应用复杂度进一步提升时,加强单向数据流的约束
能简化业务开发模式,于是在Flux
基础上提出了Redux状态管理架构
。
比如,对于以下三类业务逻辑:
虽然他们在前端都表现为状态,但由于各自逻辑不同(比如缓存需要考虑过期时间),需要被区别对待。
综上,我们会发现,当从事物(这里的状态管理
)的上一层抽象(这里的前端业务开发
)出发来观察事物,会获得更深的洞察。
甚至,有些问题必须从更高的抽象层级出发才能得到答案的。比如「状态管理的技术选型」 —— 业务的技术选型是因
,状态管理选型是果
,所以这个问题只能从业务层面出发。
再来看第二点 —— 横向:在其他相关领域有和受众同一抽象层级的理解。
和状态管理同抽象层级的事物有很多,比如:
Vue
、React
)的业务开发:可以聊在Vue
、React
等不同框架中状态管理的区别,以及造成这些区别的原因CSS
中变量的状态管理发现了么,经由横向、纵向扩展后,「状态管理」不再独立存在,而是延伸出一套知识体系,这套知识体系:
当读者以后遇到与状态管理相关的问题
,都能从这套知识体系中寻求答案。
反观之前的课程结构,既然我项目中使用的状态管理库已经够用了,有什么理由再去学其他状态管理库呢?
「靠写作建立影响力的底层原理」可以分为三步:
但是,对很多人来说,即使了解上述三个步骤,也无法靠写作构建目标领域的知识体系,因为写作的卡点通常不在于具体的写作技法,而在于:
所以,「靠写作建立影响力的底层原理」的源头是「知识管理」。这又是个宏大的话题,如果大家感兴趣可以点个赞,赞多的话我再开新的文章聊~