Book Review 《构建之法》

  1. -首先浏览了一遍《构建之法》这本书的前言,其中通过客观的描述性介绍了学生与学习、老师与教学、以及学习的环境、方法等等。但是对于书中前言包括正文都频繁出现的一个词语 “文档” 深表疑问.何为文档,是指带代码?还是另有其他含义。
  2. -接着看下去,第一章用前言的风格,阐述了软件含义,软件工程与计算机科学,Bug.对于软件的阶段性,个人理解来说就是软件是要一步步来提升完善.由开始的感兴趣到动手出成品再到完善维护这都是一步一步来进行的.软件工程是为了某个特定的目的而专门建立的一个项目工程,所谓工程就有一定的层次性这一点也是跟程序开发是类似的具有阶段性.书中也是提及计算机科学和软件工程的侧重点.前者就像是JAVA 中的主类,而后者是子类。 软件工程 的进展会为 计算机科学 提供跟多的“资源”,帮助科学家做跟多的实验探索。而计算机科学得进展会提高软件工程的正确性.就像是父类对子类的一个完善,提升.子类对父类的一个反馈。最后是Bug这个词,以前的理解就是系统出现的漏洞,不完善的地方,指代不好的东西、地方.而书中给出了另一种说法"Bug 就是软件的行为和用户的期望值不一样.",没有褒贬的意味。这个倒是有点出乎意料,但也是很生动的体现出程序的针对性.不合适就是不好 !
  3. -第二章的一开始就出现了”单元测试“.呵呵,这个正是上次作业老师给的一个建议。在看了第二章之后觉得对单元测试有了一个模糊的理解.没有十分的清晰的概念,感觉就是增加模块去捕捉软件运行出现的错误并给予提示。这里希望老师可以指点下”单元测试“的具体意思- 。-
  4. -至于第三章关于软件工程师的成长:在学习阶段首先就是要对自己有一个全面提升,无论在专业技能,还是经验、思想等。再在实践中根据自己的情况选择在哪个方面追求“专和精”,在那几个方面达到“知道就好“的水平.来提高自己的核心竞争力。
  5. -第四章两人合作,一个团队中需要有统一的代码风格。在结对编程的过程中要时刻进行复审.换句话说就是要自我复审、同伴复审、团队复审。更正并且记录下错误,进行一个自我的提升.无论结对还是团队都是有一定的阶段性的,并且都是可以提高程序总体的质量的。但是这都是有前提:“必须有一个团队、结对”,那么在进行结对也好团队合作也罢前,岂不是要花费很多时间去找合适同伴,相互磨合.不然中途如果发生激烈的冲突导致解体的话就会对整个项目造成致命伤害了?
  6. -在两人合作之后就是团队合作,在第五章中强调了团队合作的各种模式:社区、业余剧团、秘密团队、特工团队、交响乐团队等等很多种模式,适合各种不同类型的项目,具备自己的优点短处。在书中强调出团队之间队员的关系与分工,还有就是项目的流程。一个团队要想成功合作,那就离不开模式指引,而一个项目需要模型来引路。那么一个团队如何去确定一个合适的团队模式呢?一个项目怎么知道那种流程是最好的呢?
时间: 2024-11-08 21:49:27

Book Review 《构建之法》的相关文章

回望来时的路:构建之法东北师大站 2016春季学期

