上了大学之后其实就没有很多时间去读书了，与其说软工作业时给我们布置了一些任务，但是也是在另一方面让我们得到了更多的知识的填补，因为平常能够接触的书籍很少，平常自己也是一个很不爱看书的人，所以我觉得这样的作业对我来说还是有所收益，尽管很多东西要去斟酌阅读，但是也好比呆呆的编程好得多啦。在阅读这些内容的过程中也能逐渐明白书中看到的一句话，代码首先是为了人而写，并不是为了机器。
好了，那我来谈谈我的阅读感受吧，当然我也会认真的面对自己的情况去面对这次作业。
A. 关于 — 银弹
我的理解呢，如果没有银弹，那么就是意味着现在情况下，没有任何一种技术还有方法可以使得软件工程生产力可以在十年内等同的提高十倍。我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。如果这是事实，那么软件开发总是非常困难的，天生就没有银弹。
其实在团队分工的开始，我们确实是有了比较好的团队分配，最后也基本达到了软件当初的一些主要需求，但是在开发的过程中来说，没有想象的那么容易，因为我们每个人都是在互相的摸索如何合作更默契，并且自己也是出于一个摸索软件的过程中，我们不断的在面临问题，解决问题，达到最后要求。对于障碍这种问题，我们并不能期待出现银弹为我们打平障碍一路畅通，就像是我们学习变成从面相过程到面相对象一样，这一路的荆棘我们都是一路斩过走过，有过积累有过自己的学习，才能够在程序设计或者学习的过程中更快的完成自己的目标，这些都是我们必须要去做的和经历的。
所以对于项目本身而言，我们需要踏踏实实完成我们的工作，对于学习而言，我们应当稳扎稳打，着重基础，没有任何捷径可走。
B — 大泥球问题
大泥球单从字面上去理解就可以提现到，混乱邋遢，事实上呢这也是象征了代码的一种情况，代码的前期的设计不完全，缺乏开发经验以及技巧都是造成我们混乱邋遢有缺陷的一切原因，所以可以把大泥球发生的原因归结为：一次性代码，碎片式增长，为了让软件有正确性，Copy过程导致问题移植，缺少前期设计，应对需求变化过晚。在团队项目中，我最近负责的部分很少，因为我最近一直也是在跑医院，这也是属于我们大泥球的一部分原因吧，因为团队合作的缺陷也会导致很多不可避免的问题。
不过我相信团队合作就应该是这样，会有自己的任务，也会有自己的失误，往往尽量减少自己IDE失误会给团队带来最大的收益，这也是我自己本身所追求的，我也会尽力在之后的工作中完成我自己的这个愿景吧。但是文章里提到“大泥球”似乎仍然是最常见的软件设计，很难避免。尽管涌现出各种鼓励、促进良好结构代码的开发方法，软件技艺运动也在不断成长，但是“大泥球”仍然是最常见的软件设计，即使人们已经从过去恶劣的设计中学到了东西，但在新的开发过程中，大泥球仍未消失。
C — CatB – Cathedral and the Bazaa
我们在开发项目的过程中，采用的是大教堂的开发模式，我们将所有源代码都放到github上去，我们可以分享我们的代码我们可以一起阅读其他人写的代码。我觉得我们的项目现在是在不断分配需求，然后实现任务的过程中前进的。但是我们缺少了很多的项目跟踪，我自己也是这段期间参加项目比较少，可能也是跟我个人情况比较特殊一些吧。不过我们的项目也是在具体的需求上做到了基本的要求。
不论是市集模式还是大教堂模式，都有其优缺点所在（这在上文中已经可以看出），关键是找到其适用的场景。这个观点虽然中庸，不过确实是实话。我以为，大教堂模式，适用于小的项目，或者是团队中有一个技术大牛带领，不需要过多的人来指点。而市集模式，则是那种涉及的方面比较广泛的项目，且不论如何，应该有一个几个人的团体对于项目的整体走向、代码有绝对的控制力，否则，会造成Kamp所说的那种混乱局面。
我们当前的项目（学霸系统的UI之用户管理部分），可以说是类似于大教堂模式。之所以说，类似，是我们的源码并非在互联网上公开的，只是相像而已。一来因为项目比较小，如果非要应用市集模式，可能会有意见无法统一，浪费资源的问题。
D — Worse is Better
我认为这个文章主要讲的是简单的暴力的往往可以压制一切，我们通常都会追求简单的设计，实现结果也要简单，成就我们需求的简单性。为了简单性，正确性，一致性，完整性都会做出一些牺牲。有时候完整性和程序的一些绝对正确性会给程序带来很大的结构复杂，并且因为复杂也会相对的付出一些代价。
E — 瀑布
严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
强调文档，在开发的后期才会看到软件的模样。在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等。对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解偏差）。
瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大的多。
F — 敏捷开发
而软件存在的意义就是与现实相适应。敏捷开发的核心即：符合现实的软件。一个符合现实的软件，才能够可持续地与现实共同发展。一旦软件与现实背离，软件的生命周期也就到了结束的时候了。
现实的世界是动态变化的，人类造出来的东西，往往是落后于世界的变化的。如，地图造出来之后，可能又多修了几条路，几个建筑；刚买了一款高配置的计算机，几个月后，自己的机器配置又处于被甩的地位了……这些变化，人是被迫要去接受。因为这些东西属于硬件，人在目前还无法轻易地改变硬件。
而与此不同的软件，则是另外一种现象了。改变软件的代价是相当低廉的。改变软件，实际上只是改变硬盘上的磁性。改变软件的容易性，带来的结果是： 一、软件开发者容易以自己的想象来决定软件怎么做。 开发出一个无用的软件，比起因为出错而要毁掉待出售的10万张地图，比起因为工艺漏洞而要招回已经出售的计算机来讲，代价太低廉了。 二、软件更加具备符合现实的条件。 开发者让软件与现实相适应，所要付出的代价非常低廉，当然对于敏捷开发我们也会有一些相应的办法：Scrum meeting 以及 个人学习团队互助的编程。
在Scrum meeting 上 ： 每天都会进行scum meeting汇报，包括今天自己完成了什么任务，明天的计划是什么。并生成每天的燃尽图，显示整体项目进度。这样的做法可以监督每一个成员每天按时按量完成自己的任务，保证项目的整体进度。
在个人学习和团队互助的编程过程中 ： 我们都会自己有阶段性的学习，然后在学习之后我们会进行交流，分享不懂不会的地方最后进行一个汇总，交给编程能力或者对语言比较熟悉的同学对这些我们收集到的问题进行解答。
所以，敏捷开发的核心就是符合现实的软件。为了造出符合现实的软件，才有了进一步的价值观及方法论。
G — 团队项目
我们的团队项目是"BUAAMOOC“，我负责的部分是PM和测试，但是我觉得我在个人的工作完成上十分不满意，也是因为我前段时间的身体情况耽误了太久，不过我希望在之后的团队项目的工作中自己可以打起精神吧，不希望自己因为自己的不足而感到失落，我应该投入到团队的合作中去发挥更大的力量才是我应该继续要做的事情。
