《构建之法》第一、二、十六章阅读笔记

第一章

问题一:1.2.4软件工程的目标--创造"足够好"的软件

什么是好软件?

原文1.一些同学认为,所谓好软件,就是软件没有Bug,所谓软件工程,就是把软件中的Bug都消灭掉的过程。

软件的行为和用户的期望值不一样就叫Bug。

原文2.Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。

首先对于第一点来说,我觉得无论多么好的一个软件或多或少都会有Bug,只不过是在用户体验的过程中让用户尽可能少的感受到缺陷,尽可能提高用户的使用效率,这就是一个足够好的软件。而软件的行为和用户的期望值,我认为是针对开发者群体和用户群体来说的。对开发者来说通过一定的软件流程,在预计时间内发布出符合用户需求,可维护、可继续发展的软件就是创造了一款比较好的软件,但是一旦用户增加可能会引发系统崩溃等一系列问题,这就是Bug。对于用户来说,用户希望的是随时都能让软件正常使用,满足自己的需求,一旦软件出现问题,不能满足用户的需要,也是Bug。就比如说火车购票的软件,我认为那是一个非常优秀的软件,高峰时期一秒钟可以出售700张车票,这对一个业界的开发者来说做的已经很优秀了。但是面对强大的购票群体来说,一秒钟700张票仍然无法满足人们的需求,与用户的期望不一样,也是一种BUG。

第二点对于现阶段的我来说这些概念可能会比较深一点,比如说我现在所接触到的东西是一些简单的前后端开发,我们在运行的过程中遇见的比较普通的错误,找到错误位置,增加一点或者删除一点就好了。但是对于那种比较大的项目来说,我们应该如何通过Bug从代码的角度更加细致更加具体的来分析软件的开发效率、可靠性和可维护性,衡量软件是否足够好。还有就是,我们应该如何构建出这种开发体系?

第二章

个人感觉第二章有点不太懂,看了几遍还是很懵。刚看的时候就觉得一直在题代码覆盖率,但是不是很清楚是什么概念,然后看了几篇博客,有了简单的认识,还有单元测试、回归测试、效能分析这些概念感觉比较新,需要点时间来详细了解。

代码覆盖率浅谈:http://www.cnblogs.com/coderzh/archive/2009/03/29/1424344.html

代码覆盖率分析:http://blog.csdn.net/ffeiffei/article/details/6579280

如何编写单元测试:http://www.cnblogs.com/mq0036/p/4100084.html

问题一:

通常代码覆盖率被拿来作为衡量单元测试好坏的指标。

原文1.单元测试应覆盖所测单元的所有代码路径,包括错误处理路径。为了保证代码覆盖率,单元测试必须测试公开的和私有的函数/方法。

原文2.100%的代码覆盖率并不等同于100%的正确性!

结合我在博客上看到的,我的问题是即使软件的代码覆盖率达到了100%,但是会存在那些应该写却没有写的代码,这样代码中就仍然有BUG无法解决,所以用代码覆盖率来衡量测试单元的好坏还有效吗?

问题二:

效能分析还有点不是很明白,我的理解是通过抽样或者代码注入进行分析,降低程序的时间空间复杂度,从而提高程序运行速度。但是这个操作方法可能还不是很懂,希望有深入的理解!

问题三:

原文1.软件的设计原则之一是开放--封闭原则。

允许扩展。当应用的需求发生改变时,我们可以对模块进行扩展。

不允许修改。对模块行为进行扩展时,不必改变模块的本身。

分享几个我觉得很好的博客

开放封闭原则http://blog.csdn.net/yqj2065/article/details/53508056

浅谈Java的开放封闭原则https://www.cnblogs.com/chenmo-xpw/p/6649246.html

第16章

问题一:迷思之二:大家都喜欢创新

原文1.程序员们都坚信,没有一门高级语言能像汇编语言那样完美地完成工作。

其实我觉得技术每天都在变化,软件的功能也在不断地完善,新的语言也在出现。我们也应该对其他语言有所了解,就比如说最近几年特别火的Python,以前人们总是说C和Java是无可替代的,但是自从人工智能火了以后,Python就进入了大众视野,人们用Python写网络爬虫等,效率有了很大的提高。所以我们做软件开发也不应该仅仅局限于JAVA,也应该适当地学习一下其它语言。

原文地址:https://www.cnblogs.com/BoscoJK/p/8592579.html

时间: 2024-11-09 03:07:04

《构建之法》第一、二、十六章阅读笔记的相关文章

《构建之法》第十六章读后感更正

