构建之法书评

构建之法这本书从多个层面的介绍了软件工程,我个人认为邹欣老师写的很好尤其是他对于现在的师生关系的定义是非常明确的就是“健身教练和健身学员之间的关系”,这是打破了以往我们对于师生关系的一些错误的理解。他明确的指出了老师和助教可以帮助学员的通过一系列的正确的方式,要让那个学生明白软件工程不是枯燥的,而是特别的生动和有趣,对于开发软件过程中的bug我们不应该把它当作缺陷,而是当作一个功能,一个不能正确的运行的功能。 学习软件工程我们不能只按照老师给我们制定的套路去进行的,你做一个关于软件工程的项目你要有自己的想法,和对于这个软件工程的深刻的理解。我们对于软件工程的理解往往只是做理论的,但是这样完全不够的因为软件工程他是一门实践的课,老师和学生都不能够停留在浅层的理论上而是应该放到实践中从实践中发现并且解决问题,当然实践的方面也会涉及方方面面的问题,但是这些问题不能够通过只通过理论来解决他,因为很多刚开始学这个软件工程的人都是“菜鸟”,他们不懂得把软件运用到实践中。所以如果你只讲理论,那么学生的人数就会越来越少,这可不是老师所希望的结局。
    软件工程是把系统的、有序的、可视化方法应用到开发、运营维护中这样就会遇到各种的问题。例如一个最经典的的问题就是“BUG”,很多人认为BUG就是废材,没有用的东西。但是在邹欣老师的把BUG认为他不是缺陷反而它是一种不能正常发挥的一个功能,所以老师希望我们能够正视你自己的代码的BUG,而不是一味的抛弃他,我们要从BUG中找到有用的信息在软件工程开发的对于BUG的检查。就涉及到单元的测试,单元测试是软件工程开发的一个重要的过程我们对于这个方面一般由作者自己代劳。因为这个是对于你开发时的一个基本的简介所以由作者自己代劳就会使整个程序的或者工程更加的具有可读性,并且更好的去实现他,,当然我们在开发的过程要时刻注意代码的规范问题因为你写的代码不只是是你一个人看,因为软件工程项目的开发会涉及许多的人,所以你的代码规范性就至关重要了。所以一个好的代码不仅要实现好的功能,更要的能让你的团队更好的去维护他。这样目地就达到了。
   邹欣老师所提到的需求分析是软件的核心部位,因为一个好的需求分析是做足市场调查、开发产品的需求、用户的调查我们灯油一个竞争性需求分析框架。我们需要估计项目的进展情况,这里我们不得不提出一个思想就是“分而治之”,时注意划分模块。这都是我们需求分析需要做的各种事情,所以这一步是软件开发的重点,决定一个软件项目的可适性和可实行的重点,真正到了开发的阶段我们必须有我们自己的团队,和我们需要采取的开发的类型在这点上面“敏捷开发”就是一个很典型的例子。这样每个组员都必须有自己的想法和每天的都需要发现自己的问题大家在一起讨论并且去解决他,我们要开发一个能让用户为之疯狂的产品这就需要我们对产品进行一些包装了。对于用户的体验我们需要保证其质量的,这样才能够更好的满足用户。
   这样一个软件工程的开发已经接近尾声了,保证我们可以发布在不同平台,对于每个版本有的BUG进行检测,这样就可以进行事实更新。对于邹欣老师之前对于软件工程的解释我觉得我们想要学好这门课是需要老师和我们学生一起努力并且加油!!!

中国科学技术大学软件学院 + 周赵瑜 + 构架之法—邹欣

时间: 2024-11-10 08:08:00

构建之法书评的相关文章

关于《构建之法》读后感

关于<构建之法>读后感 翻开<构建之法>,第一眼看到的是其他读者对该书的读后感受评语,看了这些评语便引起了我的好奇心,这本书真有他们说的那么好?软件工程留给我的印象说比较枯燥无味的,那么一本关于软件工程的书即便写的再生动形象始终逃不开枯燥不是?可是书评却恰恰相反,这让我有一种想探究竟的冲动在无形中被勾起了. 看了,发现该书真如其他读者反馈的一样,该书是一本写的有血有肉的,具有强大的实用性及超级趣味性,生动形象的让人很容易读懂的书. 该书的内容主要以设置情景,采用一问一答的形式为软件

构建之法现代软件工程

读了邹欣老师著作的<构建之法>以及参考其他众位大神对于本书的书评后,我获益匪浅,具体如下: 首先我觉得邹老师这本书看起来很轻松,当然不是指没含量,实则恰恰相反,只是这里我要更多的突出是另一方面,那就是这本书给读者营造的氛围很轻松,让我不知不觉就看了好多页,内容很丰富,其中有很多的假设,难得的是每一个假设的情景都很活泼形象,与实际很贴切.同时这本书很好的解决的这个知识领域“从零到一”的问题,从一个微型项目最有可能的起步过程开始:组建团队.准备工具.完整的学习一个项目开发过程的指导,这样的设定保证

构建之法——读书笔记(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技能的反面 通过玩魔方的例子说明了技能提升的

《构建之法》——软工学习进度(2)

如何衡量一个软件工程师 如何衡量一个软件工程师?这是<构建之法>第三章的核心问题.第一章讲述了团队的流程,第三章则是对第一章的具体描述,从笼统的团队具体到个人.软件开发流程不光指团队的流程,还包括了个人开发流程,因为软件团队是由个人组成的,简而言之,个人在团队中也有独立的流程.那么问题来了,如果我们去面试,该如何定义我们自身呢?又或者说,看到一个同行的软件工程师,该如何形容他的技术? 第三章通过对足球的比喻,向我们形象的阐述了这个问题的关键.足球中有传接.盘带.射门等具体技术,映射到软件工程上