阅读作业2 团队编程的感想收获和总结 张孝祖
团队编程今天就行该告一段落了，心里有一种意犹未尽的感觉，俩个星期的合作着实让我学到了很多东西，也收获了很多，下面逐一分析
一 编程能力方面
这是我第一次编写html的程序，第一次用asp做网页，从什么都不会到基本了解超文本的编写方式，asp的编写方式，再到会用那些控件
每一步都让我发愁过，也上我学习过，学会之后也让我高兴过。当然，写团队项目也必须会使用tfs，我发现它比原来的单纯版本控制软件svn
好用很多，它直观高效，使用方便，管理更方便，我已经觉得它是一个非常值得在团队编程中使用的工具。
我分到的工作是upload模块，还有一小部分主页上的登录登出按钮，显示xxx欢迎你等字样，还有的组员分到搜索，查找数据库等等任务，从
他们的任务中，我也大致了解了什么是倒排表，什么是分词，怎么在c#中嵌入sql语句。即使他们做的功能跟我的毫无关联，我还是学到了很多很多
二 团队协作方面
一个团队要想干好一个工作，团结一致是必不可少的精神，我们组首先整体是非常和谐的，大家分工明确，积极编程，写博客，非常认真的一起努力，
对分工的多少也没有过多的怨言，组长分工也比较明确。
三 小组之间的协调
我们有许多小组，任务是分配好的，但接口之类的东西要组长之间的协调，这里不得不说还是出现了一些问题的，比如用什么编程软件，用什么语言，怎么
设计接口，潜在任务的互相推诿等，也有的组做的慢，有的组做得快，但因为需要用到慢组的东西，快组必须自己处理或者等慢组的情况，这些都是团队编程
跟分组编程重叠之后带来的弊端，我认为，要想把许多组统一起来，要有明确的分工，统一的进程，统一的领导，没有这些是很难协调组跟组之间的工作的。
所以，团队编程也有他不好的地方。
阅读资料里有关于软件结构中不好的体系结构叫做大泥球的文章
体系结构之所以重要，是因为每个系统都离不开它。有时，体系结构是在实现系统的任何部分之前开发的。其他时候，系统实现则在没有正式体系结构定义的 情况下进行。大多数情况都介于这两种极端情况之间。然而，即使是在后一种情况下，系统也有体系结构，并且在软件领域，系统体系结构经常是在构建系统之后才 变得明显。
这种未经过良好设计的体系结构大致具有三种类型，每种类型都具有自己贬义但难忘的名称：
- 大泥球（Big ball of mud，也称为“贫民窟”，Shantytown。）——此类系统包含很大的未使用部分。而且未使用的部分还与其他的一切交织在一起，使得识别它们变得不可能，更不要说删除它们了。
- 意大利面条（Spaghetti）——这是没有逻辑流的系统，其中任何部分都可能与任何其他部分连接在一起。在此类情况下，大多数部分都共同具有对许多或大多数其他部分的依赖性，尽管此类依赖性对于系统的整体功能并没有多大的意义。
- 纸牌屋（House of cards）——对于这种非体系结构，每个部分都依赖其他许多部分，因此对一个部分的更改会破坏其他若干部分，并且修复一个问题会引入许多其他问题。
我们的团队项目目前我认为还没有这样的大泥球存在，这都归功于大家分工明确，组长一开始建立主框架时建的清楚明白，所以后来程序完工时，功能模块都是十分清楚地，独立的
当然模块和模块之间会有依赖，但独立修改还是没有问题的。
我们的团队是用什么方式建造软件
- 大教堂模式（The Cathedral model）：源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。
- 市集模式（The Bazaar model）：源代码在本模式也是公开的，不过却是放在互联网上供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
此书的要义是“让够多人看到源代码，错误将无所遁形”（Given enough eyeballs, all bugs are shallow）。作者表示大教堂模式的软件开发让程式除错的时间大幅增加，因为只有少数的开发者可参与修改工作。市集模式则相反。
很显然，根据以上的定义，我们的团队是用大教堂式的开发方法开发软件的。
