阅读作业
没有银弹 No Silver Bullet - Essence and Accidents of Software Engineering - Brooks
在这篇论文中，作者阐述了软件的四个本质：Complexity,Conformity，Changeablity, Invisibility
在解释复杂性时，作者首先把软件和其他的人类建造物做对比：
Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine, open or closed. In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. 在软件开发中，如果我们遇到两个相同的部分，我们一般的做法是把他们写成一个函数，以便于重用，因此软件的每个组成部分可以说是互不相同的，不可替代的。而在人类的其他建造物，例如楼房，则是由重复的砖块，或者是钢筋混凝土搭建而成，因此软件的复杂性远超于普通的事物。
而作者又把软件的复杂性与基础科学例如数学物理的复杂性做对比，我觉得这里的对比真的让人豁然开朗，它突出了软件的复杂性的本质性
Mathematics and the physical sciences made great strides for three centuries by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties experimentally. This worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence. 物理和数学学科之所以在建立了基本概念和模型后，可以快速发展的原因就是物理和数学的“本质”并不复杂，但是为什么软件工程没有这样的基础模型和概念呢？就是因为软件的复杂性就是软件的本质之一!
软件的可变性也是软件的本质之一，为什么软件一直在被改变呢？就是因为软件是一个embedded system，它和硬件有关，和写软件的人有关，和需求有关，一旦这些影响因素发生变化，例如硬件更新换代，需求变更，那么软件就需要随之更新，所以软件是在一直变化的。
软件也是“不可见”的，一个软件实体不能用一张图或者一个立体模型给表现出来，因为它的复杂性和易变性，如果尝试为一个软件建立一个可视化的模型，那么可能需要几个图模型，有的表示数据流向，有的表示依赖关系等等，但是这些都无法像现实世界的实体一样，通过一个立体模型直观的表现出来。
在之后作者提出的一些建议中，我觉得这个建议很关键：
Incremental development?grow, not build, software.我们要做的不是建造软件，而是不断的更新软件，关于这一点，神策数据的CEO桑文锋老师就在α阶段的总结会上提到过类似的，就是不要想着一开始就造一个大工程，好的软件是靠不断的更新换代产生的，可惜的是，我们在这个学期的软件开发过程中并没有很好的贯彻这个原则，不过我是非常赞同这个观点的。虽然在我们的团队开发中没有实现不断迭代版本，但是我自己在写一些个人项目，例如我们的编译大作业，再比如之前的计组等的过程中可以感受到 迭代的重要性。我们无法在一开始写出一个软件就保证它是最好的，只有在不断的根据用户反馈或者自己的重构中不断的提高软件的质量。
Big Ball of Mud
“大泥球代码”，这个比喻非常生动，它形容那些结构杂乱无章的代码。我觉得这样的代码的产生有两个情况，如果设计者只有一个，那么这个设计者在一开始肯定没有想好怎么组织代码，就糊里糊涂的开始写，如果代码的参与者有多个，那么这些参与者在一开始一定没有统一代码的编写规范，导致各写各的，合在一起就变成了四不像。
为了避免这种代码的产生，我觉得首先是要有一个清醒的头脑，在开始写之前先想好大致的架构，然后是要有不断改正更新的勇气，很多人因为重构比较麻烦就懒于重构修改，导致代码结构越来越混乱庞杂，最后只能推到重来，这是极其费时费力的行为，最后是要有一个统一的原则和规范，这个在多人合作时极为重要，在我们自己的团队开发中，就经常会因为一些原则规范不明确，导致一些时候开发工作效率低下，不过这种情况下只需要及时补充规范，严格执行规范，及时纠正即可。
Cathedral and the Bazaar
作者拿“教堂”和“集市”类比软件开发的两种模式，教堂模式就好像封闭的建设，会有精致的设计，充足的成本，长期的建设，而集市模式则更像是自然而然的形成，大家都来参与集市的建设，当然最后质量通常不如精心设计和建造的教堂。
我觉得软件开发如果可以吸收两个模式的优点会更好，首先吸收教堂模式的优点，就是必须要有一个软件设计主导者或者大家都要遵守的设计原则，防止这个软件不会跑偏，然后就是要结合集市模式的特点，大家都可以为软件开发做出自己的贡献，集百家之长。
我们的开发模式一开始是大教堂模式，就是由一个人制定设计，其他人执行设计，但是后来发现其他课程的课业太繁重了，如果还由一个人设计，可能导致开发进度过慢，所以之后就变成了集市模式。
所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外我认为这句话很有道理，在我们的团队开发中，一开始是由多个人讨论设计，但是很快就发现，每个人往往都只会关注和推崇自己的设计，对他人的设计往往采取排斥的态度，所以后来我们的设计只由一人负责，其他人仅仅审查并提出一些意见而已，这样做才能保证质量。
我们团队曾经遇到过这种情况，不过很快改正了
瀑布模型
我觉得我们团队开发的瀑布模型是这样的： 游戏内容设计 -> 内容设计转化为逻辑设计（类的组织） -> 逻辑设计转化为代码编写 -> 测试运行并调整游戏平衡性
这个开发过程给人的感觉就好比单周期流水线的运作，效率很低（至少我是这么认为的），因为下一阶段的负责人必须要等待上一阶段结果的产生，最重要的是不能并行运作，例如如果游戏内容设计人员给了你一部分内容设计，在你把这部分转化为逻辑的设计后，发现如果把游戏设计人员给你的另一部分设计参与到已有的逻辑设计中的话，很多原来的结构都不适用了。虽然我们经常要求软件设计要有可扩展性，但是这个可扩展性的“扩展能力”我认为有时根本不能满足需求的改变，因为总有一些扩展的情况是你想不到的。
如果软件开发的过程能够达到像CPU流水线那样精巧的并行设计该多好，至少在我们的团队开发中，我们没有实现并行。
个人总结
这个学期的软工学习了很多，一开始的个人项目和结对编程，让我学习了C++和QT的基本使用，这也为之后的编译打下了坚实的C++语言基础，之后的团队项目，虽然坑很多，但是让我第一次体验了团队开发，同时也体会到了一个好的PM，一个好的团队交流，一个确定的代码规范对于团队编程是多么重要。
不过这里也需要着重说明一下最大教训，就是框架的选择，不成熟的框架可能会造成很多不必要的麻烦，这里也不一一列举了，总之在选择框架时不仅仅需要要看它的可用性，还要注意它支不支持单元测试！