软件工程课程总结

软件工程课程总结

一、

学期开头阅读博客链接：链接

学期开头由于对软件工程的知识了解甚少，很多比较行内的词汇都是一头雾水，所以很难提出比较有价值的问题，下面简要地回答当时提出的问题，然后着重结合一学期的理论学习和实践学习，谈一些自己对于《构建之法》所讲的知识的理解。

1、开源的企业如何盈利？

关于这点，我觉得可以举出现实中的一些企业来说明，就比如谷歌的安卓操作系统，在现阶段是开源免费的，但是调查谷歌公司的营收比例就可以知道，谷歌的广告收入占到了很大一部分，也就是说，谷歌公司的基因是做平台，通过平台盈利，这点就和微软以软件授权为主要盈利方式有本质不同。现在安卓已经是全球第一大移动操作系统，谷歌光靠从应用商店中的应用收入分成就可以获得巨大的盈利。

2、回归测试中出现退化如何避免？

修复BUG需要修改程序，而每一行程序的修改都会更改程序逻辑，那么就一定存在修复了新的BUG，而旧的已经修复的BUG又重新出现的可能。所以，每次新版本的产品发布之前，进行回归测试是不可避免的程序。我们要思考的方向应该转换为如何提高修复的效率，为了达到这一目的，应该使软件的构建符合一定的代码规范，同时，必要的文档是必不可少的。只有尽可能做到每个模块的功能单一化，才能做到BUG的局部化，这样才能提高查错、修改的效率。

3、注释究竟应该怎样书写？

如果是自己写的一百行以内、只有一两个函数的小程序，那么一行注释也没有也无伤大雅；而对于一个上万行的软件工程，一行注释也没有的程序会让人一头雾水，完全无法阅读。我个人比较推崇面向对象的软件构建思想，因此，我认为，按照面向对象当中的规格书写方式来书写注释是比较符合规范的注释方式。如果我们真的要选择一种好的注释方式来采用，可以去看看微软的开源项目，他们的注释可以成为行业标杆的作用。

4、goto语句是否可以滥用？

答案当然是否定的。书上提到的goto语句的使用仅仅是为了一些特殊的功能，比如函数返回、以及转错误处理的。现在大多数的高级语言以及足以强大到程序员可以用其他清晰的语言表述逻辑来替代goto语句，因此，避免使用goto语句仍然是一条不成文的行业约定。

下面针对后面几章，也就是团队项目MSF开发流程中某些环节来谈一下自己的看法。

MSF开发流程中的一个核心思想就是需求指导开发，因为软件工程的最终目的是开发出用户满意的产品。书上分析“360”和“hao123”的例子十分生动形象，让我走出了以前的误区：程序猿最大的缺点就是死板，以二进制的方式去思考问题，想当然地认为中国的人只要会用word和ppt就是电脑高手了（我以前就是这么看我爸的）。但是同样是需求分析，苹果看到了触控交互方式，而黑莓还在坚持键盘交互方式（虽然后者的用户定位主要是高端商业用户，但是普通大众才是消费主力军）。我觉得乔布斯的口号：“我们创造需求”有些玄乎，这种需求分析方式需要一种天才般的直觉，而作为软件工程这样的工程性学科，只能着重讲述一般化的东西，那么，像乔布斯那样的能力能否被培养？

还有一点就是测试和软件质量的问题。影响软件质量很重要的一个指标就是BUG数量，对于BUG的查找，现在实际软件工程操作中主要是通过测试来完成的。但是我觉得，软件的BUG也分成刚性需求模块的BUG和弹性需求模块的BUG，二者的重要度是不能等同衡量的。出现在刚性需求中的BUG，是必须要解决的，不然会大大影响用户体验，因为用户的使用频率高了，BUG出现次数也会比较高；而对于出现在弹性需求中的BUG，则可以考虑其是否常见，如果不常见，则应该把精力放在其他更重要的BUG的修复之上，书上并没有对这二者进行比较明确的区分，我认为这是一个缺陷。

二、

在软件开发过程中，我们还学习了一些国内外的编程大牛对于软件工程的一些体会，他们并不针对某一个具体的软件来说明如何开发，更着重分析如何提高软件开发的效率和软件的质量方面，他们大都领导开发过大型的商用软件，或者参与过大型的开源项目，会谈一些在实战过程中总结的经验。在谈到软件开发模型中，我接触到了瀑布模型和敏捷开发模型。现在敏捷开发模型很流行，我们的团队项目也是采用这种开发模式，但是，瀑布模型也不无可取之处。瀑布模型和敏捷模型相比，前者更强调稳定性，后者更强调变化性。稳定的开发流程的好处是什么？那就是可预期，因为PM可以比较精确地预期整个软件的开发时间。而变化性的开发流程中，不断返工是不可避免的，这样，软件无法按期发布的风险就会加大，现在软件市场竞争如此激烈，用户的需求变化也很快，如果不能按时发布产品，那么就很容易被淘汰。所以，用哪种开发模式，要根据软件的预期而定。

三、

在团队项目开发过程中，都用到了哪些软件工程的知识点：

需求分析：用户调研

软件设计：用ER图来直观地表达设计思想。

实现：通过TFS来控制开发流程。

测试：测试的同时书写测试文档，并反馈给实现人员。

发布：发布后要实时收集用户反馈，为下一轮迭代提供指导。

维护：在实现的时候就要考虑可维护性，不然维护的代价太高。