软件工程-构建之法 阅读笔记

在我正式开始阅读这本书之前,我对于软件工程这个词汇的概念还是模糊的,认为它只是停留在是一门学科,一个专业,或者是一大堆硬生生的理论知识,然而当我读完构建之法这本书的推荐序和第一,第二版前言开始,我就深刻意识到我之前对于软件工程的肤浅认识是多么错误。

  我看书一般喜欢从从书的封面开始看起,或许这也是大多数人看书的习惯,·在本书的封面素描着一副鲁班锁,刚开始让人感觉有点奇怪,明明是一本讲软件工程的书,为什么要用鲁班锁做为封面图案呢?原来玄机深藏于鲁班锁的内部,这鲁班锁从外部看,是严丝合缝的十字立方体,但是各个部件在内部凹凸部分互相咬合,这正是“构建之法”的体现。

  上完数据结构的课程后,或者在更早之前,“程序=数据结构+算法”这句话,就早已深记于心,可是一个实现理论的程序在实际的学习和生活中好像并没有什么用,我们在工作中,老板不可能叫你完成一个求最短路径算法的实现,我们要完成的项目是包括需要求最短路径在内的各种程序的集合,本书中的引例就非常详细并且生动的说明了所谓的程序,软件,软件工程这三者之间的关系,从完成一个随机打印小学二年级的加减法题目,到由此带来的用户和需求,进而扩展为支持例如二元一次方程的,并且网站可以长时间访问的一个工程。从一个简单的程序,扩展到满足各种功能的应用软件,再扩展到能保证维修的软件服务,这正是软件工程的这一“工程”的一步步构建的过程。

  一般来说,软件团队都要用户提出需求开始的,再到软件的整体构建,然后是软件设计,这是各个功能的代码实现阶段,再者是软件测试阶段,测试完之后,投入到实际生活中使用,在实际生活中接受用户的各种各样的反馈,解决bug,维护软件。这是一整个软件开发的流程,再加上对源代码以及项目的管理,构成了软件开发的核心,广义上的软件工程还包括用户体验部分,交互界面的设计部分等等,由此,作者得出一个推论:

               软件 = 程序 + 软件工程

这个推论让我对软件这个概念有了深刻的认识。

然而软件工程这个名词解释是什么呢,作者给出的解释是“·软件工程是把系统的,有序的,可量化的方法应用到软件的开发,运营和维护上的过程;软件工程包括下列领域:软件需求分析,软件设计,软件构建,软件测试和维护;软件工程和下列学科相关:计算机科学,计算机工程,管理学,数学等等。”

从作者讲到的软件的不同开发阶段,也让我对软件的开发有了进一步认识,那就是一个成熟的软件都是从一个玩具模型(简单的程序)开始然后慢慢发展到影响到一个公司或者一群用户的生态系统,例如淘宝和Windows操作系统,如果说这两者都出现了更新上严重错误,那么这将会对人们的生产生活造成巨大的影响。

读完本书的绪论,就激起了我对软件工程巨大的兴趣,也彻底颠覆了我原来对软件及软件工程的理解。一个复杂且庞大的软件的构建过程不亚于一栋大厦的建造过程,用“工程”称其,当之无愧。

时间: 2024-10-05 08:57:33

软件工程-构建之法 阅读笔记的相关文章

构建之法阅读笔记四—团队开发

构建之法阅读笔记—团队开发 软件开发过程中有团队和非团队之分.其区别就在于目标利益的不同,团队中每个人的目标是一致的.共同的,会根据实际情况给每个人分配不同的任务,不会计较个人利益的得失.非团队每个人的目标都是不同的,大家都为自己的利益而奋斗. 在阅读了构建之法后,我了解到团队开发有以下的特点:1.团队开发有一致的集体目标,团队要完成这个目标.一个团队成员不一定要同时工作.2.团队成员有各自的分工,互相依赖合作,共同完成任务.还有完成一个项目开发的工作流有业务建模,需求,分析和设计,实现,测试,

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法阅读笔记6--敏捷开发2

构建之法阅读笔记—敏捷开发2 敏捷开发并不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发:而这种开发方式的主要驱动核心是人:它采用的是迭代式开发:敏捷开发并不是瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据:而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心.而所谓的迭代开

03构建之法阅读笔记之一

构建之法阅读笔记03 遇到问题总是想弄清楚所有细节.所有依赖关系之后再动手,想的太多,没法前进,分析的就会出现错乱,或者直接动手,慢慢发现偏离的一开始的轨道,忘记了目标,这样就会产生"分析麻痹"和"不分主次,想解决所有问题",以后遇到问题应该时刻记住自己的目标,在解决问题的时候不断提醒自己,应该如何思考.越早对自己有一个清晰的定位,对自己越好,很多人只是把软件工程师当成一个工作,当成一个能挣钱养家的营生,而我想把它的当成自己投身的事业,把软件项目相关的目标作为长期的

软件工程概论-构建之法阅读笔记01

<构建之法>这本书主要是以"做中学"为授课方式,它不是只教给我们一些理论性的书本知识,而是让我们在完成一个个的项目时,真正掌握编程的精义,拥有熟练地编写代码的能力. 首先,我们先要确定在这门课上我们和老师的关系,即健身教练和健身学员的关系.因为这样的关系一旦确定.就要求我们每个学生,都是想学好软件工程这门课,而教练即我们的老师,就要根据我们每个学生的不同,制定合适的计划来指导我们的学习. 我们每个学软件工程的人几乎都知道"程序=数据结构+算法".而概论这

《构建之法阅读笔记02》

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

构建之法阅读笔记05

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

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义

构建之法阅读笔记(02)

这一周,通过对构建之法的阅读,对软件以及软件开发有了更加深的体会,一个好的软件工程师,首先要学会与别人合作,要能够包容别人的过失,同时能够发挥自己的长处,个人单枪匹马开发软件,已经很少见了.一个好的软件工程师,要有好的编程习惯,代码的风格与规范,缩进,行宽,以及变量的命名,大小写,能使代码结构清晰,看起来好看,并且简明易读,同时也要有注释,可以让阅读代码的人能够读懂. 在好的编程开发人员,也有犯错的时候,这时候进行代码复审就显得尤为重要,一方面可以学习编程思路,另一方面也能够及时检查出错误,学习