【原】软件开发知识体系

软件开发历程

1. ALL IN ONE
   

• 软件开发最早时期的开发模式，可以理解为一体化，所有业务、接口都在一套系统，毫无层次可言。

2. MVC
   

• MVC 是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式。

3. RPC
   

• RPC（Remote Procedure Call Protocol）——远程过程调用协议

• 简单的说，RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
  RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
  RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
  RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。

4. SOA/SaaS
   

• 早期软件服务模式
  

• 本地PC模式（一台电脑，一个服务，完全封闭式，无法对外提供接口服务，非互联网概念）

• 机房-PC（一个机房作为几台PC的服务中转站，无法对此机房外提供接口服务，非互联网概念）

• 云服务-SaaS（数据、服务接口在云端，提供API给N个终端使用）

• SOA包括了关于软件是如何被架构起来的东西，而SaaS是关于软件是如何被应用的。

• SOA是一个框架的方法，而SaaS是一种传递模型。

• SaaS主要是指一个软件企业向其它企业提供软件服务。而SOA一般是企业内部搭建系统的基础。SaaS注重的是提供服务的思维。而SOA注重的是实现服务的思维。

• 面向服务架构（Service Oriented Architecture，SOA）
  

• 软件即服务（Software as a Service，SaaS）
  

从需求到实现

1. 需求分析
   

• 根据产品描述，分析如何实现产品功能

2. 概要设计
   

• 通过需求分析，数据流向，设计出大概功能模块

3. 详细设计
   

• 定义功能模块接口、方法、参数、返回值、实现逻辑

4. 数据结构
   

• 实现产品功能逻辑需要的数据库表，创建表需要明确字段、索引，如果需要修改旧表，考虑给字段默认值

5. 接口定义
   

• 接口调用地址、方法名、方法参数、方法返回值、方法实现逻辑

6. 兼容性
   

• 旧方法名称、参数不要变更，如有新逻辑，可增加方法参数，如果逻辑复杂考虑根据新增参数判定是否是更改后的需求然后用方法重载去实现新的业务逻辑

7. 设计评审
   

• 设计好功能模块接口、方法、参数、返回值、业务逻辑、数据库结构之后提请编码前的设计评审，方便问题的早发现、早更改

8. 代码实现

项目开始前：反复思考，聚焦于全景，设定结果导向、清晰的目标和实现策略。

项目执行中：优先执行最重要的事，并且每次只做一件，做的过程减少干扰和分心。

项目完成后：进行反省，衡量产出质量，执行过程中问题总结，为下次项目提供经验和准备。

1. 想清楚，搞明白（不清楚不明白肯定出问题，需要找相关人确认）

2. 规范（不规范的做法不但'污染’程序，更会造成逻辑上的歧义，例如：变量的命名）

3. 效率建立在想清楚搞明白后用正确的方式方法去规范的执行基础之上

对于新知识点的学习

• 是什么？

• 有什么特点？(应用场景，注意事项)

• 怎么开始？(demo)

• 使用场景？（test）

了解老业务流程

可借助UML

1. 表结构  
   

• 可画出E-R图也称实体-联系图(Entity Relationship Diagram)提供了表示实体类型、属性和联系的方法

• E-R图可以方便直观的表现出业务模块的数据结构

2. 业务流程
   

• 可画出
  

1. 流程图：（Flow Chart）使用图形表示算法的思路。

2. 时序图：（Sequence Diagram），亦称为序列图或循序图或顺序图，是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，时序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。

3. 状态图：(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。

3. 类结构
   

• 类图，同E-R图

4. 接口

• 通过1-3过程梳理接口之间逻辑关系，达到对老模块业务流程的至少70%的了解程度

上线流程

严格按照 bus->test->beta->production 流程上线

注意：beta必须和production代码保持一致（都是master的代码），配置文件保证和环境的一致性，不允许有跨环境的调用

1. 准备SQL

2. 确认dal.properties数据源配置正确

3. 确认用到的消息队列配置是否正确

Git

合并代码注意事项

1. 上线时间
   

• 如需要合并其他分支代码，需要确定是否和当前需要上线的功能时间一致，一致可以合并，否则不要合并

2. 是否测试完成
   

• 测试阶段中的代码一定不要上线

3. 是否是从最近的master合过来的代码
   

1. 分支功能开发过程中，可以时常把master的代码合并到当前分支，减免完成后再合并造成的更多冲突

4. 解决冲突

1. 先从pom文件开始解决，保证引用的模块都是正式版本

2. 确认冲突（非自己业务模块如果搞不清楚冲突，找相关编写人员确认）

3. 不要格式化代码（格式化代码会造成更多的冲突）

Maven

通过mvn生命周期打包主要过程，具体过程可参考http://maven./guides/introduction/introduction-to-the-lifecycle.html

• compile（编译项目的源代码）

• process-test-resources（复制并处理资源文件，至目标测试目录）

• test-compile（编译测试源代码）

• test（使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署）

• package（接受编译好的代码，打包成可发布的格式，如 JAR）

• install（将包安装至本地仓库，以让其它项目依赖）

• deploy（将最终的包复制到远程的仓库，以让其它开发人员与项目共享）

Maven标准目录结构

src

   - main 项目主体目录

     - java java源代码文件

     - resource 资源目录

     - config 配置文件目录

   - test 测试目录

     - java 测试代码目录

     - resource 测试所需资源目录

 pom.xml maven的pom文件

Java 规范

war包目录结构（j2ee 规范）

 WEB-INF目录（安全目录）

• web.xml：Web应用部署描述文件，必须目录

• classes目录：存放字节码文件、配置文件

• lib目录：存放第三方类库文件

• 存放图片，jsp等页面信息

其他，待补充...

与之相关

1 6 天时间修改 1 行代码：现实中的软件开发流程

2 软件开发中的 10 条最佳指导原则