软件工程

对于一本关于软件工程的教材我想大部分的读者第一印象就是枯燥、乏味，通篇多是高深难懂的代码让读者看的昏昏欲睡。但《构建之法》却给我们别样的感觉，作者把软件开发的方法讲的清晰有趣实用，并有相关的人物扮演不同的角色贯穿全书，让我们有一种看小说的感觉，看了开头就有一种想继续往下看的冲动。但仅仅是有趣并不是一本好书的评判标准，此书不仅拥有大量的趣味性，更不缺乏强大的实用性。作为一个菜鸟学员，对于将来的工作一定是充满了未知的，而此书却通过菜鸟程序员个人开发到一个团队的组成进行了全过程的讲解，让我们了解到了一个团队的出现是需要经历各种磨合和考验的。 对于软件相关专业的我们来说，学习了很多的专业课程，像算法，数据结构，编译原理，软件工程等。很多学生都会有这样的疑问：我学了这么多的课程有什么用呢？在工作中有多少会真正被应用到呢？也就是说，大家都觉得理论和实践之间有着不可逾越的鸿沟。该书的内容主要以设置情景，采用一问一答的形式为软件开发测试等各领域的一些常见问题用最简单的文字回答，对于一些比较难懂的概念性较强的专业名词也会以故事或情景及我们生活中的小例子来解释，让我们可以在轻松简单的文字或例子中明白其深意. 我认为与绝大部分介绍软件工程或者项目管理的书籍非常不同的一点，就是邹老师非常强调“人”在软件开发中起到的作用。在上这门软件工程时，我们抱怨作业比别的课程多，还要写博客，但我们应该“风物长宜放眼量”

初步了解 对于本书进行了一遍粗略的阅读对于本书有了一个粗略的见解。 1.这本书并不像传统的教材一般，整本书通篇罗列着晦涩难懂的概念，而是运用生动幽默的语言去打动读者，作者将自己的感触和对于软件工程的理解，通过简明扼要的手法落于纸上，更加能够帮助读者理解这本书和软件工程。 2.没读这本书之前，并不太懂软件工程的概念，只是认为软件的核心的就是代码，那么软件工程的核心就是写代码的程序员如何写好代码。在一开始的读书过程中，我颠覆了以往的观念，但后来其实想想也并无大错，其实软件工程的一系列方法，都是为了让程序员更好的去完成工作。软件这门工程，也如同盖楼一样，一个人的能力强大， 最多让某个结构更加坚固，但是软件工程着眼的是整个工程，并不简简单单局限于某个点某个面。我们所罗列的方法与思想，都是为了整个工程流程而服务的。这才是软件工程的核心所在 《构建之法》的章节比一般书籍更多（当然在计算机书籍中属于正常），共有17张，每个章节讲述的都是不同的重点，把17章看过了以后，就如同手把手带你领略过了一遍整个软件开发的过程。涵盖的部分包括了测试、项目经理、开发人员、用户体验等等多个方面。多方位的考虑一个软件的成功元素。不同的需求读者，可以选择自己想要的章节进行细化的阅读 其中我对于团队一段印象非常的深刻 总结了一点东西 1.交流 2.说到做到 3.接受团队赋予的角色并按照角色要求工作 4.投入团队 5

这个作业的要求来自于： https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178 在这个愉悦的国庆小长假，我仔细阅读了《构建之法》1-5章，对软件工程有了新的认识，现在就1-5章发表我的看法 第1章：概论 在这一章我明白所谓的程序就是数据结构+算法、软件即程序+软件工程、软件企业即软件+商业模式。程序包括算法、数据结构是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量，商业模式决定了一个软件企业的成败。这可以说是整个构建之法的核心。软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。 我看了这一段文字 ：什么是好的软件？一些同学认为，所谓好的软件，就是软件没有缺陷（BUG），所谓软件工程，就是把软件中的BUG消灭掉的过程。我认为，只要没有bug的软件就算是好的软件了吗，有没有其他的衡量标准呢？于是，我再网上查了其他的见解，如下： 要衡量一款软件是不是好软件，可以从以下几个方面来判断： 首先是使用方法要简单，一款性能优越的软件，在 使用方法 上是很简单的，初次使用也能够在短期内就可以上手使用。 其次就是 功能全面 ，这也是软件的灵魂所在。一款好的软件要满足使用者的各方面的个性需求。因为使用者的行业不同，对象不同，因此产生了各种各样的使用软件，可以完成不同任务的软件

