【软件工程Ⅱ】作业三 |读《构建之法》1-5章有感

本次作业的要求来自于:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

前言

 曾经听过别人问过我这样一个问题,一个月中除了课本你看过多少本书?一年呢?说实话,这个问题让我确实无言以对,我不知道该说什么,是了,我连课本都不太想看,更别说读一些其它的书籍来充实自己了。所以,趁着国庆之余我决定读上几本书来充实自己,而这一本虽然不在我的计划范围之内,但看了之后发现书上有很多很有趣了例子,也不会觉得无趣。粗略的阅读了《构建之法》1-5章,虽然课本有些地方写得很详细,但还是会有一些疑问,以下是我看了书之后的疑问。

第1章 概论

 1.2 软件工程是什么

(1)怎么理解软件工程

我其实不是很懂什么是软件工程,只是知道软件工程在软件开发中不可或缺的。

软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程

——《构建之法》

软件工程这个概念对于现在的我来说还是比较模糊,事实上,我去网上看了一些关于软件工程的描述与书上说的意思基本一样,但是目前的我还做不到用自己的话把对软件工程的理解描述出来,所以软件工程到底是什么?可以举例说明吗?

(2)什么才是真正意义上好的软件

“所谓好的软件,就是软件没有缺陷(Bug),所谓软件工程,就是把软件中的Bug都消灭掉的过程“

”什么是Bug呢?简单的说,软件的行为和用户的期望值不一样,就叫Bug。是否是Bug,取决于用户、开发者的不同角度“

——《构建之法》

百度百科上对Bug是这样描述的:”软件的Bug,狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。“

那么当我们开发出某一个软件,一部分用户在使用的过程中觉得软件的某一个功能不应该有,而一部分用户又很喜欢软件的这个功能,当用户对软件的某一个功能持不同意见时,这个功能的存在是不是一个Bug呢?身为开发者的我们是应该把这个功能删了还是继续保留呢?

第2章 个人技术和流程

 2.1 好的单元测试的标准

书上对于好的单元测试的标准一共罗列了9条,它们分别是:

  1. 单元测试应该在最基本的功能/参数上验证程序的正确性;
  2. 单元测试必须由最熟悉代码的人来写,一般指程序的开发者;
  3. 单元测试后,机器状态保持不变;
  4. 单元测试要快;
  5. 单元测试要产生可重复、一致的结果;
  6. 单元测试时每个单元要保持独立性,即单元测试的运行/通过/失败不依赖于别的测试;
  7. 单元测试应该覆盖所有代码路径;
  8. 单元测试应该集成到自动测试的框架中;
  9. 单元测试必须和产品代码一起保存和维护。

首先,单元测试后要保持机器状态不变,那么机器状态不变具体指什么?

其次,什么是覆盖代码路径?为什么单元测试要覆盖所有的代码路径?这样做有什么意义吗?如果代码很复杂也要这样做吗?百度百科对于覆盖代码路径的描述是这样的:”路径覆盖(Path Coverage),又称断言覆盖(Predicate Coverage)。它度量了是否函数的每一个分支都被执行了。“

我们在做一个具体的项目的时候怎样做到覆盖所有代码路径呢?

第3章 软件工程师的成长

3.3 软件工程师的职业发展

书上说的一句话我深感认同,那就是”没有人能在学校里掌握所有‘将来会用到的知识’才离开学校随后马上把技术运用在实践中“,我们经常说活到老学到老,这并不是嘴上说说而已,现如今,我们每个人都是通过学习各种知识来成长,而职业成长同样也如此。下图是来自绉老师的软件工程师自我能力评价表(http://www.cnblogs.com/xinz/p/3852177.html)中截取的一部分,通过此表我们可以进行自我评价并根据评价结果以及实际情况调整自己的学习计划。

目前为止我还处于学习基础的阶段,最缺泛的就是对于所学东西的应用,所以目前对于我来说最基本的应该是把一些理论知识争取做会应用,把低层次的问题给解决掉。这一节我的疑问是既然我们要对自己的未来有所规划,那么我们怎样确定自己什么科目学精什么科目粗略的知道就好呢?

第4章 两人合作

 4.4 代码复审

代码复审主要是看是否在代码规范的框架内正确地解决了问题。代码复审主要包含三种形式,分别是自我复审、同伴复审和团队复审。

我对于代码复审的疑问是代码复审是不是真的每一行都要执行并检查一次?在真正的项目开发中我们有这么多时间去一行一行代码的检查吗?代码复审要求要有可测试性,那么这个可测试性是要通过怎么来做到的呢?

第5章 团队和流程

 5.3 开发流程

软件开发模型分为瀑布模型、快速原型模型、增量模型、演化模型和喷泉模型等,我们一般的软件开发都会采用瀑布模型,瀑布模型将软件划分为制定计划、需求分析、软件设置、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

我这一章的疑问是像我们如果想要开发一个比较实用的软件,但是我们没有客户,那么需求分析可以从何而来?我们可以通过什么方式去获取用户的需求呢?

原文地址:https://www.cnblogs.com/bhuan/p/9751772.html