1.  前因 微软邹欣老师著有<构建之法:现代软件工程>[https://book.douban.com/subject/26577755/].第一版首版以前,我还不知道邹老师是哪一位,就在网上曾经看到过有人转引他的观点,感到说得太有道理了,一拍大腿的感觉.比如他提到教师和学生之间应该是健身教练和学员间的关系,不是教师带领学生参观浏览,也不是狱警和囚徒的关系.比如他批评没有代码量的软件工程教学.<构建之法>到手,第一遍粗读我花了一周的时间,酣畅淋漓.很多处让你再拍大腿,"

我读经典(8):以独特的视角来看软件工程--读《构建之法:现代软件工程》有感

?? 对于计算机相关专业的学生来说,我们学习了很多的专业课程,像编程语言.算法.数据结构.编译原理.软件工程等.很多学生都会有这样的疑问:我学了这么多的课程有什么用呢?在工作中有多少会真正被应用到呢?也就是说,大家都觉得理论和实践之间有着不可逾越的鸿沟.邹欣老师的<构建之法:现代软件工程>一书很好地,并且巧妙地将理论和实践结合了起来. 继<移山之道>.<编程之美>之后,邹欣老师再推新作<构建之法:现代软件工程>,将软件工作的方方面面生动活泼地呈现在了大家(尤

速读《构建之法(第三版)》 20199319

本周速读了<构建之法(第三版)>,本书共有十七个章节(如下图所示),介绍了软件工程的方方面面,干货满满.在速读完成后我思考了以下几个问题. 1.目前流行的几种源程序版本管理软件和项目管理软件各有什么优缺点? Microsoft TFS 微软的团队代码管理服务平台Team Foundation(通常记作"TFS")是一种为 Microsoft产品提供源代码管理.数据收集.报告和项目跟踪,而为协作软件开发的项目. 优点:TFS功能非常强大.微软对于个人或小团队推出了免费的TFS

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

简读《构建之法》,所想问题展示

1,<构建之法>这本书全局语言通俗,学生很容易读懂,但是存在一个隐患:学过软件工程,我们只是笼统的理解,而对这方面的专业知识很少了解,该怎么办? 2,书中提到的软件结构,软件设计与实现具体是怎样的?怎么理解它们之间的关系? 3,软件在不断更新和增加功能的负担下,一定程度下会崩溃.若有一个软件,即将考虑添加下一个功能,但是在添加这个功能之后,系统一定会崩溃,但是这个功能对这个软件的市场前景起着至关重要的作用,这是该怎么办? 4,软件设计和软件构建有区别吗?不同之处是什么? 5,当软件中的依赖关系

构建之法阅读笔记05

2017.5.20 今天阅读的是<构建之法>第8章需求分析的阅读笔记,我们如果要开始做一个软件,最先要进行的就是需求分析,我们应该充分的了解我们这个软件是否具有前景,我们为用户提供的服务是不是用户所需要的,这一章详细的叙述了如何进行需求分析. 首先是获取和引导需求,我们应该找到软件的利益相关者,了解挖掘他们对软件的需求,引导他们表达出真实的需求.然后分析和定义需求,对各个方面的需求进行规整,定义需求内涵,从各个角度将需求量化,然后估计实现这些需求所需要的时间和资源,确定各个需求的优先级.紧接着

《构建之法》学习(5)——团队和流程

<构建之法>学习(5)--团队和流程 1.非团队和团队   团队共同的特点: 团队有一致的集体目标,团队要一起完成这目标 团队成员有各自的分工,互相依赖合作,共同完成任务 2.软件团队的模式       一窝蜂模式       主治医师模式 有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作.       明星模式 主治医师模式运用到极点,可以蜕化为明星模式,在这里,明星的光芒盖过了团队其他人的总和.       社区模式 社区由很多志愿者参与,每个人参与自己

《构建之法》学习(3)——软件工程师的成长

<构建之法>学习(3)--软件工程师的成长 1.1个人能力的衡量与发展 积累软件开发相关的知识,提升技术技能 积累问题领域的知识和经验 对通用的软件设计思想和软件工程思想的理解 提升职业技能 实际成果      衡量软件开发的工作量和质量 项目/任务有多大? 花了多少时间? 质量如何? 是否按时交付? 1.2软件工程师的职业发展 职业发展--考级之路 职业成长--Steve McConnell版本 职业成长--大公司版本 职业成长--自我评估 1.3技能的反面 通过玩魔方的例子说明了技能提升的