《构建之法》5.5,6,7章读后感

1.第五章的第三节提到瀑布模式的各种变形,其实老师觉得哪种是最好的,变形好,还是不变形好?

2.第六章说的敏捷,什么才算是敏捷?敏捷的团队与普通团队的差别在哪?就像新浪微博突然搞了一个微博丢失,用户写的微博都没了,新浪当时用半小时的时间就恢复了数据,他们用了什么样的方法来找回丢失的数据的呢?

3.第七章提到MSF,MSF具体是怎样的?

时间: 2024-10-22 10:50:19

《构建之法》5.5,6,7章读后感的相关文章

《构建之法》之第一二三章读后感

读<构建之法>这本书就像读故事书那样,耐人寻味,又很多故事和经验都是源自作者本身,读起来很有趣,并不会像其他书那样的枯燥乏味. 这本书的第一章——概论,为我们解释什么是软件,什么是软件工程,读完这章对这些概念有一定的认识这章让我明白,代码不能盲目的敲,好的软件并非两三天内就能赶出来的.在编写程序之前,需要做一系列的分析.设计,要满足客户的需求,后续还要对软件进行测试.维护等.在这之前,我一直觉得能把程序运行,能有正确的结果,那就完成任务了,可这只是整个软件流程的一部分而已. 问题:目前软件工程

《构建之法》之第四章读后感

<构造之法>第四章主要讲一些两人合作前的基础,以及两人合作对于成功的重要性,两人合作是两个人的不断磨合.适应.与进步. 本章大篇幅讲了两人合作需要的准备,例如代码的规范,这非常重要,如果你的代码,只有你一个人看得懂,这十分不利于团队合作,再好的代码,不能被别人知道,这还是一个不好的程序,因此代码规范非常重要.优秀的代码应该遵守的原则是:简明.易懂.无二义性.我们在规范代码时要注意缩进.行宽.括号.断行.空号等的规范与使用.我们要养成良好的写代码的习惯,注意程序的命名,我们要用英文命名,不能随便

《构建之法》第十六章读后感更正

第十六章IT行业的创新 1.关于灵感.灵光闪现固然重要,很多伟大的发明依靠的就是灵光一现的基础,但是灵光闪现的前提是个人的思考,长时间的思考.完成这一灵光的基础是不断的尝试,提高自己的技术.这样才会将自己的灵光变成一个实物而不是空想. 2.关于喜好.并不是人人都喜欢创新,因为创新本来就是个长耗时又难以被认可的东西.创新有需要考虑的因素有许多,个人.面子.优先级等等,现在人们更多的是支持在原有材料技术上的"线性发展"--扩充功能等. 3.关于想法.人们接受的并不是好的想法而是他们所需要的

《构建之法》第11,12章读后感

第11章 软件设计与实现 1.  关于小飞拿到spec之后做的估计开发任务所需时间,他是根据以前同类任务所需花费的实际时间以及其他同事的时间估计的.以现阶段我们学生的角度,该如何估计一个项目开发所需时间呢? 2.  修改集是什么?集成是什么意思?怎么样才是集成呢? 3.  每日构建是什么意思呢? 每日构建意味着自动地,每天,完整地构建整个代码树.(译者按:"代码树",原文为source tree,        意思是将整个项目源代码的目录,子目录,文件的位置尽可能事先固定下来,这样在

《构建之法》8,9,10章读后感和总结

第八章:需求分析 需求分析,我觉得需求分析挺重要的,一个需求分析是指对要解决的问题进行详细的分析,弄清楚问题的要求,包括需要输入什么数据,要得到什么结果,最后应输出什么.可以说,在软件工程当中的"需求分析"就是确定要计算机"做什么",要达到什么样的效果.可以说需求分析是做系统之前必做的.需求分析确定了整个团队的方向,那么怎么做好需求分析呢?有以下几个步骤:1.获取和引导需求:2.分析和定义需求:3.验证需求:4.在软件产品的生命周期中管理需求. 第九章:项目经理0

构建之法第六、七章读后感

第六章 Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的.迭代的开发过程.Scrum包括了一系列实践和预定义角色的过程骨架.Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员. 敏捷流程一共有4步: 第一步:弄懂需求与任务是相互依赖的关系 第二步:想要学会把一个任务从产品层级的描述逐步细化到技术实现层面,那么技术能力和交流能力尤为重要的,根据每个人的能力来分配任务以保证任务的高效完成. 第三步:个人要

《构建之法》第6~7章读后感

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的.迭代的开发过程.Scrum以经验性过程控制理论(经验主义)做为理论基础的过程.经验主义主张知识源于经验, 以及基于已知的东西做决定.Scrum 采用迭代.增量的方法来优化可预见性并控制风险.第六章主要讲敏捷流程概述:第一步:找出完成产品需要做的事情——Product Bocklog.第二步:决定当前德尔冲刺(Sprint)需要解决的事情——Sprint Backlog.第三步:冲刺(Sprint).第四步:得到软件的一个增量版本,发

《构建之法》1.2.3章读后感

第一章 这章就是通过一些比喻来确定软件的概念,而我们就是要知道我们如何去面对客户所提的要求,让我们去通过编写软件去满足客户的要求.而我们也就要了解怎么去学好软件的编写. 我们需要通过在不同的程序语言实现同一个客户的简单要求.从中得到自己需要的经验来让自己进步. 问题:如何正确去理解软件和代码之间的关系? 第二章 软件需要单元测试我是没想过的,但是我觉得测验可以让我们把上段时间掌握的知识巩固,因为前期的代码还比较简单,但后期的代码比较困难就可能觉得测试不好了.这章就是让我们自己去做好自己的那份工作

《构建之法》第6~7章读后感和对Scrum的理解

第6章 敏捷流程 “敏捷流程”是一系列价值观和方法论的集合.从2001年开始,一些软件界的专家开始倡导“敏捷”的价值观和流程, 他们肯定了流行做法的价值,但是强调敏捷的做法更能带来价值. 敏捷开发原则: 1.尽早并持续地交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,

《构建之法》第六七章读后感

  Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的.迭代的开发过程.在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议 长度是2到4周(互联网产品研发可以使用1周的Sprint).在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照 商业价值排序的需求列表,列表条目的体现形式通常为用户故事.Scrum团队总是先开发对客户具有较高价值的需求.在Sprint中,Scrum团队从产 品Back