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

第一章、概论

原文的1.2.1节中有说到软件的不可见性,其中有这么一段描述:“商用软件出现了错误,工程师可以看到程序在出错的一瞬间留下的一些痕迹(错误代号、大致的目标代码位置、错误信息),但是几乎无法完整的重现到底程序出现了什么问题。”言下之意就是在调试程序时我们很难知道程序到底出了什么问题,对此我有一些疑问。百度百科与搜狗搜索中并没有软件的不可见性的词条,我只能通过自己的理解来理解这句话。在我自己的编写代码经历里,当代码出现了问题时,我可以在编译器中很直观地知道问题的代码是哪些, 可以根据提示做出相应的修改,以达到调试的目的。我们调试一个程序不就是为了让它尽可能地没有bug,可以没有问题地发挥自己的功能。即程序的具体问题所在我们也许不清楚,但是代码的问题所在我们是清楚的,并且可以做出相应的修改,以此来让程序的问题得到修改。所以这个不可见性软件特性的意义到底在哪里?

第二章、个人技术和流程

原文中2.1.2中有提到单元测试应该集成到自动测试的框架中,书中说:“另一个重要的措施是将单元检测自动化,这样每个人都能随时、随地的运行单元测试。”根据书中的描述与一些我在网上的查找,我对单元测试有了这样的理解:它是为了让我们所编写的程序实现目的功能,而对其中的最小可检测单位做检查和验证。这个最小单元,在百度百科中有一个很具体的定义,比如说是Java中的类,C中的函数等。众所周知,像这样的基本单元,在一个项目中是非常多的。那么当程序员在编写单元测试时,岂不是要面对十分巨大的工作量?而对于此,我们难道没有什么可以优化的方法吗?书中有写到我们可以减少复杂代码的使用比例,但我认为这是一个治标不治本的方法。所以对那些逻辑思维十分缜密或者已经经验十分丰富的程序员,也必须做到每个单元模块都要写一个单元检测吗?  其次,所谓的自动化到底是什么样子的?我通过百度百科了解了不同语言的测试工具,但是对书中提到的自动化到底是指什么,还是不太了解。

第十六章、IT行业的创新

就第十六章而言,我还是比较赞成作者的那些说法的,其中16.1.1迷思之灵光一闪,伟大的创新就紧随其后、16.1.3迷思之好的想法会赢与16.1.5迷思之要成为领域的专家才能创新令我茅塞顿开。我自己也有参与到科研立项与国创的团队中,在寻找老师点评的过程中,我们一些自认为比较有意义的想法被老师否决掉,当时还是有些郁闷的,现在明白过来,并不是说一个看似有意义的东西就一定有做出来或者说推广的必要。其次,好的创新是来源于平时的积累,厚积薄发,没有什么是能一口吃成个大胖子的。除此之外,我们在创新的过程中,也要分析市场的相应需求,从实际中出发,就算是涉及一些自己不那么熟悉的行业,也没有必要望而却步,白白浪费了自己的创新灵感。

原文地址:https://www.cnblogs.com/398353876qq/p/8595344.html

时间: 2024-10-11 13:07:27

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

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

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

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

第一章 问题一:1.2.4软件工程的目标--创造"足够好"的软件 什么是好软件? 原文1.一些同学认为,所谓好软件,就是软件没有Bug,所谓软件工程,就是把软件中的Bug都消灭掉的过程. 软件的行为和用户的期望值不一样就叫Bug. 原文2.Bug的多少可以直接衡量一个软件的开发效率.用户满意度.可靠性和可维护性. 首先对于第一点来说,我觉得无论多么好的一个软件或多或少都会有Bug,只不过是在用户体验的过程中让用户尽可能少的感受到缺陷,尽可能提高用户的使用效率,这就是一个足够好的软件.而

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

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

软件工程导论 第一、二、十六 章 随笔

