- 对M1M2的一个总结
我特别感谢我们组的PM。以前我觉得女生学计算机这个专业，跟男生比差太远了。总觉得我们女生就是上上课写写作业考考试还行，但是一到开发什么项目啊，实战之类的，总觉得自己的能力和男生比差太远。但是自从加入到了这个团队，PM一直引导着我们，从什么都不会，到可以分工合作，一起做一个项目。这个经历对我来说十分难得，也让我收获了很多。这种收获不仅仅是知识上的技术上的，而是了解了整个软件开发的概念和流程。
每次scrum meeting，PM都会给我们分配任务，然后把我们做这个任务的技术难点大概和我们说了一下。让我们有一种师傅领进门的感觉。然后我们就可以各自开工啦。对于我们组来说，PM是一个特别灵魂的任务。大家遇到任何问题，都会先跟PM商量。
总体来说我们对我们的软工项目最终成果挺满意的。毕竟母不嫌子丑嘛~但是这个学期大作业实在太多，导致我们基本都是靠刷夜完成的大作业。所以希望软工在时间上能有所调整就更好啦~
- Silver Bullet? Yes or No.
在这一学期亲身经历了软件开发的过程后，我更加深刻地意识到软件复杂的本性，使得这样一颗silver bullet不存在。那么那些所谓的软件工程的方法论能起到什么样的作用呢？我觉得长期以来人们总结出的软件工程的管理方法，开发方法，核心目的就是一个，控制复杂度。既然软件不可避免的复杂，而人们对软件的要求又不断升级，为了能开发出能跟上时代的软件，我们的方法论必须注重于控制复杂度。具体做法是将软件的功能分层，在上一层隐藏其下一层的细节，做好模块化，并写详细的开发文档。核心思想是团队合作，并尽量将复杂的功能分步分层完成，分而治之。
- 大泥球，the Cathedral and the Bazaar和worse is better：
即使遵循最好的软件工程方法论和核心思想，软件中也总是有很多bug或者不好的设计。如果在开发的过程中，突然发现这个软件最基本的设计应该用一种更加有效的方法，这时怎么办？教堂的做法是重新设计，力求做到最优的设计。这样必然会增加开发成本和投入的时间与精力，但也往往会迎来革命性的性能提升。而集市的做法更加保守，它比较偏向于在以后的设计和实现基础上修改，并在一定程度上解决问题。这样做的好处则是更新快，成本低，但会让以后的维护更加困难。这种代码复杂程度的增大和维护成本相应的提高叫大泥球现象。即一些quick and dirty的代码越滚越大，最终让代码结构混乱。但是集市的这种方法也不一定会导致大泥球现象，比如GNU Emacs就是用集市这种做法管理的很成功的开源项目。
而我们在软件开发过程中，由于受限于时间精力和成本，我们也用的是集市的做法，对于开发过程中发现的一些比较根本的设计问题，我们也没有办法重新设计，只能做一定程度的修改。我们感受到集市的做法也不是没有好处。第一，它更保守，保留了所有的开发版本，每一个新的版本都建立在旧版本的基础上，很少重新设计实现程序。虽然有的泥球越滚越大，但是源代码的版本的完整性对维护反而有帮助。第二，它充分利用了所有组员的能力，让每个人都在原来的基础上可以进行修改。大部分时候，大家的想法集思广益，是可以让软件向着更好的方向进化的。第三，它的容错性比较高，由于源代码版本版本的完整，很多修改之后出现的新bug可以通过回到原来的版本来实现。而教堂由于抛弃了以前的设计，在实现中出现的新错误会更加难以处理。
- 敏捷开发：
集市的这种做法在敏捷开发的思想里也能看到影子。敏捷开发强调在较短的周期中，发布新版本的软件。而教堂的一大特点则是软件更新周期较长，许多版本只供内部测试使用。我觉得敏捷开发这样的原因是相信通过频繁发布软件的新版本，观察用户的反馈，来调整今后开发的重点。教堂的做法在确定开发目标这一方面上就比较有劣势，因为有可能设计者觉得基本设计存在漏洞，决定重新设计，但是即使重新设计完成了，却发现用户的使用要求不高，并不需要设计者的重新设计。这时就很尴尬，设计者虽然设计出比原来更好的软件，但是由于软件投放市场的时间和版本数量都不够，导致对用户要求的错误估计，结果这次优化其实是并没有必要的。这就体现出敏捷开发的主要优势，即通过不断的用户选择，让市场需求来指导软件的优化与升级，这种做法更加实用，有效。
总的来说，我在这个学期的软件开发过程中，体会了软件内在的复杂度，并运用了将底层软件功能抽象化来完成了对软件复杂度的控制。我们采用了集市的开发形式和敏捷开发的开发周期，不断地完成可用的新版本，并进行测试，得到反馈，从而确定新的开发目标。我们深刻体会了软件开发方法论的重要性和实际应用，以及不同方法论的效果之间的对比，收获良多。