标签：后台运行 覆盖 接下来 前端 其他 颠覆 效率 软件工程 意义
早就听说罗杰老师的软件工程课是实用性与理论性相结合的课，在这门课上不单单只是简单的编写代码，调试程序，还要做到迭代开发，撰写文档等实际软件工程中所必须要完成的工作。为了锻炼自己的能力，学到一些不一样的知识，这学期我选择了罗杰老师的软件工程课。
课程大概可以分为三个部分，个人项目，双人组队项目，团队项目（五人）。
个人项目强调个人能力，包括编写代码的能力，创造力，想象力等等，罗杰老师说过：在实际开发软件的过程中，很少是“单兵作战”，但个人能力是团队的基石，只能个人能力出众，团队水准才能不低。故安排这个个人项目考验我们。我们所做的个人项目是编写一个北京地铁搜索线路的程序，输入起始站和终点站，找到能够完成目标的最短线路和换成最少线路，刚接到任务的时候我以为这个任务其实和我以前写的其他大作业没有什么区别，自己独立编写一个代码量不少的程序，其中涉及到复杂的数据结构用来储存每个地铁站点的信息，涉及到搜索算法，包括宽度优先搜索，A-star算法等等，整个程序的调通，功能性测试等等。我这么想的，也是这么做的，但实际分数出来后发现我的分数并不是很高，事后我总结了一下原因，觉得问题可能出现在我将大部分时间都用在了代码的调试上，而忽视了项目说明文档的编写，导致文档的语言太过简陋，很多实现的细节没有反映出来，由此我总结道，软件工程一篇好的项目实现文档，应该事无巨细的讲解程序实现的每个环节，有些事不仅仅是程序中做到了就可以，而是要把他展现出来，让看文档的人知道你是怎么做的，为什么这样做。
带着一丝丝对软件工程的体悟，我们的课程进入了双人组队项目，我与一位同选这么课程的好友组成了一个双人队伍，在此之前的其他大作业上我们也是合作了很多回，所以这次我们可谓信心满满，罗杰老师上课曾经讲过：一个团队从创建时的陌生到最后的心有灵犀需要一个过程，一开始两个人可能彼此并不认识，到后来的相识，相知，再到后来可能能够互相了解，有一定 默契，过程中可能还会遇到一些问题发生争执……只有经历了种种，才能达到完美契合，形成一个真正意义上的好的团队，我想着我们之前已经有过配合，尽管可能达不到心有灵犀的要求，但至少应该也是有一些默契了，抱着这样的心情，我们开始了双人项目，这次的题目依旧是地铁，不同的是这次需要有一个图形化的界面，我由于之前使用过c++的gdk库，编写过图形界面的程序，因此我毫不犹豫的选择了团队中的前端开发任务，负责编写图形化的界面，而我的队友则因为有了个人项目的基础，在后端算法和数据结构的选择和实现上也容易了不少。编写代码的过程很顺利。吸取第一次的教训，我们也早早的就开始写起了文档。这样一份我们认为比较满意的作业并没有换来我们所预期的成绩，看到成绩的那一刻，我和队友都陷入了深思，通过与其他团队小分的比较，我们找到了一些我们相对于其他团队做的不足的地方——测试，其实说实话，关于测试我们相比于其他组来说并没有少做，在程序整体完成后，我们曾试过任意一种输入的起始站和终点站组合，看是否程序的响应会发生问题，我当时这样想，用户并不会关心你是怎样完成这个程序的，你用了什么算法，什么数据结构，什么语言，什么先进技术等等，他只关心，我使用你的软件后能不能得到我所希望的结果。所以当我们完成这项数量庞大的测试后，我们觉得我们的程序已经没有问题，不需要再写什么单元测试了，事实说明我们的软件稳定性确实没有问题，可问题却出现在了测试上，反观其他组的测试报告，基本上覆盖了程序的各个分支，覆盖率甚至高达90%以上。这颠覆了我对软件工程的认识，什么是软件工程？百度百科说是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。换句话说，我们不单单是要让我们的程序整体运行结果是正确的，而是要从根源上分析，从设计，到数据结构，算法的选用，每一处的改动为什么是对的。不理想的分数可以说沉重打击了我的自信心，但也使我更加理性的分析了课程想要教会我们的内容：编写代码的能力不可或缺，但你要说明这样写代码是正确的。事后想想这样做是很有道理的，在实际的工程项目中，代码量往往上万，其中大部分代码都不是你写的，你也不可能有时间和精力去了解每个实现细节，那么你在使用其他人编写的方法和函数的时候，只能假设其他人的代码是对的，那么怎么保证其他人的代码是对的那，就需要那个人在自己的单元部分就做好万全的测试，同理，那么你在向这个工程添加新的代码时，为了让其他使用你的代码的人放心使用，就必须保障你的改动 不会影响到整个软件，或者你改动这一部分的正常使用，因此就需要在每个单元进行充足的测试，而不是整体完成后，再进行测试，我们对整体的测试虽然也能保证程序的正确性，但我们能够在短短的两周内调试并完成代码仅仅是因为我们的项目太小，无论从代码量还是人力方面，一旦程序在测试中出了问题，不是我的错就是队友的错，代码也就我们两个写，可以很容易的就定位代码错误位置。因此，总结来看，我们完成了程序，但用的不是标准的软件工程流程，因此没有获得理想的分数也是自然的了。
想了这么多，于是便期望在团队项目中能够真正做到学以致用，我们的团队项目是学霸在线网站的后台数据处理部分以及后台数据获取部分（爬虫），这个项目到我们手上已经历经了多轮迭代开发，项目一开始可以说是进展不利，没有往届团队的说明文档，甚至看到的往届同学的代码都是α版本（未完成版本），对C#语言的不熟悉（之前仅在c++与c#程序设计课上学习和用到过，学霸网站数据处理部分源代码使用C#编写的）加之代码中没有注释，代码的冗余太多（7个类完全没用），使得我们对代码的理解进展缓慢，最终我们决定将核心代码保留后，将编写语言的重点从我们不熟悉的C#转为java，采用java调用C#程序编译的动态链接库（.dll）的方式保留原有代码进行新一轮迭代开发，这一改变可以说是机遇与风险并存，其中使用的新技术c#编译的动态链接库如何能被java引用这个问题延缓了整个工程的进度，但使用java语言编写的开发效率得到了提升（对java语言使用的熟悉程度比C#高），eclipse将java工程导成jar包，从而将整个程序变成了一个后台运行的程序，使用web显示和控制处理进度的思想也在用户体验和效果上得到了老师的认可。另外，出于对前两次项目的反思和亲身经历，可以接手一个没有项目文档的项目实在是太难了，因此，我们团队特意写了两篇博客，说明整个项目实现的每一个函数的用意以及实现细节。和整个程序的操作使用说明。
http://www.cnblogs.com/nrm1/p/6215275.html
http://www.cnblogs.com/nrm1/p/6250988.html
截止到β阶段发布答辩结束，本学期的软件工程课程已经告一段落，回顾本学期的课程，在编译技术与数据库的双重压力下，能够习完软件工程这样一门课程负担丝毫不亚于上述两门课程的我 着实为自己感到骄傲，在感受到自己的成长之外，我还想给这门课程提一点自己的建议，以下建议仅代表我个人意见，如有错误还望见谅。
1、由于在软件工程课程的后半段（大概是在数据库考试，编译考试，数据库大作业，编译大作业以及其他科目考试时候，也是团队项目β阶段关键时期），考虑到这些考试需要复习以及大作业需要时间去完成而且直接影响这些科目的最终成绩，因此软件工程的课程项目优先度极低，事实上，我个人在这一时间段内每周投入软件工程的时间不会超过4小时（大概是在周三晚上）。所以，我考虑是否可以调整教学模块，在课程的一开始就进行团队项目，然后双人项目，最后个人项目，这样做的理由如下。首先，由于学期上半段其他科任务不重，学生将有更多的时间做这个项目，可以做的更好。第二，双人项目和个人项目相对于团队项目有更加明确的目标，而且代码量比团队项目小，可在短时间内调试完全，适合在其他科目任务繁重的情况下做，而且可以提前布置，让有时间有能力的人先做。这样做可能会打破老师由渐入深，循序渐进的教学方式，但事实上，每个人在选这门课程的时候可能多半都是冲着团队项目而选的（至少我当初是因为这个目标而选）。
2、课程中的项目除了要完成代码以外，还要写一些文档（博客），作为一个计算机系的学习成绩一般的学生，写代码的能力不能说很高，但也是家常便饭，但是软件工程的规范性文档确实不知道怎么写，尽管在每次作业要求中均用大量文字叙述了文档中该写什么，不该写什么，但有一些细节还是不清楚，因此希望能够在布置作业时，老师能够提供一些往届优秀样例，可供参考。
3、关于团队项目中迭代项目各阶段时间安排，现在的时间安排是一周规划目标，两周冲刺，一周测试。老师的原意是没有错的，希望大家能够有充分的时间规划，充分的时间测试。但是作为一个并没有多少开发经验的团队而要，要在没有编写一行代码的情况下，规划出接下来两周的任务的详细计划是在是太难了，因此，大多数情况下只能进行粗略的，大范围的计划，而无法具体化，等到真正实现的时候又会发现代码与当初所想有出入，然后更改甚至推翻当初的目标，这样做导致第一周时间基本浪费，因此，我想可不可以这样，将第一周的项目规划时间减少为3天，然后从第四天开始就进行冲刺，冲刺到四天后，第二周开始再次进行规划三天，修正或更改第一次规划目标，然后完成后续冲刺，至于第四周的测试，我建议缩短为后4天，前三天再度分配到冲刺阶段，并不是说测试不重要（事实上通过学习软件工程课我才知道测试的重要性），而是其实在冲刺阶段，我们都已经对代码进行过大量的测试已确保别人使用时不会出错，即测试的工作平时就在进行，只是缺少将测试结果记录下来的过程，只要我们将平时的测试代码记录汇总起来，其实就已经完成了大部分单元测试，而且能够几乎涵盖所有代码，而事实上在冲刺结束后代码应该已经整合完成，几乎所有的功能已经可以正常使用了，这时只需要对一些极端数据进行调整即可。故建议减少最后的测试时间。
以上即为我在上完这一学期软件工程课的感慨和反思，以及对软件工程课程的建议。最后感谢所有老师和助教一学期的教育和指导，也感谢所有选择这门课程同学的陪伴。谢谢各位！
标签：后台运行 覆盖 接下来 前端 其他 颠覆 效率 软件工程 意义
原文地址：http://www.cnblogs.com/nrm1/p/6257094.html
