导图社区 《简约之美》 软件设计之道
将软件设计作为一门严谨的科学,阐述了开发出优雅简洁的代码所应该遵循的基本原则。作者从为什么以前软件设计没有像数学等学科一样成为一门科学开始入手,道出了软件以及优秀的软件设计的终极目标,并给出了具体的指导规则。
编辑于2022-08-01 11:09:27游戏主机御三家怎么选 | PS5、Switch、Xbox购买攻略 能让你玩起来的游戏机🎮是最推荐的游戏机。Switch 和 XSS 只要2000块就可以玩起来,价格便宜。Switch是掌机,哪里都能玩。有钱当然推荐 PS5,画质好体验好。 游戏机的生命周期一般在7年左右,所以本身还是非常保值的。 希望大家都能找到自己心仪的游戏机,祝大家玩的开心!
我们在实际的工作和学习接触中,会发现一个比较统一的问题,那就是:随着数据在企业生产经营中的广泛应用,我们究竟该如何借助数据分析的能力,去提升公司业务的运营效率,为企业降本增效呢?也就是我们常说的实现真正的数字化,最终达到企业经营模式的转型。那么这个问题,其实根源在于:我们个人如何培养自己的数据思维?
如果说十大必去的城市的话,我就觉得那些把省级行政区(直辖市除外)放进来评论的,不知是不是跑题了!所以按照包括直辖市在内的叫法,我认为排在前两名的肯定是北京和西安。具体的谁靠前就不好说了,反正都差不多。
社区模板帮助中心,点此进入>>
游戏主机御三家怎么选 | PS5、Switch、Xbox购买攻略 能让你玩起来的游戏机🎮是最推荐的游戏机。Switch 和 XSS 只要2000块就可以玩起来,价格便宜。Switch是掌机,哪里都能玩。有钱当然推荐 PS5,画质好体验好。 游戏机的生命周期一般在7年左右,所以本身还是非常保值的。 希望大家都能找到自己心仪的游戏机,祝大家玩的开心!
我们在实际的工作和学习接触中,会发现一个比较统一的问题,那就是:随着数据在企业生产经营中的广泛应用,我们究竟该如何借助数据分析的能力,去提升公司业务的运营效率,为企业降本增效呢?也就是我们常说的实现真正的数字化,最终达到企业经营模式的转型。那么这个问题,其实根源在于:我们个人如何培养自己的数据思维?
如果说十大必去的城市的话,我就觉得那些把省级行政区(直辖市除外)放进来评论的,不知是不是跑题了!所以按照包括直辖市在内的叫法,我认为排在前两名的肯定是北京和西安。具体的谁靠前就不好说了,反正都差不多。
简约之美
引言
计算机出了什么问题
程序写的太糟糕
化繁为简
程序究竟是什么
程序员指令和计算机执行操作的结合体
结果的质量取决于
机器的质量
想法的质量
代码的质量
缺失的科学
设计
定义
v
为创造性活动制定计划
n
为某种创造性活动而制定但尚未实施的计划
业已存在的创造物所遵循的计划
目的
程序代码应采用什么结构
是速度重要,还是容易阅读重要
应选择哪种语言
软件设计
软件系统中任何与架构有关的技术决策,以及在开发系统中所做的技术决策
程序员也是设计师
软件设计的责任应当落实到每个写代码的人身上
必须时时愿意聆听建议和反馈
任何决策都必须由单独的个人而不是一群人做出
软件设计的科学
目前软件设计还不是科学,终究会成为科学
科学
汇总而来的知识
具备某种结构
一般性的事实或基本的规则
应用到现实中
科学方法发现或证明
概念说明
定义:事物是什么,应如何使用
事实:事物的真实陈述
条例:给你的确切建议
规则:永远为真的事实
为什么不存在软件设计科学
软件管理的科学
存在彼此矛盾但各有道理的观点
软件设计的科学
没人关注
软件设计的推动力
全部软件的共同目标
帮助其他人
软件设计科学的目标
确保软件能提供尽可能多的帮助
确保软件能持续提供尽可能多的帮助
设计程序员能尽可能简单地开发和维护的软件系统,才能达到上两个目标
未来
决策
不是要确定绝对的好坏,而是一个排序问题
软件设计的方程式
D=V/E
D:变化的可取程度(迫切性)
V:价值
E:成本
价值
定义
这个变化能带给人多大帮助
依据
开发经验
对用户恰当的研究
组成
可能价值
有多大可能帮到用户
多少用户
发挥频率
潜在价值
为用户提供多大的帮助
平衡危害
赢得用户的价值
评估发布计划
成本
与变化有关的每一点时间,都是成本的一部分
维护
成本=实现成本+维护成本(E=Ei+Em)
价值=当前价值+未来价值(V=Vn+Vf)
完整的方程式
D=(Vn+Vf)/(Ei+Em)
化简方程式
随时间流逝,当前价值和实现价值越来越不重要
D=Vf/Em
你需要什么,不需要什么
维护成本增长速度比价值快,就会遇到麻烦
理想状态:维护成本随时间降低,最终接近0
未来收益高于维护成本,则值得做
相比降低实现成本,降低维护成本更重要
设计的质量
设计质量的好坏,正比于该系统在未来能持续帮助他人时间的长度
不可预测的结果
预测短期未来是可能的,但长期未来基本是未知的
决策时,考虑未来的变数,而不是预测未来
软件设计的目的是创造更好的未来,而不必预测未来究竟会发生什么具体的事情
变化
变化定律
程序存在的时间越久,它的某个部分需要变化的可能性就越高
程序应当保证尽可能合理的灵活性,以应对变化
真实世界中程序的变化
软件设计的三大误区
编写不必要的代码
“你不会需要它(YANGI)”
不要编写不是必需的代码,并且要删除没有用到的代码
代码难以修改
原因
对未来做太多假设
每次只确定少数几个需求,并立刻实现
不仔细设计就编写代码
设计程序时没,应根据现在确切知道的需求,而不是你认为未来会出现的需求
过分追求通用
问题
无论多么通用,都不够满足未来面对的真实需求
不能从用户的角度很好地满足需求
写过多不需要的代码
渐进式开发及设计
渐进开发:通过小步骤构建整个系统
渐进设计:通过小步骤用来创建和改进系统的设计
缺陷与设计
缺陷概率定律
在程序中新增缺陷的可能性与代码修改量成正比
与“变化定律”矛盾
因此需要设计
理想的设计:能适应外界尽可能多的变化,而软件自身的变化尽可能少
如果这不是问题
永远不要“修正”任何东西,除非它真的有问题,而且有证据表明问题确实存在
避免重复
理想情况下,任何系统的任何信息,都应当只存在一次
简洁
简洁定律
软件任何一部分的维护难度,反比于该部分的简洁程度
简洁与软件设计方程式
化简代码对于降低维护成本非常重要
简洁是相对的
加上“头一次看代码,那么……”的注释
文档
不同上下文时,同样的情况是否简洁是不一定的
工具的简洁程度与每个人使用的熟练程度有关
简洁到什么程度
简单到傻子也能懂!
降低代码学习难度的方法
简洁的注释
简单的设计
循序渐进的引导
保持一致
在编程时保持相同的方式(如命名)
程序的内部行为应当保持一致
可读性
代码被阅读的次数远多于编写和修改的次数
代码可读性主要取决于字母和符号之间的空白排布
一致
命名
足够长以完整表达意义或描述功能,但不能太长影响阅读
考虑频率,常用的更短
注释
代码的意图不应该用注释说明
注释的目的是在理由不够清晰明显时加以解释
简洁离不开设计
复杂性
复杂性
会叠加,并且不是简单的线性叠加
原有功能越多,新增功能成本越高
增加复杂性的做法
新增功能
扩展软件的用途
新增程序员
做无谓的改变
困于糟粕的技术
糟粕:深陷其中
理解错误
糟糕的设计或不做设计
重新发明轮子
复杂性与软件的用途
系统基本用途应当是简单的,不要添加满足其他目标的功能
思考用户的需求
最受用户喜欢的软件是专注而简洁的,并且始终执着于基本用途
糟糕的技术
生存潜力
持续获得维护的可能性
开发者是否积极
用户是否活跃
供应商是否单一
互通性
如果需要,从一种技术切换到另一种技术的难度
对品质的重视
最近的发布中,产品是否更加完善了
是否重构了
是否更易用
安全问题
其他原因
是否简洁
是否符合软件的基本用途
个人喜好
复杂性及错误的解决方案
了解真正要解决的问题是什么
复杂问题
大多数麻烦的设计问题,可以用在纸上画图或写出来的方法找到答案
应对复杂性
办法
拆解成小部分,逐步重新设计
每次修改足够小,不让事情更复杂
首先要做好设计
不能花很长时间专门重新设计,停止开发新功能
违反变化定律
重新设计时只考虑让新功能更易实现,然后实现它
把某个部分变简单
做什么?
设计模式
设计方法
学习软件工程师普遍使用的工具
掌握多门语言
熟悉不同类库
不可解决的复杂性
屏蔽这种复杂性
在外面包装一层
推倒重来
可以接受的条件
已完成准确评估,证明重写比重新设计更有效率
有足够时间重新开发
有比原系统更高明的设计师,或设计师能力大大提升了
完全打算好了通过一系列简单的步骤设计整个新系统,每一步都有用户反馈
有足够的资源,兼顾维护原系统和重新设计新系统
测试
测试法则
你对软件行为的了解程度,等于你真正测试它的程度
软件的最后一次测试时间距离越近,继续正常运行的可能性越大
软件在越多的环境中测试过,就越确定它可以运行在这些环境中
除非亲自测试过,否则你不知道软件是否能正常运行
保证测试是准确的
必须观察测试的结果,确保它们是有效的
如果失败,必须有办法让你知道情况及原因
自动化测试