发布于 2022-04-15 09:37:18 8200 举报 这篇文章是《系统架构,复杂系统的产品设计与研发》第二部分。 本文主要围绕 概念,需求与目标三个词展开。 之前第一部分主要围绕涌现,形式和功能三个词阐述。原文参照这里 我认为这六个词是这本书的核心之处,值得关注。 概念什么是概念
概念把功能映射到形式。 概念虽然不是产品/系统的一项属性,却是形式与功能这两项属性之间的一种观念映射。 翻译过来讲,我们给用户描述系统或者产品时,通过概念可以让用户直观的感受到产品最终的样子。 书中特别强调 概念虽然不是产品/系统 的一项属性,但它却是形式与功能这两项属性之间的一种观念映射。 概念不是产品/系统的属性,而形式和功能是。 在我看来由概念到产品的过程就是讲故事,并且实现故事的过程。 概念是表达想法使用的语言之前在一篇博文中说到系统复杂性,文中强调 复杂性就是任何使得软件难于理解和修改的因素 我们说到软件开发,随即想到一些词,像高内聚,低耦合。自顶向下,分而治之。模块化,服务化,都是为了降低软件的复杂度。 复杂性John Ousterhout 教授在《A Philosophy of Software Design》书中提到了一个非常主观的见解: 复杂性就是任何使得软件难于理解和修改的因素 John 教授将它抽象为变更放大(Change amplification)、认知负荷(Cognitive load)与未知的未知(Unknown unknowns)这 3 类 变更放大看似简单的变更需要在许多不同地方进行代码修改 认知负荷认知负荷(Cognitive load)是指开发人员需要多少知识才能完成一项任务。 使用功能性框架时,我们希望它操作简单,部署复杂系统时,我们希望它架构清晰,其实都是降低一项任务所需的成本。 盲目的追求高端技术,设计复杂系统,增加学习与理解成本都属于本末倒置的一种。 未知的未知未知的未知(Unknown unknowns)是指必须修改哪些代码才能完成任务 或者说开发人员必须获得哪些信息才能成功地执行任务 在日常工作中体现在不知道需要修改哪些功能,影响范围在开发之前无法判断。 「复杂性」贯穿整个产品设计与开发周期,降低复杂性是架构师的重要职责之一。 书中有专门一章提到了架构师的角色,减少歧义,制定解决方案,交付结果。 架构师的角色我一直有一个观点,架构师有两个属性 一个是权力,一个是责任。 架构师绝不仅仅是技术资历更高的工程师而已。 读完这本书,结合最近的经历,这句话描述架构师更合适 架构师是构建产品解决方案,并付诸交付的管理者和执行者。 减少歧义某个事件或者状态被解读为不同的含义,就会出现模糊现象 事件的结果不明确或者值得怀疑,会出现不确定,模糊的。 不确定的都是有歧义的。比如项目的参与方,需求方,截止日期等。 其实每天工作交流也就是做这些事。
需求与目标说出你的需求,我们通常说,技术服务于业务。 利益相关者在我看来设计系统之前,有两项需要知道。一项是系统的利益相关者和受益者有哪些。 第二项是需求方描述的需求是什么样的。 软件系统参与者通过交付软件体现价值。利益相关者理论有一个核心原则,认为利益相关者的价值是从交换中得来的。 这个理念与经济学上的一个观点契合
目标目标可以定义为计划完成的事,生产企业想要完成的事 目标是产品系统的一项属性 书中将目标围绕系统问题陈述展开。 通过 To-By-Using 框架(为了-通过-使用)来系统陈述问题。 充分了解了软件系统三个属性,形式,功能,目标之后, 一起看看书中提到的 四步通用产品的开发过程 通用产品的开发过程产品开发过程分为 4 个活动。分别是 构思,设计,实现和运作。 构思:根据市场需求以及目前可供使用的技术决定构建何种产品。 设计:将要实现的东西表达成信息对象 实现:把设计变为现实 运作:运行产品,体现价值,也就是我们通常所说的运营。 之后就是迭代优化升级。 提出概念,确定形式,整理需求和目标,实现功能,展现价值。这就是复杂产品设计与开发的核心路径。 这是一本高屋建瓴的理论书籍,读完这边书,结合实际工作经验,有一种似曾相识的通透感。 原来可以这样理解软件产品。 理论结合实践,两方面都很重要。 总结今天学习到一个观点 分享到这里,作为本文的总结。
软件设计最讲究抽象能力,软件实现就是具象和落地。 厉害的人只讲人性,不讲逻辑,人性会决定他的逻辑 一个人使用 什么逻辑决定于他是什么思维框架。
参考文档 文章分享自微信公众号: |
|