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