《构建之法》速览笔记

花了一段时间快速浏览了一遍邹欣老师的《构建之法》这本书,在这里对我的首次阅读做一个小小的总结和疑问。当我翻到这本书的目录时,我首先的第一感想就是,这本书应该是关于现代软件工程管理学的书籍,但是在我快速浏览完了它的电子书时,对它又有了一个新的定位,这本书特别适合我们这些对软件工程半知半解的学生。不知道我的理解是否贴切,书中关于“敏捷开发”这一章节,我个人感觉有点像去年政府提出的“简政放权”--做好政府权力“减法”换取企业市场活力的“乘法”,公司上层领导放权,使得PM带领团队放手去做。那其中我也产生了一些疑问,望老师给予解答:

(1)在“敏捷”开发这部分中间有提到“敏捷 (Agile)”开发周期短,团队人员数量不多,方便用户增加或更改需求,但产品可靠性不高,选用”敏捷“开发软件,我们如何保证最终做出来的产品的可靠性,关于这点如何解决,在后期的维护成本是否就会有所上升?

(2)团队中每个人员的能力是有差异的,能力有高低,毕竟有所局限(像所精通的编码语言不同),成员所负责的模块是通过什么来分配任务的呢,是否有什么方式方法来做为一个衡量标准?“敏捷”适合哪种团队进行开发?如果团队刚刚建立起来,正处在相互了解相互磨合的阶段,进行软件开发是不是就不太适合采用“敏捷”思想,

(3)IT行业的变化基本上是日新月异的,MSF团队是如何跟上这种变化的呢?

就像一个软件刚刚投入使用,IT行业的思想和技术发生了改变,那么刚投入使用的软件在某些模块就过时了,此时,此时MSF团队是否又要根据目前的市场进行修改测试,那它的成本和生命周期就会有所提高.

(4)单元测试是回归测试的基础,那我可不可以这样理解:单元测试应该是对软件的各个模块分别进行测试,同时必须和代码一起进行版本维护,这是在开发过程中必须要做的事情。当在所有模块已经全部完成,再对所有功能进行整合的时候进行回归测试,找出软件中存在的bug,同时进行修复。

《构建之法》这本书的实例很多,实用性很强,它所讲述的内容,目前只能在后期自己动手做软件的过程中才能进一步实现,望老师批评斧正!

时间: 2024-10-08 00:12:29

《构建之法》速览笔记的相关文章

《构建之法》阅读笔记一

1.程序=数据结构+算法 2.构建管理,源代码管理,软件设计,软件测试,项目管理是软件工程的核心部分. 3.软件=程序+软件工程 4.软件企业=软件+商业模式 5.软件开发的不同阶段:玩具阶段,业余爱好阶段,探索阶段,成熟的产业阶段 6.软件工程是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程 7.软件工程包括:软件需求分析,软件设计,软件构建,软件测试和软件维护等领域 8.软件的特殊性:复杂性,不可见性,易变性,服从性,非连续性 9. 软件工程的目标--创造"足够好&quo

《构建之法》阅读笔记(1)

<构建之法>第一章阅读笔记 大马哈鱼洄游模型 软件工程按照经典的瀑布模型 1. 需求分析 2. 设计阶段 3. 实现阶段 4. 稳定阶段 5. 发布阶段 6. 维护阶段 事实上在现实世界中,软件工程师的职业发展与瀑布流程刚好相反 毕业进入公司(或者实习生),开始学习并维护一些已有的软件(维护阶段),主要由自己的师傅(Mentor)带领 能够在项目中改一些 Bug,然后发现发布小规模的更新版本(稳定/发布阶段),联系重构,开始和其他同事打交道 有机会负责重写一个较小的模块,没有多少文档,自己要写

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

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

《构建之法》读书笔记之:第一、二、十六章

这周看了邹欣老师<构建之法>的1,2,16章,获益匪浅.这本书写得妙趣横生,用阿超小飞几个人的生活场景和幽默的比喻帮我理解着软件工程的相关概念,让我对软件工程有了初步的了解:原来开发软件并不是我们想的那样简单:上手直接敲代码就可以了,而是会有一套详细的流程规范.下面是我看书时的一些心得笔记,和一些无法自己解答的疑惑,烦请各位老师批评指教. 第一章: 笔记: 软件=程序+软件工程,是否可以通俗地理解为,程序只是死的机器的东西,为什么做(需求分析),做什么(软件设计),做完后这东西是否可行(软件测

《构建之法》读书笔记二

这周读了<构建之法>的第二章.第二章主要讲到了个人技术和流程. 软件是由多人合作完成的,不同人员的工作相互有依赖关系.一个团队需要一定的流程来管理开发活动,每个工程师在软件生命周期所做的工作也应该有一个流程.所以就引进了一个新的名词叫做PSP--个人软件开发流程.但是要做到每个人的模块的质量得到稳定.量化的保证,单元测试就是一个很有效的解决方案.我们可以用vsts写单元测试,这是一个新的软件,我从来没有接触过,所以也不会用.只看了一下代码. 好的单元测试应该准确.快速地保证程序基本模块的正确性

《构建之法》阅读笔记01

这一学期,开始了健民老师的软件工程概论课,早就听闻健民老师的软件工程概论课很牛,听了两节课下来,果然如此. 老师引用了<构建之法>书中的理念,认为软件不是靠着理论堆积而成,而是一个个实发的项目组成的,在课上,老师引用了书中的例子来形容学生和老师的关系. 1.餐馆服务员/食客 2.老板/雇员 3.保姆/幼儿:像保姆一样操办一切 4.哥们/哥们:一起混吧 5.路人甲/路人乙 6.狱警/犯人:想法点名/想法逃课 7.健身教练/健身学员:鼓励成长 当然,大家都更加喜欢7,希望能够获得更多的编程技能和知

《构建之法》阅读笔记(2)

<构件之法>阅读笔记2 看了前面两章,我感觉我现阶段距离一个程序员还很远,软件工程师更是遥不可及.在学校的我学习了很多,如c++,数据结构,面向对象--学的多而不精,纵观现在我就是一个盲目学习的学生,上课时认真听了课后却没有花更多的时间去研究,遇到不懂的容易掉价死胡同,总是花很多时间闷闷思考,不到最后都没有去请教同学,去百度.看着其他很厉害的同学,自己就只能在一旁羡慕嫉妒恨.那现在在怎么样才能将自己对编程的兴趣提高,加强自己的编程思想?提高自己的价值?能够尽早地迈进程序员.软件工程师的行列之中

《构建之法》阅读笔记(一)

阅读第一章所得: 就像上半学期学到的那样:程序=数据结构+算法,通过阅读<构建之法>的第一章后,更加清晰的认识到:软件=程序+软件工程.也清楚的意识到我现在的水平也只是略懂皮毛,书中也提到了软件开发的4个阶段,分别是玩具阶段.业余爱好阶段.探索阶段.成熟的产业阶段.我现在就是处于玩具阶段向业余爱好阶段的过渡阶段,即写程序练习,并用新的语言如JAVA尝试C语言的程序,这么说来......大一至今是处于玩具阶段的状态.如果大学时期好好学习,按部就班,即精通老师教授的语言,那么等到毕业时,就像书中说

《构建之法》阅读笔记04

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