项目开发前需要思考的问题 | 让子弹飞一会
Cobb 619 0

项目中需要思考的问题,这往往决定项目的成败! 01 - 开发流程的定义 02 - 平台与框架的选择 03 - 目录结构及源码管理 04 - 嵌入式产品的开发效率

01 - 开发流程的定义

啥是软件开发流程?

0.01 通过一系列步骤保证软件产品的顺利完成 0.02 软件产品在声明周期内的管理方法学

软件开发流程的本质

0.01 开发流程与具体技术无关 0.02 开发流程是开发团队必须遵守的规则


介绍团队成员之间合作的发展史...

A. 瀑布模型(Waterfall Model)

0.01 通过自上而下的步骤进程软件开发 0.02 每个开发步骤都是不可逆的


步骤: 需求分析 -> 架构设计 -> 开发实现 -> 系统测试 -> 最终发布


分析: 这是早期的模型,步骤都是不可逆的(瀑布),这个模型在早期是行之有效的(早期的用户需求低,功能单一),可是随着软件规模的增加,对软件功能需求的增加,于是前辈们发现,瀑布模型不好用了,因为只有需求分析阶段和用户打交道,后期每个阶段都是不需要和用户打交道的,导致最终产品和用户需求是有差异的。 于是提出新的模型 Incremental Model

B. 增量模型(Incremental Model)

0.01 将系统功能分解为互不重叠的子功能 0.02 每次全力实现一个子功能(使用Waterfall Model) 0.03 子功能全部结束后系统开发结束


步骤: 功能1: 分析 -> 设计 -> 开发 -> 测试 功能2: 分析 -> 设计 -> 开发 -> 测试 ****功能3: 分析 -> 设计 -> 开发 -> 测试


分析: 相对于Waterfall Model模型,最大的改进,用户参与度高,每个小功能都是用户满意的。但是到了后期发现一个问题:各个功能之间是关联的。 这时增量模型就出现了问题。。 于是提出新的模型 Spiral Model

C. 螺旋模型(Spiral Model)

0.01 采用一种迭代的方法来进行系统开发 0.02 软件项目分解成多个不同的版本完成 0.03 每个版本的开发过程都需要用户参与 0.04 根据前一个版本的反馈计划下一个版本


分析: 仍然是分解,但不是功能上的分解,而是版本上的分解。前期预先定义好这个项目分为几个阶段来完成,每个阶段会产生软件的中间版本,并且每个版本在开发的时候,都需要用户的参与。 事物总是发展的嘛,还有更好的开发模型。

D. 敏捷模型(Agile Modeling)

0.01 一切从简 0.02 拥抱变化 (TEAMS USERS: 开发团队深入到用户内部,和用户在一起开发这款软件,好处在于,用户需求改变,开发团队立即知道,提高开发效率,避免无用功) 0.03 高效工作 0.04 持续开发


总结: 0.01 每个模型的提出,都是为了更好的开发出符合用户需求的产品,做到这一点的方式是,提高用户在软件开发过程中的参与度. 0.02 瀑布模型只有需求分析的时候用户参与,而敏捷模型是时时刻刻和用户一起。 0.03 越靠近用户,开发出来的东西越符合需求。

02 - 平台与框架的选择

开发速度往往决定一个开发团队,一个公司的生死存亡。

开发平台 VS 开发框架

软件开发平台 0.01 开发平台是位于操作系统之上的软件层(封装操作系统上一些细节的实现,直接提供模块化的功能) 0.02 开发平台提供更多通用模块化的功能,简化(加速)软件开发平台

软件开发框架 0.01 开发框架是位于开发平台之上的软件层(相对于开发平台来说,抽象封装的力度更高) 0.02 开发框架是为特定应用所设计的更抽象的软件模型


总结: 开发平台提供的模块化的功能是比较通用的,而开发框架提供的模块化的功能比较定制了,只适合特定的应用。 并且框架是位于平台之上的。

平台与框架示例一: Spring / Java

--------------------
    Web 应用程序        |
--------------------
    Spring            | 框架层  
--------------------
    Java            | 平台
--------------------
    OS                |
--------------------

Spring->这个框架针对轻量级的web程序而设计的,非常定制。(基于平台的,模块是定制的)

平台与框架示例二: Qt

    -----------------------------
    |    桌面应用程序                |
---------------------------------
    |状态机框架 | 模型视图框架    | 框架层
    |      动画框架    ……            |
Qt    -----------------------------
    |        Qt Core                | 平台层
---------------------------------
    |        OS                     |
    -----------------------------

Qt既是一个平台,又是一个框架。最好去看一下源码,设计非常简洁明了。


总结: 选择平台与框架的标准:"可以加快项目的开发速度"

03 - 目录结构及源码管理

目录设计 VS 源码管理 (制定规则)

0.01 项目中每个文件的代码用一个文件夹进行管理 ----------文件夹由inc, src, makefile构成 0.02 项目中每个模块的对外函数声明统一放置同一目录中 ----------如:common.h xxxfunc.h

目录设计示例:

项目:Project
第一层:libs common module main -------# Project项目下的四个文件夹 第二层:libs : inc、lib ------# libs库下的文件存放的文件夹 第三层: inc: dlib.h slib.h lib: dlib.so slib.so

目录设计的意义:

0.01 书架功能 --------反映项目中代码的层次感和模块化 0.02 意识引导 --------引导对于新增文件功能,命名及位置的思考 0.03 增强维护性 --------加快开发人员对于项目整体架构的理解

04 - 嵌入式产品的开发效率

常规嵌入式开发的方式 01代码编写 -> 02代码修改 -> 03交叉编译 -> 04程序烧写 -> 05功能验证 -> 06判断通过? -> 07结束战斗

备注:如果06不通过,那么回到02返回执行 02 - 06 之间的步骤。 每改动一个地方,就要在硬件上做功能验证。反复烧写是体力劳动,而且,拖慢了开发速度。


存在问题

0.01 开发工程师必须人手一台设备(项目早期可能无法满足) 0.02 每次代码改动必须到设别进程验证(效率低下) 0.03 反复多次烧写可能导致设备损坏(不稳定的早起设备)

调试问题

0.01 需要基于额外硬件(JTag)连接设备进行断点调试 0.02 常规日志只能写于文件中,无法实时查看 0.03 几乎无法进行现场调试(客户环境调试)

嵌入式基础设施的建设

0.01架构设计时,模块之间遵循强内聚,弱耦合原则 -----------模块能够基于PC环境编译,进行单元测试 0.02 开发PC环境中的设备模拟器 -----------产品代码能够在PC环境完整编译并运行PC环境 0.03 开发产品中可实时查看输出日志系统 -----------设备运行日志输出可以实时传输到PC环境,客户现场定位问题。

文章参考 https://item.taobao.com/item.htm?ft=t&id=612571963885

评论区

索引目录