构建之法阅读心得(二)

第二章中,作者写到了好的单元测试的标:单元测试应该在最基本的功能/参数上验证程序的正确性、单元测试必须由最熟悉的人来写、单元测试过后,机器状态保持不变、单元测试要快、单元测试应该产生可重复、一致的结果。独立性——单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性。单元测试应该覆盖所有代码路径,但是100%的代码覆盖率并不等同于100%的正确性、单元测试应该集成到自动测试的框架中、单元测试必须和产品代码一起保存和维护。

程序要进行单元测试来保证程序的健壮性。

还要进行回归测试,就是在原版本上运行的测试用例通过的话,在下一版本上再运行时,却没有通过,这就是软件"退化",所以需要进行回归测试。在新版本上运行所有已经通过的测试用例,来验证后面的版本没有出现软件"退化"的情况。

但是如果是模块功能发生了变化,那么测试用例也需要修改来测试新的模块。

程序还要进行效能分析,这个是以前从来没有了解过的。就是找出程序运行时,哪个函数或方法消耗的时间多,就是程序运行的瓶颈所在,进行效能分析,从而对相应模块的代码进行优化。进行效能分析的方法有抽样和代码注入,各有优缺点。不过普遍用的是先用抽样方法找到瓶颈所在,然后对特定模块的代码用代码注入的方法进行详细分析。还要注意避免没有做分析就过早进行"效能提高"。

对程序员或者工程师是有能力成熟度模型的。工程师在需求分析和测试上花的时间更多,而在具体编码中比大学生花的时间少一半多,从学生到职业程序员,以后在写代码的时间会少很多,更多是用在分析上。

时间: 2024-10-13 09:03:38

构建之法阅读心得(二)的相关文章

构建之法--阅读笔记二

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

构建之法阅读笔记二。

过了很久,也可以说是有了编写一个软件的经验回来再看构建之法这本书,对于这本理解是不同的.我刚好看到代码复审这里,而且在小组里也可以算是说是承担了代码复审这个模块.与书中说的一样,在单元测试中成功的功能模块,连接到主程序中确实出现着错误.也是这样,我们也反复修改了好多次代码.另一方面就是,我们的界面一开始都是用Windows builder创建,所以还需要后期调整代码规范.但是相对于书上所介绍到的代码复审过程,还缺少了复审标记,审核表部分.可能是因为我们小组交流起来很方便吧.令我惊喜的是,在书中确

构建之法阅读心得(六)

构建之法第六章,本章为敏捷流程,主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论,各种软件开发方法论的优缺点,选择软件流程根据等. 敏捷开发:是一系列价值观和方法论的集合 敏捷开发的原则: 1.尽早并持续地交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分

构建之法阅读心得(五)

本章为团队和流程,主要介绍了典型的软件团队模式和开发流程以及它们的优缺点.TSP.MVP.MBP.RUP 团队:并不是几个人凑到一起就叫团队,称之为团队.应该有一致的集体目标,团队要一起完成这目标.团队成员有各自的分工,互相依赖合作,共同完成任务. 软件团队的模式:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式. 开发模式:写了再改模式.瀑布模式.瀑布模式的变形:1>生鱼片模型2>大瀑布带着小瀑布.Rational Unif

构建之法阅读笔记二

快到期末了,我想一想老师留的任务,才写了一篇,今天拿起来又看了一部分,看到了有关代码规范这一方面,结合最近老师留的大作业,对此深有体会,谈谈我自己对此的一些看法. 还记得在大一一开始上的第一堂专业课上,教我们c++的王辉老师就说过,想要做一名合格的工程师,代码规范是基础中的基础,但是在当时我相信大多数人包括我自己都是左耳朵进右耳朵出,根本没在意,虽然在以后的课上老师也会时常提醒我们,可是,感觉也没什么效果,现在的我回想起那时对代码规范的理解,简直那啥...当时的我自以为代码规范不就是形成自己的写

构建之法阅读随笔二

谁不喜欢创新呢?然而细细想来,创新就是做和以前不一样的事,并不是所有的人都喜欢"不一样".当你提出一个创新的想法时,你会得到什么回答呢?为什么我辛辛苦苦想出来的点子得不到领导或同事的赞赏?这里面有好几个原因: 个人自负/嫉妒 这个想法居然被你想出来了,老子不能接受 面子或政治因素  这个东西要是搞成了,我很没面子 优先级  我已经有10个创新的点子,没有时间和资源去处理新的想法 安全  不创新,我没有风险:要创新,我可能要失去一些东西 习惯  这不是我们做事的习惯,不符合我们一贯的原则

构建之法阅读心得(七)

第七章介绍了微软公司的MSF,这让我们对微软又有了更深一层的了解,原来微软采取这样的理念.很小的时候就开始接触微软产品,windows系列的操作系统.办公软件等:那时候只是知道微软是一个很强大的软件公司.之所以成为一个强大的公司,功劳在于微软的MSF,而MSF中的基本原则又是很多IT行业者的追求,想必所有IT者都以进入微软为目标吧..MSF的最大特性是商业化,并一直体现在项目的实施过程中. 所谓商业化意味着客户的商业利益.客户投入多少,得到多少回报,客户要用到哪些最新的技术,最后如何把项目计划(

构建之法阅读心得(三)

第三章讲的是软件工程师的成长.个人能力的衡量与发展,软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的,在团队的大流程中,是每一个具体的个人在做开发.测试.用户界面设计.管理.交流等工作.因此,个人在团队中也有独立的流程. 初级软件工程师有以下几种成长:积累软件开发相关的知识,提升技术技能.积累问题领域的知识和经验.对通用的软件设计思想和软件工程思想的理解.提升职业技能.实际成果. 软件流程TSP对团队成员也有要求:交流.说到做到.接受团队赋予的角色并按角色要求工作.全

为什么报计算机还有阅读构建之法的心得

1.为什么选择计算机这个专业; 当初读本科的时候,一志愿填的是电气工程及其自动化,估计是因为分数太低了被调剂到了网络工程专业.之前的我并没有过多的接触计算机,感觉自己对这方面并没有多大的兴趣,本科的时候自己的学习并没有多么的认真.当时自己还想过要转专业,后来也不了了之了.慢慢的感觉这个专业还可以,也就学了三年,后来到了考研的时候,本来打算考金融专业的,但是跨专业考研难度挺大的,而且最近几年计算机这个专业实在是太火了,毕业之后工作找工作各方面都不错然后就限定决心考了计算机技术.庆幸的是考上了,现在