Blog

Blog

PHODAL

专家 x 抽象 x 类比

多年以前,我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家?怎样才算是技术专家?社交媒体上所谓的 “技术专家”,在某方面(如编程)上的实力一般,也算是专家吗?过去,我并没有细入的思考过这个问题,直到看到一个软件的元模型,以及一本名为《表象与本质》的书,才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。

在这里,便尝试性地做出第一次小结。作为第一次小结,它会存在一系列的不完善的地方,有待于后续进行完善。

所谓的专家嘛,就是在擅长的 “领域”(或者领域中的一个子领域)里,构建了具有范畴化(归类)的概念空间,并可以通过类比灵活地完善自己的概念库。简单来说,就是一个专家能有不同层次的抽象能力,还能以合理的方式(不同的层次)的语言和不同的人进行 “交流”(编程的对话)。

模型:对于现实的抽象

回到我们擅长的编程领域,尝试性地对周遭的空间做一个抽象。诸如于,对我们所处的位置进行建模,以将其作为数据进行存储。在不同的上下文里,这个位置是一个相当迷惑的。比如说,你正在和你的亲人聊天,ta 问你:你现在哪里?不同的人可能有不同的回答:

  • 住在一起的家属,答案可能是:客厅。可能让你去拿个快递。
  • 出差时:某某市。不需要详细的信息。
  • 市内外出:xx 商城。

仅从交流的层面来说,这个问题就相当的令人头大。

对位置进行建模

而回到代码在,在不同的业务领域里,在对于这个位置建模时,这个位置可能是:

  • 一个 GEO 坐标。它只包含:longitude、latitude 两个属性。软件想获取当前的位置,以推荐一些相关的广告信息。
  • 一个房间内的位置。它可能是:卧室(次卧、主卧)、室厅、厨房等。软件在寻找匹配的智能(障)音箱,并及时响应你的请求。
  • 一个建筑位内的位置。它可能是:地下一层、地下二层、一楼、地面等。软件在寻找合适的位置,以找到合适的人将快递放到你手里。
  • 一个城市的某个位置。它可能是:xx 区 xx 街道 xx 小区等。软件在寻找你的准确位置,以便判断你是否在封控区内。
  • 一个国家的某个省某个市。它可能是:中国福建省厦门市。软件需要大致的位置,以便计算合理的快递价格。

位置在不同的上下文、不同的人眼里,可能造成非常大的二义性。而以协作的方式构建出这个模型,则可以有效地减少这种二义性的发生(PS:这也就是为什么协作调模型会受到欢迎的原因)。如果只考虑通过 IP 上门查表的情况下,只需要类似于百度这样的 API 结果:

{  
    address: "CN|北京|北京|None|CHINANET|1|None",    #详细地址信息  
    content:    #结构信息  
    {  
        address: "北京市",    #简要地址信息  
        address_detail:    #结构化地址信息  
        {  
            city: "北京市",    #城市  
            city_code: 131,    #百度城市代码  
            province: "北京市",    #省份      
        },  
        point:    #当前城市中心点  
        {  
            x: "116.39564504",    #当前城市中心点经度
            y: "39.92998578"    #当前城市中心点纬度
        }  
    },  
    status: 0    #结果状态返回码  
}

所以,在掌握上述的分类的情况下,我们能算是地理位置方面的专家吗?

新的抽象概念:行政区与行政区划分

我觉得我不是,比如说,按专业(维基百科上,对于 行政区划 的定义来说)来说,省这一级应该算是一级行政区:所以,我们有 34 个省级行政区,包括23个省、5个自治区、4个直辖市、2个特别行政区。在中国的上下文下,我们相当于只概括了其中的一类类型,基于这种模型建模,会出现中国北京北京市的情形。

而,现在这样的位置模型放到俄罗斯联邦的情况下,它又有问题了,会出现俄罗斯 - 北高加索联邦管区- 车臣共和国,再往下才是行政区。如此类推,就当前来说,我们能掌握好地球上的主要行政划分。而像英国这种包括殖民地的国家,还有群岛 - 教区这样的概念。放到地球 🌍 这个上下文下,这个问题就更复杂了。

所以,在中文的维基百科上,这个层级就变成了:

  • 一层行政区
  • 二层行政区
  • 三层行政区
  • 四层行政区
  • 五层行政区

然后,每个国家就可以获取自己有几级的位置,以及有对应的名称,完美。

然而,由于我们原先已经有一套系统了,为了更好的类比于原来的位置信息,API 可能返回相同的结果,但是解释就变成了如下的形式:

Country Name:
State/Province:
District/County:
City:

这个外国人写的模型又相当的令人头大,District/County 变得相当的诡异。所以,这就是考验一个专家能力的时候了。

在这时,与 State 进行了类比,也都抽象都到一级行政区,对于我们这些普通人来说好理解多了 \~。从编程的角度来说,一层行政区这个名称相当的不好,鬼知道它对应的是啥。

