构建之法阅读笔记(一)

学习软件工程这门课程已经有5周了,通过这五周的学习、实验、以及阅读我对软件工程这门课程有了一定的了解。下面就通过对《构建之法》这本书的阅读过程来记录下我最近的感受。

通过课余时间的阅读,《构建之法》这本书我已读完前4章,通过对这四章的阅读,除了对软件工程的基本概念的了解外,我认为我收获最大的就是对软件工程师在公司的定位以及发展有了很大的认识。软件工程就是把系统的,有序的,可量化的方法应用到软件开发,运营和维护上的过程。软件工程包括软件需求分析,软件设计,软件构件,软件测试,和软件维护。同时软件工程还涵盖了许多其他学科。由此可见软件工程并不是我们平时所学的那些固定的计算机方面的相关知识,而是一种方法,一种方法的应用。它详细列出了一个工程是怎么设计完成的,在完成这个工程的过程中要用到哪些知识,要用到哪些方法。这些都是根据不同的工程有不同的详细设计,而我们所学习的就是将这些详细设计的方法进行总结归纳出来的东西。可以说是一种思想吧,他并不是一成不变的。

通过学习软件工程这门课程以及阅读《构建之法》,我对以下几点印象深刻:

首先是对BUG的概念有了新的更加正确的认识。我以前认为BUG就是软件的漏洞,故障,在软件进行正常运行时会出现不知名的错误。其实这种想法是不正确的,BUG是不能这样来定义的。软件行业有这样一句著名的笑话:(BUG)这不是缺陷,这是一个功能。所谓的BUG,对不同的对象来说是不同的。有的人对某个软件或某个功能的要求并不是很高,这样当他拿来一个简单的软件使用时,这个软件满足了他的需求,那么他对这个软件的体验应该是很好的,可是当另一个拿来用时,他对某项功能要求更高,但是他并不知道这个软件对他所设想的功能并不支持,那么当他使用这个软件是体验就会不好,他可能就会说这个软件有BUG,那么这个软件真的有BUG么?通过以上所述,就能大体上解释什么事BUG了。

其次,我对个人开发流程有了跟明确的认识。卡内基梅隆大学针对软件工程师设计了一套模型——PSP(Personal Software Process)。最新的软件工程师的任务清单(PSP)是这样的:


计划

估计这个任务需要多少时间

 备注

开发

分析需求

生成设计文档

设计复审

代码规范

具体设计

具体编码

代码复审

测试

 
 记录用时  
 测试报告   
 计算工作量   
 事后总结   
 提出过程改进计划   

通过对这个表的阅读,我们能够清晰的了解到个人开发流程中应注意到的笔记录下来的东西的,这些东西能够不断提高我们的设计完成水平,同时这也是我们学习晋升的记录和凭证。所以说这些东西是很重要的。另外,在开发过程中的开发测试是更为重要的一件事,在此就不做太多的解释记录了,后面应该会有更为详细的阐述。

下面让我们来看一下软件工程师是如何成长的:

1、积累软件开发相关知识,提升技术技能。例如对某一开发平台的掌握。

2、积累问题领域的只是和经验

3、对通用的软件设计思想和软件工程思想的理解

4、提升职业技能,包括:自我管理能力,表达和交流能力,与人合作的能力,按质按量完成任务的执行力,这些能力在各个领域都非常重要

5、实际成果。产品的展示和市场占有率等等。

以上这几方面对一个初级软件工程师来说是很重要的。另外软件工程师的职业发展也有很多模式,但基于我们现在大学学生的身份,只有考级之路这种模式在一定程度上比较适合我们。我们可以选择其中现对来说有一定含金量的资格考试进行考级。

第四章讲的是两人合作,这章的重点讲的是两人应该如何合作,两人合作的相关方法以及可能经历的阶段。这些对于现在的我们来说还是有一定距离的,当然的在老师的帮助下,我们也都体验了一把两人合作的经历。通过这次经历,我确实认识到两人合作开发的优势,但是我认为这些东西的开展建立在一定的基础上的。这个基础就是我们具备比较深厚的个人开发技术,只有这样,我们在进行合作开发时才能够从中收获到应该收获的东西,比如说合作的经验,合作的流程等等。当我们自身的开发能力相对较弱时,我们结对开发的过程中的重点反而不是合作,而是各自掌握相关的技术,这不就与我们最初的想法背道而驰,我暂时是这么认为的,可能不对,可能我没有更好的认识合作开发。反而在这章的学习中,我收获最大的是代码的规范,这是合作开发的基础。同时这对一个人的代码编写也是一种规范,一种能力的提升,我认为这方面的训练很符合我们现在的情况,因为我们的代码应该说是没什么规范。当然,对合作开发的介绍也非常重要,这对面临毕业的我们是非常好的指导,如果没有这部分的介绍,我们在工作之后肯定会经历更多的困难,我非常庆幸能学到这方面的知识。

通过这5周的学习,我认为我收获到了很多东西,对以后就业也有了相较之前更为清楚的认识。对个人的发展有了较为明确的目标。这些都会在一定程度上减少我们在就业方面的紧张和压力。

时间: 2024-08-02 06:46:31

构建之法阅读笔记(一)的相关文章

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

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

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

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

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

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

03构建之法阅读笔记之一

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

《构建之法阅读笔记02》

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

构建之法阅读笔记05

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

构建之法--阅读笔记二

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

构建之法阅读笔记三

今天阅读了构建之法第四章,对我最深的感触就是代码规范,对于一个软件工程师来说,编程是一项基本技能,程序编的好一半来自于代码的规范:就算你学的算法再好,编程能力再强,代码不规范也没有任何意义.当阅读者拿到你的代码时一头雾水,完全看不懂,这样的代码对于后期的维护和bug的寻找难上加难,或者是对于后来的初学者来说,也是去了教育意义.所以在我们日常的编程过程中要养成代码规范的习惯,习而久之,这样的习惯会一直伴随我们编程整个过程. 还有就是代码复审,我一开始也想不明白,代码为什么要复审呢,写完代码得到执行

构建之法阅读笔记(4)

这周通过阅读构建之法,知道了MSF的原则,团队模型,开发模式. 基本原则: 1.推动信息共享与沟通 2.为共同的远景二=而工作 3.充分授权和信任 4.各司其职,对项目共同负责 5.交付增量的价值 6.保持敏捷,预期和适应变化 7.投资质量 8.学习所有经验 9.与顾客合作 MSF基于一组工作模型,这组模型是由微软公司及其合作伙伴,在与客户成功开发分布式计算和客户服务器应用程序的经验得来的. 简而言之,一个项目要达到的目标很多,MSF团队模型让不同的角色实现这些目标,在一个项目结束时,每个角色都

构建之法阅读笔记(02)

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