第一章　　概论 软件工程是什么？ 软件工程的核心部分(构建管理、源代码管理、软件设计、软件测试、项目管理)和用户体验、用户界面设计等组成了软件工程,而软件=程序+软件工程。 软件开发过程中的难题有5点: 1、复杂性 2、不可见性 3、易变性 4、服从性 5、非连续性 软件的其他特性:1、有许多不同的程序设计语言、软件工具盒软件开发平台。 2、存在许多不同的软件开发流程。 3、软件团队中存在许多不同的角色。 4、软件通 常可以存储在磁带上，也可以存储在CD、DVD上。 第二章　　个人技术和流程 个人技术与流程与软件工程有什么关系？ 软件是由多人合作完成的，不同人员的工作相互有依赖关系，所以个人技术是会影响整个软件开发的过程，个人技术主要是软件开发过程中的细节问题。在开发出软 件后，必须要经过测试才算是完成了软件，这就需要一个好的单元测试的标准——1、单元测试应该在最低的功能/参数上验证程序的正确性。 2、单元测试必须由最 熟悉代码的人(程序的作者)来写。 3、单元测试过后，机器状态保持不变。 4、单元测试要快(一个测试的运行时间是几秒钟，而不是几分钟)。 5、单元测试应该产生可重复、一致的结果。 6、独立性-单元测试的运行/通过/失败/不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。 7、单元测试应该覆盖所有代码路径。 8、单元测试应该集成到自动测试的框架中。 9

　这篇读后感讲的是我读完构建之法前三章后所学到的东西以及自己的感想。 　　首先来谈谈我学到了那些东西。 　　程序=数据结构+算法； 　　软件=程序+软件工程； 　　软件企业=软件+商业模式。 　　以前，我认为软件就是程序，程序就是软件。 　　但是，真实的生活中是这样的： 　　一个能实现某种功能的程序带来了一些用户和需求。 　　那么，程序就变成了软件的初始版本。 　　接着又是一些小小的要求，然后这个应用软件就变成了软件服务。 　　这才是软件于程序的真实关系与演变。 　　以前，我的意识里认为，以后敲代码就可以赚钱，但是具体怎么赚，却从未想过。 　　但是现在，我知道了，一个团队要想要活自己，赚钱的方式有： 　　1.交钱买断； 　　2.有的“先试用再交钱”，有些软件也提供试用版，免费版和正式版，还有的类似期刊订阅，每年交钱； 　　3.有的不但免费，连源代码也一并奉送，但是要求获得源代码的开发人员遵守某种协定； 　　4.有的送硬件，但是软件要收钱； 　　5.有的送软件，但但是硬件要钱； 　　6.也有的免费用，但是要看我的广告； 　　7.还有的免费用，程序也不是我写的，如果有问题，给我钱，我就来提供咨询。 　　那么，究竟什么是软件工程？ 　　软件工程就是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。 　　初级软件工程师如何成长： 　　　1.积累软件开发相关的知识

软件工程学是一门新兴的管理工程学，虽时间不长，但却有着强大的生命力。当今是一个信息化技术主导的社会，很多企业对软件的需求都非常大，这就给软件开发者赋予了很大的商机，以获取丰厚的利润，同时也带来了很大的压力。软件是一个看不见摸不着的东西，它没有实体，开发所需的时间往往需要投入大量人力物力，为了充分满足客户的需求，还需要不断的进行测试完善以及后期的大量维护，这就造成软件的开发速度跟不上用户的需求量，功能无法满足不断变化的市场。软件工程这门学科提供了一套规范化的软件开发、测试、后期维护、项目管理的方法。规范化开发软件大致可分为如下几个流程：可行性分析、需求分析、总体设计、详细设计、测试、维护。以前的开发者们有一个误区，总认为设计阶段的编程是最重要的环节，自从软件危机爆发后，使人们认识到后期的维护以及前期的需求分析才是重中之重。(本篇只是大致阐述软件工程的大致内容，具体的环节以后会随着本人的深入理解不断更新) 来源： CSDN 作者： 既往不追 链接： https://blog.csdn.net/weixin_42786917/article/details/104471613

软件质量管理 定义：所有描述计算机软件优秀程度的特性的组合 特性：反应软件的本质 度量和评价 特性度量：预测性、验收型 预测度量：瓷尺度度量、二元度量 软件工程分为软件开发技术、软件工程管理 来源： CSDN 作者： 刘晨阳—Nancy 链接： https://blog.csdn.net/weixin_43008535/article/details/104465644

