一 . 对M1M2的一个总结
我特别感谢我们组的PM。以前我觉得女生学计算机这个专业，跟男生比差太远了。总觉得我们女生就是上上课写写作业考考试还行，但是一到开发什么项目啊，实战之类的，总觉得自己的能力和男生比差太远。但是自从加入到了这个团队，PM一直引导着我们，从什么都不会，到可以分工合作，一起做一个项目。这个经历对我来说十分难得，也让我收获了很多。这种收获不仅仅是知识上的技术上的，而是了解了整个软件开发的概念和流程。
每次scrum meeting，PM都会给我们分配任务，然后把我们做这个任务的技术难点大概和我们说了一下。让我们有一种师傅领进门的感觉。然后我们就可以各自开工啦。对于我们组来说，PM是一个特别灵魂的任务。大家遇到任何问题，都会先跟PM商量。
总体来说我们对我们的软工项目最终成果挺满意的。毕竟母不嫌子丑嘛~但是这个学期大作业实在太多，导致我们基本都是靠刷夜完成的大作业。所以希望软工在时间上能有所调整就更好啦~
二．对《构建之法》阅读问题的回答
1.一个PM通常都是怎么起步的？PM也是从程序员做起吗？
PM需要的能力十分多样化。一个好的PM必须了解常用的框架和工具，知道它们的优缺点并且针对项目的需要选择不同的框架。所以PM的知识是团队里面最广泛的。如此广泛的知识，通常由实践得到，也就是说PM也需要有实际的编程项目的经验，也是从程序员做起的。如果没有实际编程和搭建平台的经历，PM很难引领一个团队。
2.为什么ZBB之后反而会有bug的bounce？
ZBB并不是说没有BUG，毕竟任何测试都不能证明一个程序没有BUG，只有数学证明才能证明一个程序真的没有BUG。所以在ZBB之后，仍然会有比较细微的BUG隐藏在程序中没有被发现。而在之后尝试去更新软件版本的时候，有可能一个之前不会造成什么大问题的BUG，在新的功能下就会变成明显的问题。
3.一些专门针对限时限量的东西的软件，比如挂号、选课、秒杀等软件，钻了系统的漏洞，但又确实方便了有需要的人，应该禁止还是放任？
应该禁止。因为毕竟网站的设计都是为了满足一般用户的需要的。网站设计的本意是针对人，而不是机器人，如果有人利用网站漏洞谋取利益或对他人造成危害，这是应该被封杀的行为。
4.虽然改良式创新更受欢迎，但是人们有的时候需要颠覆式创新，所以，究竟什么时候人们要看到颠覆式创新的必要并欢迎它？
我的理解是当软件面临很难突破的瓶颈，或是已知有一种更好的设计可以极大的提升软件的效率的时候。这种时候更加考验对软件功能的抽象设计。如果功能抽象做的不好的话，很可能更新了软件之后，人们之前的用法就不成立了，这会对依赖你的软件的用户造成较大影响。而理想状态则是只改变底层实现，不改变表面的接口。
5.用户体验和数据结构算法并没有直接关系，但是许多非常成功的软件就是应在良好的用户体验上，那么我们为什么把学习数据结构和算法当做最优先的课程？
尽管用户体验十分重要，能够长期吸引用户的还是这个软件究竟有什么用。而想要做出有效的软件，数据结构和算法是必要的。并且数据结构和算法需要更长时间的积累和努力，而用户体验相对比较好改进。
三．产生的新问题
1.前端和后端代码的开发应该以怎样的顺序进行？以及分别开发之后怎样有效的结合在一起？
前后端开发应该同时进行。最有效的结合方式应该是写详细的开发文档，尤其是后端要提供尽量清晰的API供前端调用。前端开发人员应该及时反馈给后端开发人员，说明还应该添加怎样的功能。
2.在网页模板流行的今天，UI设计到底有什么意义？
如果是比较典型的网站，比如博客，社交网站等等，确实有很多可以参考的模板。但是对于一些特殊用途的网站，还是要用专门的用户体验设计比较好。另外，如果能够设计出十分美观的页面的话，可以让用户眼前一亮。
四．再读软工博客的新体会
Silver Bullet? Yes or No.
在这一学期亲身经历了软件开发的过程后，我更加深刻地意识到软件复杂的本性，使得这样一颗silver bullet不存在。那么那些所谓的软件工程的方法论能起到什么样的作用呢？我觉得长期以来人们总结出的软件工程的管理方法，开发方法，核心目的就是一个，控制复杂度。既然软件不可避免的复杂，而人们对软件的要求又不断升级，为了能开发出能跟上时代的软件，我们的方法论必须注重于控制复杂度。具体做法是将软件的功能分层，在上一层隐藏其下一层的细节，做好模块化，并写详细的开发文档。核心思想是团队合作，并尽量将复杂的功能分步分层完成，分而治之。
大泥球，the Cathedral and the Bazaar和worse is better：
即使遵循最好的软件工程方法论和核心思想，软件中也总是有很多bug或者不好的设计。如果在开发的过程中，突然发现这个软件最基本的设计应该用一种更加有效的方法，这时怎么办？教堂的做法是重新设计，力求做到最优的设计。这样必然会增加开发成本和投入的时间与精力，但也往往会迎来革命性的性能提升。而集市的做法更加保守，它比较偏向于在以后的设计和实现基础上修改，并在一定程度上解决问题。这样做的好处则是更新快，成本低，但会让以后的维护更加困难。这种代码复杂程度的增大和维护成本相应的提高叫大泥球现象。即一些quick and dirty的代码越滚越大，最终让代码结构混乱。但是集市的这种方法也不一定会导致大泥球现象，比如GNU Emacs就是用集市这种做法管理的很成功的开源项目。
而我们在软件开发过程中，由于受限于时间精力和成本，我们也用的是集市的做法，对于开发过程中发现的一些比较根本的设计问题，我们也没有办法重新设计，只能做一定程度的修改。我们感受到集市的做法也不是没有好处。第一，它更保守，保留了所有的开发版本，每一个新的版本都建立在旧版本的基础上，很少重新设计实现程序。虽然有的泥球越滚越大，但是源代码的版本的完整性对维护反而有帮助。第二，它充分利用了所有组员的能力，让每个人都在原来的基础上可以进行修改。大部分时候，大家的想法集思广益，是可以让软件向着更好的方向进化的。第三，它的容错性比较高，由于源代码版本版本的完整，很多修改之后出现的新bug可以通过回到原来的版本来实现。而教堂由于抛弃了以前的设计，在实现中出现的新错误会更加难以处理。
敏捷开发：
集市的这种做法在敏捷开发的思想里也能看到影子。敏捷开发强调在较短的周期中，发布新版本的软件。而教堂的一大特点则是软件更新周期较长，许多版本只供内部测试使用。我觉得敏捷开发这样的原因是相信通过频繁发布软件的新版本，观察用户的反馈，来调整今后开发的重点。教堂的做法在确定开发目标这一方面上就比较有劣势，因为有可能设计者觉得基本设计存在漏洞，决定重新设计，但是即使重新设计完成了，却发现用户的使用要求不高，并不需要设计者的重新设计。这时就很尴尬，设计者虽然设计出比原来更好的软件，但是由于软件投放市场的时间和版本数量都不够，导致对用户要求的错误估计，结果这次优化其实是并没有必要的。这就体现出敏捷开发的主要优势，即通过不断的用户选择，让市场需求来指导软件的优化与升级，这种做法更加实用，有效。
总的来说，我在这个学期的软件开发过程中，体会了软件内在的复杂度，并运用了将底层软件功能抽象化来完成了对软件复杂度的控制。我们采用了集市的开发形式和敏捷开发的开发周期，不断地完成可用的新版本，并进行测试，得到反馈，从而确定新的开发目标。我们深刻体会了软件开发方法论的重要性和实际应用，以及不同方法论的效果之间的对比，收获良多。
五．在实践中学到的知识点
需求：尝试从用户的角度换位思考问题
设计：UI设计，技术框架选择以及设计文档的编写
实现：前端技术和框架（HTML、CSS、JS、SemanticUI），前端后端的结合
测试：浏览器命令行等，用于测试html， css和JS
发布：主要是讲自己的代码push到内部的GitHub上
维护：用浏览器命令行debug