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

 第一章

 通过阅读第一章，使我对软件工程有了更加深刻的认识，从软件的定义到发展，再到具体实现一个令大众满意的软件的流程和软件开发的各个阶段都有很详细的介绍，更是引用了航空产业的发展历程做了一个比较，使读者能够清晰的理解其含义。对于软件工程与计算机科学的关系和区别也通过现实中的例子给出了详尽的解读。

  关于问题

1、我通过阅读第一章的1.2.4节，我对于何为一个“足够好”的软件产生了疑问，足够好是不是就是说明并不完美，没有达到预期，是不是就说明这个软件没有达到客户的要求，不能令客户满意，使用户感到操做流畅、简单、给他们带来便利，是不是就说明这个软件并不好，既然它并不好那为什么软件工程的目标是创造“足够好”的软件？我通过百度搜查了足够好一词并没有对于它的具体的解释，但是我又认为没有任何缺陷的完美的软件是不存在，任何一个软件从产生到被人们接受再到广泛流传都需要经历时间的磨砺和不断地改进、完善变的更好，更满足用户的需求，但不可能十全十美毫无破绽，所以我是不是可以认为“足够好”的软件就是与完美差那么一点，近乎完美的意思，但差一点有时差多少呢，这应该也是仁者见仁智者见智的吧，真正的界限到底在哪里，谁有能真正的下的了这个定义呢？

 

2、第一章的1.2.4还有一个令我不能够真正理解就是对于‘’bug”这 一词的解释，对于书中的写法我是这样理解的，在大家把软件的缺陷叫做bug之前有不少工程用bug来统称系统中的问题，简单的说，软件的行为和用户的期望值不一样，就叫做bug，而是否是bug又取决于用户、开发者的不同角度。在阅读了以上内容后我是不是可以这样理解，只要我认为那个地方是bug那个地方就真的是bug，事实证明肯定不是这样，同一个问题不同的人肯定有不同的想法，专业人士和非专业人士肯定会有不同的观点。对于到底什么样的问题才算bug，我进行了搜索，得出了我的结论，bug一词有其自身本来的作为英文单词的本意，然而其在其他各个方面也有其含义，例如，其在程程序设计方面、游戏方面更有其惊精益的解释，

由此可以看出对于bug一词，现在已经不单单用在一个方面，它存在于生活中方方面面，对于什么是bug也就各有千秋了。

 

第二章

通过对第二章的阅读，让我对于一个软件的测试流程以及到底生么样的软件才是一个好的软件有了一个全新的认识，而且对于软件的效能分析的方法和个人软件开发流程也有了一定的了解，同时对于软件的设计原则也有了清晰地认知。

关于问题

1. 通过读第二章2.1节的阅读我对于“单元测试”一词并不是特别理解，对于单元和模块的概念也不是十分的清晰，我大概理解单元测试的目的是为了找出软件中的不足之处也可以说是各个模块之间配合的不尽人意的地方，但是我感觉自己对单元测试的流程以及具体的操作仍然感到很迷茫，就像是第二十三页的最后一行，我对于这时候的代码还有很多情况没有处理，例如，还没有：处理空的字符串、长度为零的字符串，都是空格的串·····   这句话就不是特别理解为什么是这样。

对于单元测试，我进行了搜索，得到了以下内容，我个人认为对于我理解单元测试一词有了助益，让我理解了单元测试的单元的具体含义有了清晰的认知。

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

 

2、对于第二章的2.4节中描写软件设计原则中的开放-封闭原则中的允许扩展和不允许修改有一定的疑问，与我理解的可扩展与不可修改有一定的区别，书中是这样写的允许扩展（Open for extension）：当应用需求发生改变时，我们可以对模块进行扩展，从而改变模块的功能。不允许修改（Closed for modification）对于这两句话的我个人的理解是这样的，当用户对于软件有新的要求的时候，我们可以对软件的功能在原有的基础上进行增加，而不改变原有模块所具有的功能，扩展过后该模块只是增加了一个功能而已。

 

以下为我在他人博客中找到的对于这一原则的解释是我对于这一原则又有了新的认识

 

对扩展 开放 对修改关闭

         1、多使用继承的方式去修改原有行为，而不是直接修改，在子类中定义拓展的方法

         2、多用多态的形式，去复用（父类用virtual定义多态方法，子类用override重写方法，实例化指向子类的父类对象，调用方法就可以实现多态）

         3、一个变量 我们不要直接去修改 而是用方法的形式

第十六章

通过对第十六章的阅读使我对于创新又有了更加深刻地认识，不是只要另辟蹊径就会成功，所有的创新都是在对于这一领域有了深厚的基础下的产物，每个人都喜欢创新，想要去尝试创新，既然是创新，那就没有所谓的前车之鉴，因此最后是走向成功还是遗憾落败都是未知。对于IT行业，创新更加是必不可少的的一环，一味循规蹈矩，稳中发展终究会被时代的大潮淘汰掉，只有敢于创新，勇于创新，才会在未来的道路上走得长远，技术的创新是必不可少的，当然只有好的成功的团队才会有好的想法，有好的想法距离创新就更进一步。

 关于问题

大家都停了很多创新者的故事，有些人会想，他们真了不起，第一个想出了这些美妙的想法，要是我早生几十年也第一个实现那些想法就好了，其实事实并非如斯，真正的创新者都是有深厚的对于该行业的知识基础做背景的，他们的成功并不是一蹴而就的，但也并实说要成为领域专家才可以创新，就如书中的例子，物理学家也可以完成计算机领域的的创新，有时候领域内的专家没有领域外的专家那么有创意，可能是因为领域内的专家禁锢在一个圈子里了，也许就是一个他们认为很简单的东西，就改变了世界，换一个角度，也许会有不可思议的发现。对于大部分成功的创新者都不是先行者这一观点，从本质上讲，先行者是一个垄断者。理论上，先行者可以向消费者收取高额费用，并且不用担心由于竞争产品的很快出现而降价。实际上，创新者经常是宁可牺牲收益来换取更多的用户数量，况且垄断的状态是暂时的。