摘要：
为期一学期的软件工程课终于结束了，总结这段时间来软工课的学习生活，我深有体会。 第一感觉就是这课的作业微多，忽略大大小小的阅读作业的话，个人编程一次，结对编程两次，团队作业一次。上过这课才觉得以前的什么JAVA、C++这些一学期一个大作业的课都弱爆了。为期一周的个人编程完全是在赶工中完成的，虽然最后好不容易按时赶完交上了，但是程序出来的结果却没有那么理想，没来得及优化也没进一步审阅，结果出错连连，但是自己真的已经花费了很大时间和精力了。 第一次作业刚提交，第二周结对编程作业就下来了，虽然之前听老师说过已经有了一定的心理准备，但真正看到题目是还是倒抽了一口凉气。这作业有两个不得不面对的问... 阅读全文
摘要：
本次作业是软工课最后一次大作业，电梯程序的改良优化，我们的工程共有以下几个文件：代码量约为1500行，以下为代码截图：运行时虽然速度慢点，但是功能上没有问题，部分运行截图如下： 本次结对编程，时间较紧，可能很多东西的实现都比较简陋，但这另一方面也让我从中领悟到了另外的东西——可能我们刚开始学习编程的时候只是注重程序的功能实现，把代码看成是最重要的东西，但是代码却其实只是软件的一部分而已，而且只是很小的一部分，对于今后可能做软件的我们而言，UI界面等其他的设计同样非常重要甚至更加重要，因为UI是用户看得到的东西，而代码用户却不会看。同一个软件，代码写的很糟糕但是界面很美观的绝对比代码写的很... 阅读全文
摘要：
第一部分——找BUG 鉴于之前没写过软件测试报告这类东西，只能通过对这个软件的使用感受简单地进行分析了。安装阶段首先我想说这个软件很不错的一点是大小只有2.01M。作为程序猿，真的很无法想象如果一个桌面软件有几十上百M那么大将会多么令人抓狂。使用事实证明这的确是一个简洁快捷短小精悍的软件。但是，安装过程实在是快得出乎我意料，是的，我打开个网页的功夫就装完了，以至于我差点没反应过来这个过程少了点什么……没错，的确是少了点什么——这软件的安装是默认的，没有选择安装文件夹的选项，以至于我都不知道它装在了什么地方。这个算是一个小BUG吧，总觉得可以再人性化点，加上这一点东西对用户使用的心情和对这软件的 阅读全文
摘要：
所谓银弹，是能杀死狼人的利器。当然现实中是没有狼人的。但现实中确实有银弹这个东西。而其意义也类似于能杀死狼人的最好办法。现实中的狼人可以是一个棘手的项目，或者一件不可能的事。而“银弹”就是指能解决这些事的方法，或者技术手段。 我们做软件的时候可能常常希望有一项技术或方法可使软件工程的生产力得到突破性的提高，然而事实上真的存在这样的东西么？ 在《No Silver Bullet》这篇IBM大型电脑之父佛瑞德·布鲁克斯（Fred Brooks）在1987年所发表的一篇关于软体工程的经典论文中，强调了由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使 阅读全文
摘要：
大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，比如SOLID、GRASP和KISS，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发（Agile）的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。 我们理想中的代码是清晰的，优雅的，云淡风轻，一望无垠，坐在电脑前深呼吸，都能闻到雨后泥土的芬芳。但是现实呢？一打开编译器就头痛。代码看得眼花，整天去修BUG，还要花半天时间先读以... 阅读全文
摘要：
当前，传统的软件工程方法越来越难以适应迅速变化的需求。近年来出现了一类新的轻量级的软件开发方法，它们被统称为敏捷型软件开发方法。在所有敏捷开发方法中，XP 是最引人注目的。 早期的时候，多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix〕。设计过程充斥着短期的、即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。 软件行业中最初的一场... 阅读全文
摘要：
所谓瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。 1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。我们可以通过图片一步步地了解所谓的瀑布模型：一个小的程序只有简单的两步经典的Waterfall软件工程模型包括以下几部分：用户需求，软件需求，需求分析，设计，编码，测试，运维。为了保证每个步骤都能正确实施，要在每个步骤之间添加一定的交互如果在测试的时候发现了设计甚至需求的问题，就必须返回为了解决上面的“返工”问题，我们可以使用下面的几步来解决 阅读全文
摘要：
。 《The Cathedral and the Bazaar》一书，是作者埃里克·斯蒂芬·雷蒙（Eric Steven Raymond）所撰写的软件工程方法论。以Linux的核心开发过程以及作者自己主持开发的开放源代码软件──Fetchmail为讨论案例。就两种基础不同的软件发展风格来探讨这些理论：一是大部分商业化世界所采用的“教堂”模式（Cathedral），另一种是Linux世界所用的市集模式(Bazaar)，这是由于对软件除错工作本质相左的假设而导致这两种不同的模式。 简而言之，所谓的大教堂模式（The Cathedral model）：源代码在本模式是公开的，但在 阅读全文
摘要：
关于《移山之道》： 在这个作业下来之前，我早已开始读这本书了，以至于在我看到如此大工程量的阅读作业时我唯一比较庆幸的事就是这里面还好有一本中文书，然后还好我已经读了三分之一。刚开始读《移山之道》的时候我看的特别慢，因为这种风格这种文体的书我还是第一次看，开始挺不习惯的，不知道该当小说看还是当工具书看。直到逐渐看到后面才发现这并不是一本工具书，更多的是指导性质的教材，它并不会从细节从操作上教我们如何如何使用Visual Studio，而是从宏观上指导我们如何通过利用这些软件工具或独立或配合地完成各种软件工程项目。后来把握了此书的脉络之后我渐渐地加快了阅读速度，原因有二： 1.有些大型项目的团.. 阅读全文
摘要：
本次结对编程作业，我和付博扬同学一组，为了使作业能够更有效率地完成，针对已有的电梯调度程序，我们进行了初步的简单任务分工以及时间分配。首先在时间分配上，两周时间看上去很多，但其实相当紧迫。一方面，这次的项目相比以往最不同的一点是，我们要在一个已有的项目上进行代码加工，这意味着我们需要先读懂已有的程序代码，并在理解之后才能开始项目展开。由于我们之前对C#的掌握并没有那么牢靠，因此C#的相关知识学习的巩固提高也需要耗去相当一部分时间。另一方面，由于两人并不在一个班级，之前并不熟悉，因此前期的交流配合上还是有一定的不便，不过这个问题随着项目的进行而慢慢消失。此外由于大家都比较习惯了单独编程，关于结对 阅读全文