不知不觉我们的软工课程已经走了一半。现在往以前看去，大一的我们做的是一个能简单运行的程序，大二的我们做的是MIPS CPU、操作系统内核这样的小系统，我们基本都能独立完成。而大三的课程，几乎都写着“项目”两次，我第一次接触了软件工程的理论，同时也在个人项目、结对项目、团队项目中不断实践着。刚刚结束的Alpha阶段尤其令人深刻感受到团队的力量。
这次的Alpha阶段中，配合上老师发布的博客作业作为指导，我们的进展严格遵循了需求分析→程序设计→代码实现的主要步骤。自此我十分同意Fred Brooks所说的软件工程中没有银弹。Java等高级语言的出现的确让软件工程飞速发展，但是无论是语言，算法还是理论，都不能绕过人们对软件的功能需求。以我们团队项目的爬虫为例，我们的需求分析出用户需要爬取含有关键词的网页，用户需要我们能对爬取的所有网页进行分析和分类。那么这些功能就是要被实打实的设计实现出来的，我并不认为将来会有那些先进的技术能够直接绕开这些必须的要素而让软件工程飞速发展。这篇《没有银弹》不仅告诉我们无法简单的解决软件工程的复杂问题，同时启发了我在软件工程中严谨的项目态度的重要性。在Alpha阶段及之后的Beta阶段，我们要做的不是想方设法躲避可能发生的复杂问题，而是更集中注意，更严谨地在复杂的问题中尽量少出错地去解决这个问题。
说到大泥球，当我们在Alpha阶段中刚拿到代码时由于毫无头绪真就认为它是个大泥球。但是在持续了几天的阅读之后，”大泥球“露出了它清晰的逻辑结构。现在看来，上届团队Beta阶段之后的这些代码的确不能称它为大泥球，UI监听器、核心爬虫、文件下载等各部分各司其职，逻辑结构毫不混乱。大泥球往往出现在那些”一次性“代码中。什么是第一次代码？我觉得我们可能再清楚不过了。大一时候那些为了通过Judge评测的C语言作业，现在自己读起来有些程序真的是不知所云。而我们的软工项目的代码，有学长传至我们，也许将来还要传给下届学弟学妹，如果功能的代码实现是一团大泥球的话，以后真的是远远看见就该绕开了。所以在Alpha阶段的编码之前，我们就充分阅读和理解了上届团队的实现思想，在一开始就明确清晰的程序结构，提出合理的算法，为代码的移植和增发做好最充足的准备。同时在每周例会中我们都会总结各自的编码工作，一篇连自己读者都费劲儿的代码，如何好意思交给PM和其他团队人员看呢？
同时我觉得我们系中大泥球的代码罕有还得额外感谢一下我们的吴际老师的面向对象课程。在课程的几次作业里，他就强制我们在所有类和方法的实现之前都要先写规格，明确这些对象和方法的作用。如此细心的进行编码前的设计，我们也就能原远离自己羞愧、而读者厌恶的大泥球了。
在大教堂和市集的两次软件工程开发模式中，我觉得我们属于大教堂模式。两种开发模式都能很显然得看出各自的优缺点：市集模式”众人拾柴火焰高“，能够充分的了解到用户们的需求，及时地进行修改；但是人多口杂，设计者往往需要在几个没有交集的需求中进行抉择，而且在设计及编码过程中掺入了需求分析，也可能会令团队晕头转向。而大教堂的编程环境清静而能高效率地完成项目，但是却有可能无法体现出用户的需求。在了解了这两种开发模式之后，我仍然支持大教堂的开发模式，原因有下：
1.所有用户的需求不可能是一致的，而用户的需求在短期内往往是不会轻易改变的。团队只要在需求分析中抓住大部分人的需求，用户在软件实现之后就会买账。
2.代码的修改往往会牵一发而动全身。如果我们要对其中一个算法，或一个功能实现修改，那么与它联系的其他部分难免需要变动。我认为代码的改动应该需要在实现之后，充分分析代码改动的得失而做出判断。
3.大多数人更喜欢选择，而不是设计。网络中有这么一句话：一个游戏的衰败是因为有更好玩的游戏出现了。游戏就是软件，用户的需求有时是难以表达的或从未需求过的，他们需要将两款软件进行对比而选择更好的一方。也就是说有的用户更喜欢去体验实体，而不是去感受概念。
我们Alpha阶段就是这样，在开始的需求分析中与数据分析小组进行商议，确定了一个固定的数据库表项，这个表项直至现在就没有进行变动过。而在Alpha阶段结束之后，我们会在进行需求的对接，是否需要根据新的功能去修改数据库的存储。而所做的这些，便是我们Alpha阶段结束之后，走出”大教堂“要做的事。而当需求分析和设计做好之后，我们就又要回归”大教堂了“。
在迭代一中，我们的开发架构是类似瀑布模型的。在迭代一Alpha阶段中，我们的4周迭代周期的工作分别为：一周需求分析与设计、两周实现、最后一周发布和维护，顺序严格而不混乱。其中还发布了功能文档和设计文档。但是瀑布模型要求从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，一旦有错误，则返回上一个阶段进行修改。可能是由于迭代时间紧迫的原因，我们并没有过多的遵循这个原则。因为瀑布模型是线性的，所以我认为他更适合那些需求变动较少的项目。而这种模型现在太过于理想化的把我们软件工程的开发进行分割，对于未知的因素抵抗力太弱，我认为这种模型已经不太适合当代的项目开发了。
Alpha阶段已经过去，通过这几篇文章的阅读，感受到了我们软件工程的一些方法论。而这些方法论大多都是适应不同的情况，没有一种是万能而令所有人信服的，也有的思想和方法已被时代所淘汰。我希望在Beta阶段中，能有根据我们团队的基本情况以及其他一些重要的因素，选择适合我们的设计方法和开发模式，能让我们的Beta阶段顺利进行。
你好,Beta！