摘要：
（1）设计框架：我们是在原来的基础上加了两个界面来实现的，第一个是启动界面，填好必要信息之后就进入第二个界面（电梯运行界面）。（2）实现工具：我们用的是WPF（3）源程序框架：我们的源程序是在原来的基础上，加两个类库UI和ElevGUI，第一个UI是总控制的类库，启动界面在这里定义，现在的启动项目设为了UI；第二个ElevGUI是用来展示电梯运行的类库，电梯运行的展示页面在这里定义。（4）代码行数：包括注释和界面用的代码，总代码行数为502行。（5）运行时截屏：启动界面：填写电梯信息所在位置和乘客信息所在位置，并选择调度算法：电梯运行界面截屏：（6）设计心得：设计UI并不是那么简单的事情，涉及 阅读全文
摘要：
测试软件：必应词典桌面版版本：V1.6.2环境：Windows XP/ Vista/ 7测试报告：第一部分： Bug的发现1. 查询汉字时，出现查询词与词典显示词不同，甚至相悖的释义；造成这个Bug的原因应该是微软的必应词典的汉语与英语的匹配系统没有精确的算法：2. 当使用查询出来的例句用法中的中英文对照时，鼠标悬浮选择的词与即时显示的词与没有出现匹配情况，甚至是弱智的错位；这个Bug的原因应该是微软机械的抓取网络释义或者英汉大字典中的中英对照时没有做一个简单的分词系统；3. “取词”与“划译”开启与关闭状态下没有显著的区别，甚至对于初次使用者来说，是没有任何作用的，因为没有任何的介绍和使用说 阅读全文
摘要：
敏捷开发方法相对于传统的软件开发方法的一个明显的不同就是敏捷开发是与代码为主的，强调代码是文档的主要部分。相对于传统的软件开发方法，敏捷开发方法有以下的特点：（1）敏捷开发方法是适应性比预见性更重要；（2）敏捷开发是以人为本而不是以项目为本。 敏捷开发方法之所以提出适应性比预见性更重要是因为需求的变化往往是不可预见的，因此强调软件开发要有很好的适应性，预见性显得不是那么重要；作者在文中 提出的解决的方法是迭代（Iterations），利用迭代控制不可预见的过程。敏捷开发中提出把人放在首要位置，但是可能会遇到一些问题，但是作者给出 了相应的解决方法，作者提出了程序员要对自己设计的模块负责，描述了 阅读全文
摘要：
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 每个阶段都有指定的起点和终点，过程最终可以被客户和开发者识别（通过使用里程碑），在编写第一行代码之前充分强调了需求和设计，这避免了时间的浪费以及 跳票的风险，同时还可以尽可能地保证实现客户的预期需求。提取需求和设计提高了产品质量，因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易很多， 毕竟在组件集成之后来追踪特定的错误要复杂很多。最后，因为前两个阶段生成了规范的说.. 阅读全文
摘要：
这篇文章首先是介绍了软件工程要面临的固有的不可避免的问题，主要是复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。下面是对文章里这些问题观点的整理：（1）复杂性（complexity）。软件要增加规模不仅仅是简单地增加相同内容的规模，还要增 加新的内容，这就使得随着软件规模的增加其复杂度的增加是非线性的，整体复杂性的增加可能比线性增加要大得多。软件的复杂性的这个特征给软件的开发带来了 不少的困难，它会给软件项目组里的组员之间交流带来困难，从而导致产品的瑕疵、开支过多和时间耽搁；这样的复杂性给我们穷举.. 阅读全文
摘要：
“这是由Raymond在其书中称颂的集市模式导致的悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休 止地复制着，粘贴着。这事儿放在今天你也许很难相信，但就是在这令人无比尴尬的混沌之下，沉睡着美轮美奂的Unix大教堂的遗迹，而Unix恰恰是以设计 简约、功能实用、执行优雅而著称于世的。（世间荣耀就此消失……）”这是书中所描写的一个现代的由于市集式开发越来越普及甚至泛滥的场景，虽然对于这个现实我还没有充分全面的认识，但是身为一个初入编码世界的人来说，自己的亲身经验告诉我，这是真实的且是毫不夸张的。 我们都是身在代码世界里的建筑师与设计师，但是由... 阅读全文
摘要：
1. 大教堂和集市的软件发展模式： 大教堂的模型：在大教堂模式中，每一个版本的源代码都是可以被用到的，但是在不同版本间的已经开发好的代码被限制在一个专有的软件开发团队中。 集市的模式：在集市模式中，代码的开发是通过互联网以大众的视角来开发的。2. 关于我们团队SuperBrothers的软件开发模式： 我们的团队没有像Linx核心创始者那样讲代码放在互联网上让大众来检查，虽然那样会使得自己的代码的错误最小化，但是由于项目时间的短暂和项目规模较小等等因素，我们只在团队内部将彼此的代码传阅，并对其中出现的问题进行讨论和上网查询。所以在这个层面上而言，我们团队的合作模式是偏向于大教堂式的市集模... 阅读全文
摘要：
大泥球（Big Ball of Mud）1. 定义： 大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。2. 缺点： 无法使得系统内的信息得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。3. 产生的原因： 首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者... 阅读全文
摘要：
我个人认为《移山之道》所教会我们的，不应当是简简单单的一些关于微软VIsual Studio协作的技巧，更重要的是一种团队协作的精神，一种如何更好的配合以及更好的完成项目的方式与方法。在刚刚开始团队合作的时候，对于队员之间的相互协调合作的重要性我还不是很了解，同时虽然完成了结对编程项目，但是还是没有体会和掌握其中的精髓。 在被书本中的“苦涩无味”的说教中，我打开了电影《斯巴达300勇士》，一个关于希腊的传说，无巧不成书的是，其中所体现的恰恰是《移山之道》多描绘的团队协作能力。每个人有着不同的性格和初始之道，也有着自己的安排和时间表，但是，一旦加入了这个团队，团队中的每个人都是你的“袍泽兄... 阅读全文
摘要：
最初由简单的数据结构导致的低性能，然后改进了数据结构，取得了很高的性能提升；最终是性能较高的分析： 阅读全文