读书笔记6—构建之法

第六章——敏捷流程

1、

     这一小节中有一个图表,对比了敏捷(Agile)、计划驱动(Plan-driven)、形式化的开发方法(Formal Method)的适用范围。里面提到的形式化的开发方法,其基本步骤是怎样的呢?为什么它能有极高的可靠性呢?下面是一些关于形式化方法特点的说明,从中可以看出它能力的缘由。

  形式化方法建立在严格的数学基础上,其目标是希望能使系统具有较高的可信度和正确性,并能使系统具有良好的结构,使其易维护,关键是能较好地满足用户需求。“形式化方法”一词虽然一直被广泛地应用,但在不同程度上,因理解不同,使其具有了不同的含义。一般说来,形式化方法是指具有坚实数学基础的方法,它是数学上的综合、分析技术的应用,用于开发计算机控制的系统,经常有推理工具的支持,它可提供一个用于模型设计和分析的一个严格而有效的途径。

  形式符号系统具有一定的数学性质,所以它们非二义性的基础在于其内在的数学结构。越是复杂的数学概念,越是建立在更原始的概念之上,如:集合、命题逻辑。这就是说,形式符号系统可以具有合适的解释,并在理论上足以确保规范的一致性解释。 形式规范是由一些精确的定义组成的,因为其符号系统的含义是明确定义的。相对地,若将英语作为交流媒体,将很难得到精确的规范。精确规范的直接益处在于:它能减少规范中的二义性和误解释的可能性(危险)。精确是形式化方法或形式符号系统的一个特征,是产生无二义性规范的主要依据。另外,形式规范主要的语用益处在于:可以对形式规范进行较详细的构造性检查,因为对此规范中的具体内容的含义不会有争议,有争议的只是内容的完备性。换句话说,精确有助于确认和交流。 由于适当的形式机制的使用,使得规范的抽象性成为可能。抽象是人们处理复杂性的主要智力工具之一,而且通过忽视不感兴趣的部分,从而有助于清晰性。各种形式符号系统对于精确、抽象地表达概念具有各自不同的能力,但它们均可用于严密地描述概念,更重要的是,它们比自然语言的描述更严密、更精确、更抽象。一般地,形式系统(框架)使得表示一个规范与其相应程序之间的映射成为可能。 形式规范有一个很有价值的特性:可操纵性。这就是说,可以在明确定义的规则的指导下,分析规范或或对形式规范进行变换。利用形式规范的可操纵性可以证明规范的一致性;可以推导出关于此规范的一些重要结果;还可以验证规范的实现过程,至少可以验证源代码相对于其规范的正确性。更一般地说,有可能将不同级别规范间的验证以及规范与程序间的验证问题简化为形式证明问题。这样,形式化方法就可以提供程序对应其规范的非常高的可信度。所以,可操纵性也有助于确认,并且由这种特性可以得到进一步的抽象(推导出的性质),同样,也有助于使得规范更清晰。

2、

这一小节提到了几种比较出名的敏捷开发方法论,如FDD、Scrum、XP、TDD。前三者在书中都有专门的介绍,但TDD,又是什么呢?

  TDD(Test Driven Development),即测试驱动开发的基本思想就是在开发功能代码之前,先编写测试代码,然后只编写使测试通过的功能代码,从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码,有很高的灵活性和健壮性,能快速响应变化,并加速开发过程。

  测试驱动开发的基本过程如下:

  ① 快速新增一个测试

  ② 运行所有的测试(有时候只需要运行一个或一部分),发现新增的测试不能通过

  ③ 做一些小小的改动,尽快地让测试程序可运行,为此可以在程序中使用一些不合情理的方法

  ④ 运行所有的测试,并且全部通过

  ⑤ 重构代码,以消除重复设计,优化设计结构

  简单来说,就是不可运行/可运行/重构——这正是测试驱动开发的口号。

  可想而知,测试驱动开发会极为有效地控制开发中的bug,但是这种先写测试代码的方式可能让开发人员有很大的不适应。学习适应TDD的成本会不会比它带来的收益更高呢?这就有待我们在实践中摸索了。

时间: 2024-10-13 22:00:52

读书笔记6—构建之法的相关文章

第一周读书笔记《构建之法》

构建之法读书笔记 #wmd-preview h1 { color: #0077bb } 构建之法读书笔记 沈三景 PB15061249 软件工程 读书笔记 前言 开学前两周,杂事颇多,没有充足的时间阅读<构建之法>,只能每天在睡前阅读约半小时,故只看了前三章.虽如此,但仍收获很多,下面就是我对前四章内容的一些看法和理解,如有理解偏颇之处,望见谅. 第一章 概论 本章主要介绍了软件工程是什么?软件工程的目标是什么?为了解决前一个问题,作者首先提出了两个等式: 程序 = 数据结构 + 算法 软件

第二周读书笔记《构建之法》