第一章 通过阅读第一章,使我对软件工程有了更加深刻的认识,从软件的定义到发展,再到具体实现一个令大众满意的软件的流程和软件开发的各个阶段都有很详细的介绍,更是引用了航空产业的发展历程做了一个比较,使读者能够清晰的理解其含义.对于软件工程与计算机科学的关系和区别也通过现实中的例子给出了详尽的解读.   关于问题 1.我通过阅读第一章的1.2.4节,我对于何为一个"足够好"的软件产生了疑问,足够好是不是就是说明并不完美,没有达到预期,是不是就说明这个软件没有达到客户的要求,不能令客户满意,

《构建之法》第十一、十二章学习总结

第十一章的内容是软件设计与实现. 在第一节中,讲的是关于分析和设计方法,向我们介绍在"需求分析"."设计与实现"阶段."测试""发布"阶段该搞清楚的问题. 在第二节中,讲的是关于图形建模和分析方法.在表达实体和实体之间的关系时,可以用到思维导图(Mind Map).实体关系图(ERD).UCD ;在表达数据的流动时,可以用到DFD工具:在表达控制流的时候可以用到FSM工具:前面提到的这些图形建模方法各有特点,UML却可以有一个

构建之法5.3-=开发流程、第六章、第七章

第五章:(开发流程) 书中介绍了六种开发流程:写了再改模式.瀑布模型.瀑布模型的各种变形.RUP模式.老板驱动模式和渐进交付的流程. 书本介绍的几种开发流程中,对我们学生而言一开始大概就是写了再改这种模式,再一些经验之下,我们的流程会有些改变,会加入一些程序的简要分析和设计,能做到分析.设计.编写代码.测试等步骤了,不是仅仅是写了再改的模式. 经过这一章节的学习,我觉得的选择一个好的开发流程对程序的编写有一个导航的作用,知道自己要干什么,有什么步骤,怎么一步一地编写出自己的程序,在开始代码编写前

读《构建之法》之一,二,十六章有感

大二下学期已经过去两周了,个人感觉,课程方面压力与动力并存,相信一步一步走下去终将得到自己的一份收获. 这几天阅读了<构建之法>的第一,二,十六章,我个人的阅读速度应该属于比较慢的那种,遇到什么不确定的,不理解的概念总要停下来好久,各种百度,否则继续阅读的时候总有种急躁的感觉,老想着前面的停顿,到头来一头雾水,还是跑去理解前面的概念.作业中关于精读的part1,2,3一开始我觉得可能不适合我这种节奏慢又钻牛角尖的,但贵在尝试,以前我的阅读习惯是只读一两遍,虽然第一遍把不理解的概念都慢慢弄明白了

阅读构建之法第一章有感

今天阅读了构建之法第一章,感觉到自己其实玩具的阶段都不到,离研究阶段更是差的有段距离.了解到程序其实只是一个藏在你电脑里的数据结构加算法,要想成为软件还得经历软件工程这一阶段,软件工程便是把系统的.有序的,可量化的方法应用到软件开发,运营和维护上的过程中.首先我要进行软件需求分析,一个成功的软件是要有市场需求作为背景的,没有需求你做的软件就是无用的东西,有了需求然后我们对软件进行设计使之安全 可行 基本满足市场的需求.然后我们便对我们的软件进行测试.最后软件在用户手中运行,但是十全十美的软件是不

Week2-作业1 《构建之法》1、2、16章观后感

这几天阅读了<构建之法>中的几章,受益匪浅,刷新了很多我对软件工程的认知.这本书让我很惊喜,阅读起来不像其他书一样枯燥,有很多人物的设计,以及对话的形式,非常有趣. 第一章.概述 读完第一章了解了软件工程具体是什么,以及它与类似计算机科学等的区别,还有对bug的定义,以前觉得软件工程和计算机差不多,看了书过后才发现其中的不同,一个比较偏科研,一个比较偏实践,悟清了许多之后,还有一些不太能明白的问题: 问题1: 我看了这一段文字 "中国大陆的高校中大致有下面三种将计算机软件的机构:计算