第十六章IT行业的创新 1.关于灵感.灵光闪现固然重要,很多伟大的发明依靠的就是灵光一现的基础,但是灵光闪现的前提是个人的思考,长时间的思考.完成这一灵光的基础是不断的尝试,提高自己的技术.这样才会将自己的灵光变成一个实物而不是空想. 2.关于喜好.并不是人人都喜欢创新,因为创新本来就是个长耗时又难以被认可的东西.创新有需要考虑的因素有许多,个人.面子.优先级等等,现在人们更多的是支持在原有材料技术上的"线性发展"--扩充功能等. 3.关于想法.人们接受的并不是好的想法而是他们所需要的

《构建之法》第4.17章读书笔记

<构建之法>第4.17章读书笔记 第四章 原文语句: 异常不能跨过DLL或进程的边界来传递信息,所以异常不是万能的. 提出问题: 1.什么是DLL?DLL是来解决什么问题的? 网上说法: DLL是Dynamic Link Library的缩写,意为动态链接库.在Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL文件,放置于系统中.当我们执行某一个程序时,相应的DLL文件就会被调用.一个应用程序可有多个DLL文件,一个DLL文件也可能被几个应

《构建之法》第四&amp;十七章读书笔记

 <构建之法>第四&十七章读书笔记 一.         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,

关于构建之法第一、第二与第十六章阅读疑惑

第一章.概论 原文的1.2.1节中有说到软件的不可见性,其中有这么一段描述:"商用软件出现了错误,工程师可以看到程序在出错的一瞬间留下的一些痕迹(错误代号.大致的目标代码位置.错误信息),但是几乎无法完整的重现到底程序出现了什么问题."言下之意就是在调试程序时我们很难知道程序到底出了什么问题,对此我有一些疑问.百度百科与搜狗搜索中并没有软件的不可见性的词条,我只能通过自己的理解来理解这句话.在我自己的编写代码经历里,当代码出现了问题时,我可以在编译器中很直观地知道问题的代码是哪些, 可

构建之法第6、7章阅读

学习附录: Scrum中文网--什么是Scrum? http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1 Scrum认证体系 http://www.scrumcn.com/agile/scrumtraining/scrum-certification-program.html Scrum实践:<硝烟中的Scrum和XP> http://www.educity.cn/pm/594948.html 这次我们

构建之法学习(第六章 敏捷流程)

第6章  敏捷流程 本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法. 1.敏捷的流程 定义:"敏捷流程"是一系列价值观和方法论的集合. 现有的做法 敏捷的做法 流程和工具 个人和交流 完备的文档 可用的软件 为合同谈判 与客户合作 执行原定计划 响应变化 2.敏捷开发原则 尽早并持续地交付有价值的软件以满足顾客需求 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 经常发

大道至简第六章阅读笔记

目前我们已经学习了c++,java两种编程语言了,对于我们来说所关心的总是代码该怎么敲,可能还并不会去在意到底用什么敲比较方便或者更好,再或者是自己习惯用哪个来编译,但是读了这章内容,发现其实很多业内人士对所用的语言都是很在乎的,就比如作者之前在特长里写道擅长TPascal.Delphi.TASM系列语言而痛恨c和c++,现在觉得很荒谬.在以前的阅读感悟中也提到过,我们在软件工程这一行中做工程,目的就是实现.所以对于程序员来说,语言真的就只是一个工具,既然是工具,那么个人就会有用的顺手或者不顺手

构建之法第一、二、十六章

<构建之法>第一.二.十六章疑问 我通过阅读发现这是一本十分有趣的书.不同于别的书的晦涩难懂,<构建之法>利用浅显易懂的语言,贴近生活的例子向我们讲述了软件工程的内容. 第一章  概论 软件=程序+软件工程 扩展:软件企业=软件+商业模式 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营.和维护上的过程.软件的特殊性有a.复杂性 b.不可见性 c.易变性 d.服从性 e.非连续性.软件工程与计算机科学的区别:计算机科学中与实践相关的部分,都和数据以及其他学科发生关系:

《构建之法》读书笔记之:第一、二、十六章

这周看了邹欣老师<构建之法>的1,2,16章,获益匪浅.这本书写得妙趣横生,用阿超小飞几个人的生活场景和幽默的比喻帮我理解着软件工程的相关概念,让我对软件工程有了初步的了解:原来开发软件并不是我们想的那样简单:上手直接敲代码就可以了,而是会有一套详细的流程规范.下面是我看书时的一些心得笔记,和一些无法自己解答的疑惑,烦请各位老师批评指教. 第一章: 笔记: 软件=程序+软件工程,是否可以通俗地理解为,程序只是死的机器的东西,为什么做(需求分析),做什么(软件设计),做完后这东西是否可行(软件测