架构师的核心能力-抽象能力

架构的核心是管理复杂度,架构师的核心能力是抽象能力,什么是抽象能力?抽象能力就是一种化繁为简的能力。何为化繁为简?就是把一种复杂的事情变得简单的能力,比如通过打比喻让别人很容易听明白你说的意思就是一种抽象能力。如何锻炼抽象能力?我觉得有三种方法,第一种是用归纳法找共性,从多个问题中找到共同的问题提炼通用解决方案,去其糟粕取其精华。第二种通过演绎法找关系,从多个问题中找关系,把多个问题串成一个问题,系统化解决问题!第三种是通过归纳法找特性。化繁为简需要不断的思考,不断的看清一件事的本质,这个事的解决方案越容易。

一、通过归纳法找共性

通过归纳法找共性有两种方法,分别是找需求的共性和找信息的共性

1.1 找需求的共性分期作为一个单一产品服务于海量亿级用户和全行业,但是各行业有很多的个性化需求,有限的技术资源不可能解决无限的行业个性化需求,所以必须对问题进行收敛,从一类需求中找到共性问题,找到最大交集然后求解。找需求的共性就是你收到一堆需求,你能分析出共同的需求是什么?比如用户说想吃香蕉、梨子、桔子和苹果等,那么共性的需求就是用户想吃水果。分期有商家贴息、部分贴息、第三方贴息和混合贴息等需求,共性需求就是灵活的贴息模式,然后基于这个共性的需求,推导出我们可以提供的技术服务或技术能力是什么,从而推导出系统架构,再比如各行业都想接入分期,但是都有些个性化的需求,那么我们是不是可以对个性化需求进行分类,提供几种标准的分期组件让各行业快速接入,比如小程序分期组件、H5版分期组件和JS版分期组件等。如果把这个问题再扩展下,作为技术要解决的问题也非常多且复杂,如果找共性需求,对所有技术问题进行收敛的话,可以收敛成三个基本需求,第一个是技术如何给业务带来护城河?第二个是技术如何给业务带来增量?第三个是技术如何保障业务安全运行?再延伸到经济活动,经济活动的本质或者核心需求是人类需求与服务供给的匹配,能交往和交流的人越多,匹配越容易匹配效率越高,人均GDP也越高,也就越富裕。

1.2 找信息的共性领域建模就是一种找信息共性的方法,领域建模首先就是要区分需求里哪些是变化的哪些是不变,把这个领域不变的信息沉淀成领域模型,基于领域模型做架构。分期在各个场景下可能衍生出不同的分期产品,如租房分期、汽车分期、家装分期和电商分期等,但其实共性都是通过组合额度、利率和还款方式等几要素产生不同的分期产品,比如电商分期额度较低、还款期限最长24个月,汽车分期则额度较高、还款期限可达3年。我们学习技术也是一样,所以技术的共性是什么,我觉得是TCP\IP等协议、语言基础、数据结构等基础技术,这些基础技术点你会发现几十年都不会变化。

二、通过演绎法找关系

通过演绎法找关系能让架构师更体系化的看一个问题。通过演绎法找关系可以分为找内部关系和找外部关系两种

2.1 找内部关系内部关系就是找到业务的生命周期和系统内部的主链路,分期业务虽然支持各种场景的个性化需求,但是系统内主链路和生命周期就一个,也很少发生变化,比如分期业务的生命周期是分期创建-分期失败-分期成功-分期支付关闭,他们的关系是从分期支付单创建到支付成功或支付失败,从支付成功到退款,最后到支付关闭。系统内部主流程包括前置鉴权、支付咨询、支付和退款等。找关系的的另外一个作用就是你看到一堆需求,你能看出这些需求彼此的关系是什么,通过这些关系去分析未来需求的趋势,是偏分期线下的需求更多,还是偏分期线上的需求更多,为啥是分期线下的需求会逐渐多起来,那么未来是不是要围绕着分期线下进行架构升级,通过对分期未来的趋势的判断做架构升级,把未来很多不确定性的事情变得逐渐有确定性。

2.2 找外部关系外部关系梳理清楚架构的边界,什么做什么不做,什么是本领域的核心服务,这些服务提供给谁使用,我们需要依赖其他领域的核心服务有哪些。为什么理清楚架构边界能够化繁为简?因为架构边界类似一个架构标准,大家遵循统一的标准沟通效率和沟通复杂度就会降低,否则每个需求都要讨论这个功能做在哪个系统?为啥要放在这个系统?我觉得不应该放在这个系统?

三、通过归纳法找特性

找特性首先是通过归纳法先找两个业务的共性,花呗支付和花呗分期都是互联网金融产品,都具备互联网产品属性和金融属性,花呗支付和花呗分期不一样的点就是分期的特性,主要体现在付费模式更多(有用户付息和用户免息),还款方式更多(3期、6期和12期),营销方式更多(全贴息和部分贴息)、以及服务角色更多(服务ISV)。再举一个例子,如果要精通JAVA要学习的内容会非常多,可能花很多时间学习也不一定能精通JAVA语言,投入产出比不高,但是如果想化繁为简就必须先找到JAVA的特性,针对特性进行深入学习,我觉得JAVA的两项特性技术是垃圾回收机制多线程框架,剩下的就和其他语言的特性差不多。大家会发现找特性和找共性是不是存在矛盾,所以在这个过程中需要做取舍,比如是否只满足共性需求不满足个性化需求,我觉得在某些场景下,取的是共性需求舍的是差异化需求,但是也可能在另外一些场景下取的是差异化的需求舍的是共性需求。关键是面对当下的业务,你判断什么当下或者未来最重要的事是什么,可能满足场景个性化需求虽然增加研发成本,但是能给业务带来技术壁垒,或者有没有一种方式能既满足共性需求又能满足部分个性化需求。

四、最后

我发现当解决一个问题的时候一定会带来一个新的问题,因为这个可能会破坏现在维持的一种平衡,要学会无为而治,并不是什么都不做,无为是不违背自然规则,我理解就是尽量少打破平衡,做好取舍维持平衡,不既左既右。比如你在做架构升级的时候,虽然升级完了能很好的满足未来的需求,但是在升级的过程中一个需求可能要同时在新老链路里同时实现,风险和工作量加倍。

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 架构师的核心能力-抽象能力

  1. 暂无评论

  1. 暂无 Trackback

return top