软件设计简洁代码思维导图

软件设计简洁代码，计算机出了什么问题？程序究竟是什么？为什么不存在软件设计科学？软件设计的推动力，一篇思维导图，带你详细了解软件设计！

软件设计简洁代码思维导图

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