构建之法读书笔记 #wmd-preview h1 { color: #0077bb } 构建之法读书笔记 沈三景 PB15061249 软件工程 读书笔记 前言 本周阅读了构建之法的四.五两个个章节.这三个章节主要讲述了代码规范.结对编程.团队模式.开发流程. 第四章 两人合作 首先提到的是代码规范,程序员写的代码不仅要给机器看,还要给人看.好的代码规范能事半功倍.代码规范有分为代码风格规范和代码设计规范.代码风格规范是指让代码保持简明,让代码更易读.书中给出的规范是Tab键为4个空格,行宽为1

读书笔记(构建之法-11.19)

读构建之法有感: 今天在实验室读了构建之法书的第4章-两人合作,书上首先讲代码规范,一个程序员写的代码主要个人看,而在给人看的前提是要代码规范. 对我个人而言,其实看到没有规范的代码是看不下去的,自己曾经也犯过代码不规范的毛病,以后这种毛病要改掉. 下面说说结对编程,结对编程有如下的好处: 1.在开发层次,结对编程能提供很好的设计质量,两个人解决问题的能力更强. 2.对开发人员自身来说,能带来自信. 3.在企业管理层次上,有效的交流可以更好地应对人员的流动. 结对编程可以不断的进行复审,可以避免

读书笔记——《构建之法》

谢谢大家能来看我的博客,这是我第一次写博客,大概也会石沉大海吧.但我会逐渐成长,写出更优秀的博客. 那么下面开启正文吧. <构建之法>一书面向初级程序开发者,讲述个人开发.小组开发.团队开发中所要注意到的问题.有助于本学期软工课程的机会,我第一次能够担任一个较大小组(8人)的组长,并带领大家完成自己的小项目.但我深知自身的管理知识是非常贫乏的,又因本书章节很多,所以我特别挑选了几个章节借鉴经验,并且遴选了最有意义的两个章节将精华部分记录下来与大家分享. 第5章团队和流程 团队模式问题是由人数渐

【读书笔记】构建之法(CH7~CH8)

MSF九大原则: 1. 推动信息共享与沟通:"谐",Alert 2. 为共同的远景而工作:目标明确-用户/老板 3. 充分授权和信任: 4. 各司其职,对项目共同负责: 5. 交付增量的价值: 6. 保持敏捷,预期和适应变化: 7. 投资质量: 8. 学习所有的经验: 9. 与顾客合作: MSF团队模型定义了小组同级成员的角色和职责:用户体验.产品管理.项目管理.开发.发布管理.测试.我惊讶地发现,在分配职责时"用户体验"显然不是一项团队的开发活动,MSF使用了&q

读书笔记5—构建之法

第五章--团队和流程      在第五章的团队和流程中,团队有共同的特点:团队有一致的集体目标,团队要一起完成目标.一个团队的成员不一定要同时工作,团队成员有各自的分工,互相依赖合作,共同完成任务.软件团队也有不同的模式.很多软件公司的团队最后都演变成功能团队,简而言之,就是具备不同能力的同事们平等协作,共同完成一个功能.在这个功能完成之后,这些人又重新组织,和别的角色一起去完成下一个功能.他们之间没有管理和被管理的关系.大型软件公司里的不少团队都是采用这种模式.小组内的交流比较频繁.我们在开发

《构建之法》及《大道至简》阅读计划

<大道至简> 2016年3月2日下午2:30开始完成三篇阅读笔记 <构建之法> 2016年3月2日晚上开始阅读并完成两篇 2016年3月4日下午16:30至晚上完成三篇 2016年3月5日早晨完成一篇

[搬家from qzone] 读书笔记 爱是一种选择

因为自己的事情,今晚上会格外的颠簸,暂时就不去体会丰子恺诗一般的语言了,偷个懒,写点自己擅长的. 话说我有一个习惯,就是把愿意跟我深入交流的人变成我的心理咨询对象.时间久了就喜欢分析点什么,比方说每个人的心理倾向的成因,或者为什么总是喜欢轻视别人或者自己.不过这种行为经常受到我家mm的批评,一方面说我不专业,另外一方面说我总是分析别人不分析分析自己.确实,看到别人的毛病总是比承认自己的问题要容易,就让我能随着这本<爱是一种选择>,找找自己内心的缺失,挖掘挖掘自己内心深处那些常常让自己纠结,又看

项目管理学习——《构建之法》读书笔记

最近终于有时间来读读书了.买了<构建之法>已经一年多了,这次静下心来读完了,收获很大.现在想起自己在上大学的时候学习软件工程是机械工业出版社出版的一本外国书籍的翻译版本,当时由于对于整个行业没有太大的感触,而这本书又全部由专业术语和定义组成,所以当时的课是相当痛苦.而老师通过的这门课程的方式又由各种理论知识考试为准,所以当时学习感觉相当“鸡肋”. 好的地方: 1,情景式.对话式对白,有趣易读.这点非常喜欢,很多实际中碰到的问题在这里可以重现.比如:每日构建,在实际开发中,就会由于各种原因导致不