软件设计的原则：高内聚、低耦合，面向对象的三大特征，封装、继承、多态。
| 简称 | 英文名 | 中文名 |
|---|---|---|
| SRP | The Single Responsibility Principle | 单一责任原则 |
| OCP | The Open Closed Principle | 开放封闭原则 |
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
| ISP | The Interface Segregation Principle | 接口分离原则 |
| DIP | The Dependency Inversion Principle | 依赖倒置原则 |
-
S:单一责任原则，注重的是职责，主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节。
-
O:开闭原则，对新增开放，对修改关闭。主要是用多态性，面向接口面层。
-
L:里氏替换原则，父类可用的情况下，子类也可以使用。也就是说子类条件更严格。
-
I:接口分离原则，注重对接口依赖的隔离，主要约束接口接口，主要针对抽象，针对程序整体框架的构建。
-
D:依赖倒置原则，高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象，主要是面向接口编程而非面向实现编程。
如何做需求分析
需求调研，准备问问题的模板
内四外八模型
业务内部：业务属性字段、业务属性规则、业务属性逻辑、业务属性场景
业务外部：业务操作者业务权限、前置业务、业务能力要求、业务环境要求、后置业务、业务输入与输出、业务可视化（外观）、业务后续处理（日志、通知）
五问法
就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。5why法的关键所在：鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。
2.如何做设计
软件为谁设计
前端使用者
后端使用者
外部使用者 + 内部使用者
主动使用者 + 被动使用者
如何获得设计能力
第1阶段，读源码
持之以恒的克勤精神，天下断无不成功之事
编程语言和OS
读Linux0.01源码，8000行代码，50页心得体会
对比式阅读，0.11版，16000行代码，为什么增加8000多行，是变好了，还是变坏了？
第2阶段，看设计
UML工具，看方法，类，文件切割，官网上有600多页白皮书，OMG证书
用手机阅读Linux 1.0内核的UML类图
阅读Linux2.0内核UML类图，与1.0类图相比，为什么设计发生了变化
推荐书籍《重构与模式》
第3阶段，看代码结构
阅读Linux3.0内核的包图，文件夹
Windows源代码的包图，对比商用软件与开源系统的结构设计的异同
第4阶段，看开源代码获取设计经验
获取他人设计经验的秘诀，外部的开源软件
功能分解
列出所有功能，画出鲁棒图
边界
画出鲁棒图，边界行为图
控制
实体
画出类图 类于类之间的关系
软件变化如何设计？
1. 列出所有变化
2. 问几个问题
变化是单一方向的变化么？
复合变化如何分解这种变化？
复合变化是值类型的变化么？ -采用配置方式解决。
复合变化是逻辑变化么？ -采用脚本的方式解决。
设计如何决定代码层次
Enterprise Architect，源代码和数据库
功能到编程文件
从功能到编程文件 ->切割方法
--敏捷方法论 - ICONIX - 对象切割法
1功能N编程文件
1功能1编程文件
接口相关
所有与边界相关程序 边界程序-边界对象
UserInterface - UI
ServiceInterface - SI
所有与逻辑控制相关的程序
业务逻辑
控制程序-控制对象
Business Logic - BL
实体对象
所有与实体数据相关的程序
实体程序 - 实体对象
Business Entity - BE
MVC思维，普适性
编程文件分类 1、UI层（UI文件夹）2、BL层（BL文件夹）3、Data层（Data文件夹）
UI和BL耦合，解耦->外观层
BL和Data层解耦->持久层
3. 如何编码
代码格局
古文式的源代码 -> 白话文的源代码，良好的阅读性，1行1职责
空白行、注释，源代码需要分段，源代码需要分段注释
债务思维
防御性编程
入口参数，左右边界
-技术的边界 + 业务边界的漏洞
团队拥有代码
遵守共同的代码规范、编程规范、代码布局风格
推荐书籍 《码出高效》
阿里代码规范插件
什么是好代码？
好的代码拥有优雅性和直白性
好坏代码差异性体现在程序格局、防御性编程、团队拥有代码。
优秀的代码不需要说明，可怜的代码需要大量注释。
优秀的程序需要更多的时间，但在未来花更少的时间。糟糕的项目往往花更少的时间，但是在未来会浪费更多的时间。
优秀的项目是考虑当前和未来的需要，糟糕的项目只侧重于现在，未来可能不能工作。
良好的程序很容易维护，糟糕的项目很难维护。
新代码如何写
函数如何写
高扇入低扇出
函数名
--函数名，不变化，知名达意，函数命名，JDK API，命名交给语言专家来做
变量
函数大小
限制程序文件代码行，限制每个函数代码行《重构》java最小函数，超过20-30行必须重构
java函数20-30行，逻辑不复杂。
20-30行函数花费时间0.5小时-1小时
公共函数如何写
公共函数如何减少其变化，问几个问题
函数会发生哪些变化？
变化是单一的么？
复合变化怎么处理？分解变化。
参数列表
--参数列表，变化单一的吗，变化复合的；分解变化
--参数个数变化，单一性变化
----参数封装法，结构体-对象-集合-数据-流 -> 接口函数，外部远程调用，多种编程语言调用，调用语言变化->封装消息，构造消息，SOAP方式，通讯调用端口->1个消息
----预留参数法，Windows COM机制《COM本质论》
----1个-2个-N个参数，最小接口原则，多态机制、角色分离原则
--参数类型变化，单一性变化
----Object万能量，装箱与拆箱，性能消耗
----类型封装成泛型
旧代码如何写？
阅读源码
如何阅读源码？
按变量的生命周期的办法阅读源码
按照对比法阅读源码
重构
如何重构
代码中的重复性或相似性 Copy/paste -重构到框架，aop框架
重构策略
绕来绕去 0 风险
设计模式重构 大风险
母子函数法 小风险
领域领域驱动设计
架构重构-降低风险 使用微服务。
领域驱动-对服务进行分割
如何应用设计模式
23种设计模式解决了 23种变化
设计模式分成三大类： 结构型，创建型，行为型。
如何选择设计模式？
类实例化的方式 - 创建型 单例
属性定义结构 -结构型 桥接
复杂算法 - 行为型 策略模式
4.如何保证代码质量
单元测试
如何单元测试
要测试哪些？
所有函数都需要测试
Public 测试
接口测试
如何选择测试用例
1. 代码覆盖率
2. 分支循环覆盖
3. 输入取值
4. 如何取值？
单参数取值法
边界取值法
分类取值
逻辑取值
组合参数取值
5.验证单元逻辑
测试驱动开发 TDD
自动化测试
5.如何自我管理
工作方式
《番茄钟工作法》，整段时间工作25分钟，休息5-10分钟，经历2个番茄钟，休息10-15分钟
工具使用
搜索：
---码出高效 filetype：pdf
科/学上网方式
必须会down论文，读论文
建立缺陷库
自己缺陷库-典型缺陷发布
缺陷信息记录：症状、场景、证据、推断、定位、策略、之前、之后
每次发版 - 缺陷列表 - 每个缺陷对应源代码（旧的-新的-对比）
归纳总结
代码培训，培训重在归纳总结