《构建之法：现代软件工程》阅读心得 总体上来说这本书的知识点通俗易懂，生动形象，但是并不浅显。和我们其它专业书籍不一样，这本书采用的是更巧妙的写作方式。这本书不是直接的知识概念的罗列堆叠，而是通过问答和描绘丰富的案例和具体的场景等多种生动形象的形式。 看完一到第五章后，就自然而然的把一到第五章串成这样的一条线：什么是软件工程，个人在写代码的时候怎样做才能写出高效有用的代码。以后作为软件工程师又应该怎样的不断进步，怎么在团队中找到适合自己的位置。对于一到五章，这样串线不知道对不对。看完第一章，恍然大悟，原来这就是软件工程啊。一直以来，我以为软件工程就是和建筑物的构成是一样的，只是系统的、机械的把所有的代码有规律的集合在一起，从而构成一个软件。看完定义才知道，软件工程是“把系统化、规范化、可度量的途径应用于软件开发、运行和维护过程”。软件可以成为商品，但又不同于别的商品，它是一个逻辑产品，具有抽象性和易复制性，由程序和软件工程组成。软件也会像楼房一样慢慢出现裂痕，这时候就需要维护保证其可用性和耐用性。这时候程序员就要重新检测自己的代码哪里出现错误，怎样维护才可以补救。与其出现问题后才补救，不如将问题扼杀在摇篮之中，这时候的就出现了“单元测试”。单元测试可以有效地保证模块的质量。诸如此类的还有效能分析测试，就是说对于同一个功能，在保证功能不受损的前提下，怎样的代码才能节约系统开销。

关于“银弹” Brooks 在 No Silver Bullet 一文中开篇便提到 “There is no silver bullet”，并且从软件工程的本质上解释了为什么一个能够解决关键问题的“武器”在软件工程上不存在（软件工程的 Complexity;Conformity;Changeability;Invisibility）。之后作者又从这么多年软件工程的发展来解释为什么没有“银弹”，无论是高抽象的语言、合理的构建方法、面向对象的思想等等。这些都不能解决软件工程带来的根本性问题。我认为，作者这么说是有道理的。 而在另一篇关于“银弹”的文章中，作者以思辨的角度从历史和方法论的观点来对软件工程中是否有银弹做了分析： 面向对象的编程思想提供了一种编写复杂系统的方法（从小的组件开始写起（造轮子））；可复用的组件以及硬件的更新都推动了软件工程的发展。软件工程发展到了现在，确实还有问题需要解决，但是正是这些问题能够不断推动软件工程的发展。 所以，就从现在来说，软件工程中的“银弹”还未出现，但是随着方法、科技的不断进步，或许之后会产生。 关于“大泥球” 大泥球的定义： 在软件工程的整个结构方面，大泥球是这样被定义的：A BIG BALL OF MUD is a casually, even haphazardly, structured system. 在具体实现上面

个人阅读作业2 作业要求：阅读关于软件开发本质和开发方法的博客/文章，结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。 No Silver Bullet - Essence and Accidents of Software Engineering这篇文章主要将软件工程存在很多问题与困难，并且解决的希望十分地渺茫。欧洲中世纪传说，有一种叫“人狼”的妖怪，它们专在月圆之夜袭击人类，传说中对“人狼”，普通子弹都伤不到也打不死它，只有一种用银制的特殊子弹才能把它杀死。引用此典故，用狼人来比喻在软件开发过程中所遇到的难题；用能够奇迹似地将狼人一枪毙命的银弹来比喻解决软件开发过程中难题的方法。软件工程发展到现在遇到了很多问题，其中软件工程开发所面临的本质问题是复杂性、整合性、易变性和不可视性。为了解决这些问题，人们探索了很多方法，比如高级语言、分时系统和统一编程环境等，但是这些都没软件工程的解决本质问题，只是从一些程度上减少了错误的发生率。最后作者写了一些可能的解决方案，如模块化编程、面向对象编程等，但是又认为解决本质问题的可能性似乎都很小。 There Is a Silver Bullet – Brad J Cox这篇文章与第一篇文章都在讨论软件工程中的silver bullet，本篇作者比第一篇作者要乐观的多，他认为面向对象、软件封装