代码大全(读书笔记)

此博客是《代码大全》读书笔记,记录软件开发过程,如定义问题、需求分析等,强调需求明确及应对变更的方法。还阐述架构先决条件,包括程序组织、数据设计等。介绍理想设计特征,如最小复杂度、松散耦合等,以及设计层次中子系统的交互关系。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

代码大全(读书笔记)

2021.06.27 开始阅读此书,这篇文章记录了一些读此书或者这款时间工作生活的一些心路,希望自己能持续从此受益。


2021.08.05 此次阅读的关注点在第 3/5/6/7/12/13 章


我虽然是计算机行业从业者,但本身不是计算机专业出身,很惭愧没能更早的耳濡目染更多基础但不可忽略的知识,虽此行业已被很多其他行业从业者开始逐步进入,但私以为最基本的素养不应该被降低,也因此不断提醒和鞭策自己,学习是一件不得不做且应该去做的事。—2021.06.27


2021.08.13 理想的设计特征


2021.08.20 设计的层次

welcome to software construction

软件开发的过程

  • 定义问题
  • 需求分析
  • 规划构建
  • 软件架构或 high-level design
  • 详细设计
  • 编码与测试
  • 单元测试
  • 集成测试
  • 集成
  • 系统测试
  • 保障维护

大部分公司其实都是「序列开发法」和「迭代式开发法」的混合,而绝大多数更侧重于前者。

references:

敏捷开发学习总结(1):传统序列式软件开发方法的缺点,以及迭代开发方法的选择

需求的先决条件

一个 Objective 不够明确,看起来非常高大上,但实际上没有可量化的指标,回头想跟这里需求分析一样,需要明确的需求其实是一个项目良好的开端。

关于需求变更:不管是 toB 还是 toC 都无法避免需求变更,该书提醒我们有必要在变更频繁时:建立变更控制程序,使用能够适应变更的开发方法,当然有必要时也要放弃一个不合理的项目。

  • 适应变更的开发方法更详细的是什么?

架构的先决条件

最终方案确定时,一个关键步骤是记录下摒弃其他方案的理由是什么,而最终方案不可替代的原因又是什么。

架构的典型组成成分如下:

部分顺序没有遵循原书中的设计,我自己也加入了一些个人观点,并对一些方面进行了合并和删减

  1. program organization
  • 架构应该定义程序的主要构造块,根据程序规模不同,各个 building block 可能是单个类也可能是许多类组成的子系统。同时应该提前考虑好构造块直接如何进行通信。
  1. major classes
  • 指明每个类的责任、继承体系、状态转换、对象持久化的描述
  • 类和其他类怎么交互

个人觉得这是一个很重要的步骤,有利于对项目抽丝剥茧

  1. data design

这里很关键的一步是:

数据通常只应该由一个子系统或者一个类直接访问:以受控且抽象的方式来访问数据

  1. business rules 业务规则
  2. resource management

资源管理在 backend 架构设计中是经常需要考虑的一个方面,包括数据库连接、线程、Redis 等。
6. security

这也是一个很重要的方面,涉及到用户输入数据的安全性,怎么防御 xss、csrf 等,以及 sql 注入等常见的安全隐患

  1. input/output 输入与输出 error processing 统一的错误处理 fault tolerance 容错性

在错误处理中需考虑到向用户吐露哪些错误信息是清晰的,同时需要考虑暴露错误栈的合理性。
7. user interface design 用户界面设计 与 internationalization 即 i18n 国际化
8. scalability 可伸缩性 interoperability 互用性 Reuse Decisions 复用决策 change strategy 灵活变更的策略

目前的开发经验中,对于这几点除非在做架构设计之前已经有类似的需求背景,那么在复用性上的考虑可能会相对局限,但注意这仅仅针对整体架构。对于子结构而言考虑 interoperability 是很有意义且必须做的一件事。

image
image

Key design concepts 关键设计概念

desirable characteristics of design 理想设计特征

  1. 最小的复杂度:简单易于理解
  2. 易于维护
  3. 松散耦合:设计出相互关联尽可能最少的类。
  4. 可扩展性:增强系统功能但不破坏底层结构
  5. 可重用性
  6. 高扇入 high fan-in:大量的类使用某个给定的类,utils
  7. 低扇出 low fan-oout:让一个类少使用其他的类
  8. 可移植性、精简性、层次性、标准技术

levels of design 设计的层次

image

关于子系统:

为了让子系统之间的连接简单易懂且易于维护,应该尽量简化子系统之间的交互关系。(就是不要牵一发而动全身

最简单的交互关系是:让一个子系统去调用另一个子系统中的子程序。

稍复杂的交互关系是:在一个子系统中包含另一个子系统的类;

最复杂的交互关系是让一个子系统中的类继承自另一个子系统中的类。
image

🔖 P84

TODO: 时至今日如果让你来设计通知系统会是什么样呢?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值