【个人阅读】软件工程M1/M2做一个总结

1.以前博客链接

http://www.cnblogs.com/penglinjiang/p/4027850.html

http://www.cnblogs.com/penglinjiang/p/4094660.html

2.请说明哪些问题现在自己已经清楚了，请阐明一下，是如何通过看书，实践，或者讨论弄清楚的

经过练习，已经明白的问题：

问题1：所谓的大教堂模式（The Cathedral model）到底怎么理解？

当时看到的定义： 源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。当时觉得这个定义很难理解，觉得在实践过程中也没有切实感受到，就一直搁置了。

现在的理解：（主要是通过自己在项目中的感受结合定义来理解的）“大教堂模式是封闭的、垂直的、集中式的开发模式，反映一种由权利关系所预先控制的层级制度”，这句话是我最终引用别人的话总结出来的，这样总结来说就是十分明了的。而我在项目开发中对这个模式也有一定的感悟，在我看来，大教堂模式就是将四方的教徒汇聚在教堂，大家一起做事儿，一起讨论，最终大家一起完成一个工程。这让我联系到我们的软件工程M1阶段，刚开始决定做这个安卓app的时候大家都感觉无从下手，所以大家就都聚在一起讨论，一起做。对于我来说，就是和队友一起从零开始学爬虫到爬取整个饿了么网站。大家开始都不会，所以就都聚在一起，聚到教堂来一起做事儿。当然，我这个比喻也有不恰当的地方，因为大教堂模式并非是因为大家都不会儿聚集，而是想一块儿做提高效率。

问题2：怎样的模式比较适合像我们这样的软件工程项目?

现在理解：我也是整个M1/M2项目下来才有所体会。从我的感受来说，在M1阶段、即项目前期最好还是采用大教堂模式，这样比较方便大家快速进入该项目；而在M2阶段，则应该采用市集模式，因为已经有了M1阶段的基础，如果再采用大教堂模式，反而有的人就开始偷懒，效率不高，这时候采用市集模式就比较有效，大家分配完成任务，到一定阶段再聚合一起，效率比较高。当然，这是针对我们这样的小项目我得出的结论，对于其他较大项目，还有待讨论。

3.哪些问题还不明白，请分析

主要有一个问题：M1阶段后，分工是否应该调整？

我不理解的原因在于：M1阶段有的人做的工作比较多，而有的人则几乎没有只进行一些最外围的工作，以致到最后都不太了解我们整个项目，在进入M2阶段后，问题就来了，如果不进行重新分工,依然是那一部分人承担了大部分工作，另一部分人仍然游离，对于承担多的那部分人来说，的确不公平，但如果冲新分工，A去接收B的工作，这样效率就会大大折扣，几乎相当于从M1重新开始，所以我对这个问题一直很矛盾。

4.产生了哪些新的问题，请提出

1、PM这个角色只是进行监督，是否合适？

2、对于代码整合的问题，很难很好的正好到一起，毕竟每人风格各异，有没有什么系统而高效的办法？

3、这是我个人遇到的问题，就是我负责团队数据爬取部分，在数据爬取过程中，我怎样判断爬取来的数据我是否可以正常使用？（法律问题）

4、其实问题同3差不多，就是我觉得我们整个项目通过爬取别人数据而不是选择找到对方选择合作哪个方式更好一点？

5.同时我们还读了8篇软件工程相关的论文或博客，你回头再看看这些文章，有没有新的体会

引用别人的一段话：“在软件技术的发展道路中，方法论起着决定性的作用。软件技术人员有必要站在哲学的高度、从方法论的角度，重新审视软件开发过程中各个环节，深刻体会软件工程和方法论的联系，从而改进和发展的现有的软件工程技术，消化吸收先进的思想、方法和技术，提高软件的质量和生产率，以适应现实世界对软件产业新的要求。软件工程应运而生。为了更好地发展和改进软件工程技术，我们有必要从方法论的各个角度分析软件工程的方法、工具和过程，从而有的放矢地改进软件工程中各个过程的思想、方法、模式和规则。”最大感受，像这样，团队合作的项目，方法真的很重要。

6.请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。

1需求：市场调查很重要

2设计：总体布局，功能细化，分而治之

3实现：前期建议采用大教堂模式，后期则建议敏捷编程，市集模式

4测试：白盒测试工具、黑盒测试工具、性能测试工具.

5发布：到尽可能多的安卓市场发布，前期建议从身边开始推广

6维护：软件数据库管理，故障分析解决