专业做网站建设,加盟网站合作,wordpress首页阅读全文,2023来个网站可以看的文章目录 0.引言1.抽象思维2.软件世界中的抽象2.1 命名抽象2.2 分层抽象2.3 原则抽象 3. 经典抽象案例3.1 方案一#xff1a;战术抽象#xff0c;多快好省#xff0c;跑步前进3.2 方案二#xff1a;深入分析#xff0c;透过表象#xff0c;探寻本质 5. 推荐一本书#x… 文章目录 0.引言1.抽象思维2.软件世界中的抽象2.1 命名抽象2.2 分层抽象2.3 原则抽象 3. 经典抽象案例3.1 方案一战术抽象多快好省跑步前进3.2 方案二深入分析透过表象探寻本质 5. 推荐一本书彩蛋 0.引言
在互联网行业软件工程师面对的产品需求大都是以具象的现实世界事物概念来描述的遵循的是人类世界的自然语言而软件世界里通行的则是机器语言两者间跨度太大需要一座桥梁来联通抽象建模便是打造这座桥梁的关键。基于抽象建模不断地去粗取精从现实世界到业务模型从业务模型到设计模型最终完成现实世界到软件世界的转换。
事实上服务端开发工程师在大部分工作时间里并不是在写代码而是在抽象建模。工程师需将业务需求抽象成领域模型、模块、服务和系统面向对象开发时需抽象出类和对象面向过程开发时抽象出方法和函数。 某种意义上软件的本质就是抽象建模则是系统地实施抽象的过程。作为一种将事物形象化的有效手段建模可将现实世界中的事物及事物之间的关系准确地表达出来。 1.抽象思维
抽象在中文里可作为动词也可作为名词。作为动词的抽象是指一种行为这种行为的结果就是作为名词的抽象。百度百科对抽象的定义为人们在实践的基础上对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作形成概念、判断、推理等思维形式以反映事物的本质和规律的方法。
事实上抽象作为一种高级思维形式与日常生活关系密切例如数字人类初期并没有数字这一概念原始人类或许能够理解三个苹果和三只鸭子但不存在数字 “三” 这个概念在他们的意识里三个苹果和三只鸭子是没有任何联系的。当人类文明发展到一定阶段发现了这两者之间存在的一种共性即 “三”于是就逐渐形成了数字这个概念。此后人们就开始用数字对各类事物进行计数。
2.软件世界中的抽象 软件的本质就是抽象在软件世界里抽象无处不在典型如命名抽象、分层抽象、原则抽象。 2.1 命名抽象
作为一名软件工程师最令你头疼的事情是什么呢是写代码看别人的代码需求评审还是修 BugQuora 和 Ubuntu Forum 曾经针对这个问题进行过广泛地调研结果显示 最令软件工程师头疼的事情是命名没错就是命名应用名、包名、类名、方法名、字段名、变量名等等。如果你不曾为命名苦思冥想、反复权衡也许你还不能算是真正的软件工程师。
关于命名Stack Overflow 的创始人 Joel Spolsky 曾言“起一个好名字很难但这是理所应当的因为一个好名字需要把要义浓缩在一到两个词Creating good names is hard, but it should be hard, because a great name captures essential meaning in just one or two words。” 其实这个浓缩的过程便是抽象的过程。
很多时候业务代码的复杂并非业务本身复杂而是人为因素造成的命名混乱就是最常见的因素。虽然不合理的命名并不影响需求的实现但却加重了认知负荷随着时间的推移理解代码的成本会越来越高。同时命名不合理本质上是抽象不合理往往影响可复用性。
2.2 分层抽象
在软件开发中经常会用到各种分层架构如经典的三层模型展现层、业务逻辑层、数据层和 MVC Model、View、Controller模型。如图 1 所示为阿里广泛采用四层模型它包括 View、Service、Manager、DAO 四部分通过分层将数据访问、通用处理、业务逻辑、终端展示四者解耦各司其职。View 与用户交互Service 依赖多个 Manager 和 DAO 实现具体的业务逻辑Manager 负责通用业务逻辑处理和封装外部服务它是对 Service 层通用能力的下沉注重复用性DAO 负责与底层数据库进行数据交互。分层架构的核心其实就是抽象的分层每一层的抽象只需要而且只能关注本层相关的信息从而简化整个系统的设计。
2.3 原则抽象
在面向对象设计和面向对象编程领域有一个著名的 SOLID单一功能、开闭原则、里氏替换、接口隔离以及依赖反转原则它是由 Robert Martin 在 21 世纪早期提出。在软件设计和开发中正确地遵循这些设计原则有助于提升系统的可维护性和可扩展性。
以依赖倒置原则Dependency Inversion Principle, DIP为例其含义为抽象不应该依赖于细节细节应当依赖于抽象。换言之要针对抽象接口编程而不是针对实现细节编程。这样做有什么好处呢一个软件系统通常可划分为多个层次上层调用下层上层依赖于下层如果上层依赖的是下层的具体实现那么当下层实现细节发生变化时上层往往也需要同步修改这就加重了不同层之间的耦合度。但是如果上层依赖的只是下层的抽象而不是细节就完全不同了抽象变化的频率极低让上层依赖于抽象实现细节也依赖于抽象即使实现细节不断变动只要抽象不变上层就不需要变化如此一来大大降低了耦合度。
Java 的 JDBC 是依赖倒置原则的一个典型应用场景 。如图 2 所示如果没有 JDBC 这一层抽象软件系统将直接依赖具体的数据库如 MySQL、Oracle 等与实现细节耦合当需要切换到另一种数据库时就需要修改大量代码来适应细节的变化。若系统依赖的是抽象的 JDBC 接口那么通过调用 JDBC 即可完成数据库操作而无须再关注 JDBC 背后的数据库因为所有关系型数据库的连接库都实现了 JDBC 接口当需要换数据库时作为抽象的 JDBC 并不会变化系统也就无需感知变化。 3. 经典抽象案例
如图 3 所示有这样一个关于 “霸屏” 动效的需求产品文档Product Requirement DocumentPRD摘要描述如下
ZFB 会员与 KAKey Account 商家合作升级会员等级特权因此在会员频道首页通过 “霸屏” 动效提示用户并引导其进入新等级特权页面
若用户点击 “看我等级特权” 按钮则自动跳转到新等级特权页面引导目标达成“霸屏” 动效不再出现以免打扰用户
若用户未点击 “看我等级特权” 按钮“霸屏” 动效展示 3 秒自动收起。由于引导目标未达成需继续引导同时为了防止过度打扰用户“霸屏” 动效每月最多出现 N 次N 需支持灵活配置。 我们来简单分析一下这个需求核心业务目标在于引导用户进入新等级特权页面同时兼顾用户体验避免 “霸屏” 动效过度打扰用户。对于服务端而言需要实现 “疲劳度” 控制逻辑即
若用户点击按钮持久化用户点击记录当用户再次访问该页面时通过查询点击记录就可以判断该用户是否曾点击按钮。若记录存在则告知前端不要弹出 “霸屏” 动效。
若用户未点击按钮持久化 “霸屏” 动效对用户的曝光记录当用户再次访问该页面时通过查询曝光记录就可以判断该用户是否满足展示 “霸屏” 动效的条件。若当月曝光次数少于 N则告知前端可弹出 “霸屏” 动效。
3.1 方案一战术抽象多快好省跑步前进
基于上面的需求分析稍有经验的服务端开发工程师立马就能想出解决方案如表 1 所示为每个用户落一条记录即可实现需求。
表 1点击、曝光记录模型概要 图片 从实现需求的角度来看上述设计完全可以满足业务当前的需要。如图 4 所示曝光、点击记录模型几乎完全是由产品文档PRD翻译而来乍看之下十分的 “信达雅”简直不要太完美。 图片
图 4 将 PRD 翻译为模型 我们再来仔细分析一下上面的模型真的好么显然很一般该模型局限于实现当前业务需求几乎没有进行抽象建模因此建立的模型不能准确地刻画业务的本质。这样的模型可扩展性极差基本就是一锤子买卖。
在笔者看来直接 “翻译” PRD 是一种战术编程或者说战术抽象。John Ousterhout 在《A Philosophy of Software Design》一书中提到几乎每个软件开发组织都至少有一个将战术编程发挥到极致的开发人员可称之为战术龙卷风Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado。战术龙卷风有以下几个特点。
快速。他们常以腐化系统为代价换取当前最快速的解决方案几乎没有人能比他们更快地完成任务。
高产。他们是高产的程序员代码量极高堪称 “卷王”。
坑多。他们往往倾向于简单地进行功能堆积忽视抽象建模将成本放到未来由后来人买单。
从战术龙卷风的特点可以看出战术编程抽象是缺乏或者说忽视抽象建模和系统设计的聚焦于快速交付系统能用就行注重短期收益而非长期价值。当然这并非完全是软件工程师的问题不合理的评价体系和行业特点亦难辞其咎。
3.2 方案二深入分析透过表象探寻本质
方案一中 “草率” 地进行抽象建模是不可取的于开发者自身而言是一种苟且无能力提升于软件项目而言随意堆积一次性代码将成本放到未来是一种不负责任的行为。
如果我们深入分析业务我们会发现其实有更好的方案而且并不复杂。如图 5 所示首先忽略 PRD 描述中那些无关紧要的细节可以发现PRD 涉及两种场景然后针对两种场景进一步抽取共同特征——场景 S : N 次/周期 Q最后洞见共同特征背后的本质——周期维度记账。 图片 基于【周期维度记账】这一需求本质我们建立的模型不仅可以满足当前业务的需要
用户点击按钮DB 里面落一条记录其中 scene 可设为 “CLICK”。当用户再次进入对应页面时先根据 userId 和 scene 查询记录若存在则说明用户已经点击过按钮告知前端无需展示“霸屏”动效。
用户未点击按钮DB 里面落一条记录其中 scene 可设为 “EXPOSE”。当用户再次进入对应页面时先根据 userId 和 sceneCLICK查询、判断用户是否点击过按钮如果没有点击则根据 userId 和 sceneEXPOSE查询、判断并更新曝光次数 count。
与此同时基于【周期维度记账】这一需求本质我们建立的模型具有更好的可复用性、可扩展性。举两个例子
多周期基于字段 quantum 和 bizDt可以支持终身、年、月、周、日等时间维度记账。满足不同业务场景的需要。
多场景基于字段 scene可以实现不同业务场景的数据隔离同时支持多个场景以及数据分析等附加需求。
抽象并非一蹴而就需要不断假设、验证、完善 如图 6 所示在人类文明早期人们基于直观地观测认为地球是宇宙的中心因此抽象出了 “地心说” 模型。随着时间的推移和观测手段的进步人们观察到的天文现象越来越多逐渐意识到 “地心说” 模型与观测结果存在矛盾于是人们开始对 “地心说” 模型进行修正像极了程序员重构模型典型如 “本轮-均轮” 模型。
然而随着更多的天文现象被发现在 “地心说” 模型的大框架下无论如何修正都无法自圆其说。在 “地心说” 模型统治人类 “天文世界观” 很长一段时间后勇敢的先行者推翻了 “地心说” 模型并提出了在当时看来离经叛道的 “日心说” 模型。 从 “地心说” 模型被提出到 “日心说” 模型被广泛接受跨越了 1400 多年的时间。这一史实表明人们对事物本质的探索是一个过程而非一蹴而就对于服务端开发而言我们对需求的认知也是如此初见之下我们往往很难直接洞见其本质而需要不断假设、反复推演最终才能抽象出较好的模型。
你可能会问——抽象建模如此麻烦开发时间往往又不充裕何必苦苦探寻所谓的本质呢能用不就行了么
如果你确有上述疑问不妨换个角度想一下 “核心竞争力” 的内涵。很多时候我们并不缺乏解决问题的办法、能力和资源而缺乏的是对问题的识别、理解、抽象。当一个问题被抽象为足以刻画业务本质的模型并拆解到软件项目维度的时候面对确定的任务、清晰的目标可以解决问题的人就非常多了。
某种程度上解决问题的能力是重要的基础但若仅仅是解决问题还远远不足以称为核心竞争力。对于服务端开发工程师而言抽象建模能力比编程落地能力更重要因为编程解决问题只是一种普通技能而已而对具象事物如业务需求的高度抽象探索事物的本质需要我们从新的角度审视旧的问题需要有创造性的想象力这才是真正的难点当然也是核心竞争力所在。
最后不要苟且不要应付。我们每一次对事物的深入思考、对表象背后本质的探寻都是一次自我提升。
5. 推荐一本书
PS本文内容节选自业界首部体系化、全景式解读服务端开发的著作——《服务端开发技术、方法与实用解决方案》。 《服务端开发技术、方法与实用解决方案》一书取材自阿里和蚂蚁集团的精品内训课程由资深服务端技术专家、技术讲师、阿里第二届技术讲师课程大赛年度冠军得主、CSDN 博客专家撰写。该书理论与实践结合全景式、体系化地阐述了服务端开发核心内容包括以下两个部分。
第一部分服务端开发的技术和方法
首先介绍服务端开发的职责、技术栈、核心流程和进阶路径然后从需求分析、抽象建模、系统设计、数据设计和非功能性设计 5 个方面展开结合案例深入讲解了服务端开发的实操方法和重难点为读者呈现服务端开发的全景图帮助读者快速、体系化地掌握服务端开发的知识和方法。
第二部分服务端典型问题的解决方案
针对高并发、高性能、高可用、缓存、数据一致性、幂等、秒杀等服务端开发实践中的典型问题给出了对应的解决方案和开发规范同时还结合案例深入分析了不同方案的优缺点。此外还总结了接口设计、日志打印、异常处理、代码编写、代码注释等落地层面的行业案例和规范。
读者对象
IT 从业人员服务端开发工程师、客户端开发工程师、产品经理、测试开发工程师等。
高校学生计算机、软件、自动化、电气、通信等专业有志于进入 IT 行业的在校学生。 目前本书已经在京东、淘宝、当当、拼多多等电商平台发售。在电商 APP 搜索关键词 “服务端开发”、“服务端开发技术”即可搜索到该书。
彩蛋 ⭐ 《阿里后端开发抽象建模经典案例》免费包邮送3本 ⭐活动时间截止到 2023-09-15 20:00:00 ⭐ 抽奖方式利用程序进行抽奖。 ⭐参与方式关注博主、点赞、收藏、评论区进行高质量评论不少于10个字即可参加抽奖活动 ⭐本次活动一共赠3本评论区抽取3位小伙伴免费送出
