《构建之法》读后感3

第6章 敏捷流程 —— 6.5 敏捷的故事

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

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

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

4.  第6章 敏捷流程 —— 6.5 敏捷的故事

  这一小节提到了几种比较出名的敏捷开发方法论,如FDD、Scrum、XP、TDD。前三者在书中都有专门的介绍,但TDD,久闻其大名,到底是何许妙招?

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

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

  ① 快速新增一个测试

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

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

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

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

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

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

时间: 2024-10-25 21:36:16

《构建之法》读后感3的相关文章

【最后的总结】人月神话读后感

人月神话读后感 这本300多页(中文新版)的神书,在经过了20多年的历史之后,仍然畅销不衰,究竟是什么让它有如此的魅力?过去的一个月,一点一滴的阅读之中算是初步的了解到了它的一部分吧. 人月神话的核心观点:概念完整性和架构师 Brooks认为,一个整洁.优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用,实现应用的方法以及用来指明操作和各种参数的用户界面使用策略.概念的完整性是易用性中最重要的因素.而架构师,则是负责保证产品所有方面的概念完整性的,架构师设计的是能够让

人月神话读后感

书中应用焦油坑表示过去几十年的大型系统开发,很多大型和强壮的动物在其中剧烈挣扎.让我感觉到,软件开发过程中所遇到困难是多么的多,开发多么艰难.但是这本书同时告诉了我们软件的开发有苦也有乐,我们可以在编程过程中体会那份快乐.<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关

人月神话读后感2

<人月神话>是为软件开发经验的天马行空总结.比<Beautiful code>更为有远见,把我从充实代码的清晰简介升华,拓展到软件开发的高层度, 一个周密,准确,明朗的开发需求分析,可行性研究,软件实现是软件开发的完美递进. 人与神话中讲述人力和时间并不体现线性关系.指出以大量人员和较短的时间,并不能缩短软件的开发进度.一窝蜂的作业方式无助于软件生产,且会制造麻烦,产生出更差的软件.向进度落后的项目追加人力,只会使进度更加落后.所有的编程人员都应该是乐观主义.人数和时间的呼唤仅仅适

人月神话读后感(三)

作为软件工程的经典著作,<人月神话>的主要贡献是对软件开发过程的几个重要关键点,提出了独到的见解. 其中内容就是: (1)提倡外科手术式的团队组织: 在软件开发组织上的过份民主,往往带来的是没有效率和责任,参与其中的人想法太多,层面参差不齐.所以,软件开发的组织,应该借鉴外科手术式的团队方式,有一个主要的负责人,其他人都是分工协作的副手,这样效率最好,结果最好.(2)软件项目的核心概念要由很少的人来完成,以保证 概念的完整性: 少就是多,项目的定位需要和功能多少的权衡.太多的想法,使项目没有焦

人月神话读后感三

人月神话阅读笔记之三 之前从来没有注重过文档的重要性,想起啥就写啥,从来没有整理过思绪和想法就是想写啥写啥,不会在乎太多的问题. 但是看完这本书以后就明白了很多,这样的做法是很错误的一种行为,作者强调文档的重要性,他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座.但是效果都非常的的不好,他们知道如何来写出优秀的文档,但是他们缺乏热情.所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作.结果显示这种方法的效果还是挺好的. 以后写程序一定要先写好文档,要不自己

人月神话-读后感2

文章主要讲了在软件开发工程项目中,时间和人员数量上的转化关系.表明了在一个项目中增加人员的数量不一定能够缩短项目完成的时间,很多时候还会起到相反的作用.正如Brooks法则中所说的那样“想进度落后的项目中增加人手,只会使进度更加落后”. 在软件项目中,缺乏合理的时间进度使造成项目滞后的最主要的原因.造成这个结果主要由于以下几个方面,包括我们对工程的乐观的估计,错误的认为人和月(时间)可以无条件的相互替代,软件经理不合理的估算和缺少对进度的跟踪和监督. 在编程人员中弥漫着乐观主义,他们通常会认为一

人月神话 读后感(1)

在软件领域,很少能有像<人月神话>一样具有深远影响力和畅销不衰的著作.这本书可以称得上是软件行业的圣经,因此我怀着好奇的心态翻阅这本书. 一下是我对文章内容的摘抄与一些自己的理解. 第一章焦油坑 讲的是一入软件这个行业好似掉入焦油坑,快乐与烦恼并存.编程行业为什么有趣,因为它不仅满足了我们内心深处进行创造的渴望,而且唤醒了每个人内心的情感,软件的乐趣便在于他独一无二的创造性,在与创造出对其他人有用的产品那种满足感. 当然烦恼是过程很枯燥,遇到bug时寻找和修改的过程充满了枯燥.这就是编程,一个

人月神话读后感03

“四套马车”讲团队配合.书中所讲是常见的小规模的软件开发公司的情况,如何合理的分配各项任务使得开发工作顺利的完成对这些小公司来说确实是问题.但对于目前我所在的公司,暂时不存在这样的问题.毕竟部门的规模还是有的,70人,任务也单一,只是软件测试,除了有时任务较多显得有点忙以外,基本上还是能应付的过来.但是其中提到一些问题和建议还是可以用到的. 比如书中提到使用专业和高级的工具未必就能提高工作效率和质量,这一点对我有很大的惊醒作用.我往常还是很迷信这些一些好的工具和好的制度,以为有了这些,整个流程,

人月神话读后感(一)

感受一,软件编程职业的乐与苦 如文中所说,编程的乐趣在于创造事物,如小孩玩泥巴一样,创造出了自己的东西,这种魔术般的,上帝一般的感觉确实吸引着我,从无到有,从最开始的构思到一步一步的逐渐实现并完善一个项目,最后得出能用的东西,这种成就感是令人满足的,但是任何事物有乐就有苦,编程也是如此,我目前所直接感受到的就是在编码过程中无限的BUG需要去解决,解决-测试,测试-解决,用以完善自己的思路,这种过程是比较乏味,枯燥的,但却是,说心底话,只有多经历这种过程,多去见识那些BUG,并且努力去解决他们,这

人月神话读后感(二)

感受一,一个项目概念的完整性非常重要 概念上统一的系统能更快地开发和测试,为了实现这个目标,设计必须由一个人或者具有共识的小型团队来完成. 一个团队必须保持概念的完整性,才能使团队高效的运作,方向一致. 感受二,交流对项目开发起着至关重要的作用 巴比伦塔项目的失败是因为缺乏交流,以及交流的结果--组织 在本书中,多次提到了要非常多的进行交流,在他开发的System360中,有很多交流的方式,有每周一次的汇报会议,到每月一次的大会,还有不断修订的项目工作手册 ,以及实现人员随时可以像结构设计人员询