抽象:用再简单的方式解决问题

抽象的有趣之处在于,当你有了更高一次的抽象时,解决问题的方式将变得非常简单 —— 但是,它是有成本的。

从抽象的过程来看,其实可以分为多种分类方式及其抽象,每个维度面向的是不同发展时期的。所以,它可能会有:

  • 类比:省市区街道 → 行政区
  • 分类:行政区类比 → 一二三级行政区
  • 元模型:行政区类比/一二三级行政区 → 层级树

只是呢,从编码的角度来看,不同的抽象层次里,它的实施成本差异是巨大的,如提取一个元模型 —— 可以直接考虑按倍数计算。而类比呢,是其中成本最小的一种方式。

全集还是抽象模型?

在实施的时候,当我们构建一个位置模型时,会考虑构建一个位置的全集,这样实施成本是最低的 —— 因为位置相关的属性是有限的,短期内也不可能快速变化。并且,位置信息并不是系统的核心功能所在,并不需要建立过于复杂的元模型。而其它模型,可能是无限的,并且还会大量的无预期增长,比如各类的智能设备。诸如于在 OpenHAB 智能家家居系统,构建的 Location 层次是这样的:

Location:
 - Indoor
    - Building : Garage, House, SummerHouse
    - Floor    : Attic, Basement, GroundFloor, FirstFloor, SecondFloor, ThirdFloor
    - Room     : Bathroom, Bedroom, BoilerRoom, DiningRoom, Entry, FamilyRoom, GuestRoom, Kitchen, LaundryRoom, LivingRoom, Office
    - Corridor 
    - Apartment
 - OutDoor: Carport, Driveway, Garden, Patio, Porch, Terrace

穷举所有可能的家居位置信息,构建一个分类系统和分类机制,来一个新的 Location,可以划到一个合适的位置。所以,如果一个专家,它可以对它们进行抽象,分类,再进行元模型的提取。

在编程模型上,OpenHAB 则提供了一个概念的抽象:Things、Channels、Bindings、Items、Links,其中 Things 是整个系统的一个重要概念,即可以物理添加到系统中的实体。Things 并不一定需要是真实设备,还可以是互联网上的各类资源。从这个定义上来说,它对于可控制的资源进行了定义。而设备也是一种资源,HTTP API 也是一种资源。它相当于是对他们进行了抽象,这也就是 Things 的有意思之处:两个不相关的分类,在具备同一属性时,可以进行抽象。

所以,从编程上来说,提供全集还是抽象模型,取决于它的增长程度。

抽象行为

有了抽象的模型之后,再对模型的行为进行抽象,我们就能得到一个抽象的语言 —— 用来描述模型之间如何进行交互。我们便能得到一套行之有效的 DSL,诸如于 OpenHAB 中的 Rule DSL:

rule "Start wake up light on sunrise"
when
    Channel "astro:sun:home:rise#event" triggered
then
    switch(receivedEvent.getEvent()) {
        case "START": {
            Light.sendCommand(OFF)
        }
    }
end

当我们提升到这一层次来考虑问题时,那么问题就变得非常简单了。甚至于,我们可以结合各类智能(障)语言输入设备,来快速完整各类设备的添加。

元模型:一个类型系统

而在我们引入设备这一概念的时候,我们会发现:我们是在编写一个领域特定的类型系统。在这个类型系统里,我们为这些设备定义了:名称、属性:度量、状态、控制等。诸如于一个客厅的灯,我们在设计它的元模型时,它的名称是:灯。它包含的属性包含了:亮度,高度是一个 Int 类型,所以还需要在模型上存储对应的属性。一个简单的元数据便是(仅为示例):

# Room
name: 灯
location: Indoor::Room::LivingRoom
category: Lightbulb
property: [{ name: 'light', type: Lighting, value: 38 }, { key: 'color', type: ColorItem, value: '#123456'}]

而对于 value 本身的处理,也就是一类的类型,它可以是:Color, Number, Int, Image, Location, DateTime, Switch等。而针对于 Switch 来说,它还归属于 OnOffType,包含了开关相关的状态(State),以及对应的控制命令(Comand)。而 State、Command 本身也是一种 Type。

简单来说,它对归类进行了归类:

  • 一个客厅的灯是一种灯。
  • 灯包含了开关的属性。
  • 开关则包含开关状态和控制开关的属性。

这真是昂贵的抽象成本。大类中包含了小类,小类又包含了细分类型,而类型最后还要用类型系统描述。

构建抽象的成本

回过头来看,我们构建模型的目的又在哪里呢?为了一次次的日常交流,还是为了更好的知识传承?

最后,回到我们跑歪的标题上来,一个理想的专家在精通自己的领域之后,能快速触类旁通。就好比是一个学霸,便是一个 “学习/考试” 方面的 “专家”。


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签