M1/M2总结

1.M1/M2总结

软件工程这门课上我们接手了学霸系统数据处理的移植项目

在M1阶段,我们进行了明确的分工,还做了一个整体性的计划.可是在移植的过程中,我们发现学长的代码里漏洞百出,他们后台的数据库更是惨不忍睹,根本没有什么规范,连一些最基础的约束都没有.

当时我甚至都在想,这样一个项目有移植的必要吗? 连基础平台的版本都如此不能直视.

不过大家的态度都是积极的,我们中的好多人,包括我,都从零开始疯狂地学了C#,LUCENE,XML,JSON，TFS等等知识,每个人都非常努力地修改错误,与此同时还在不断地进行移植,大家都很累,累到每天光为干这一个事都要熬夜2,3点钟,甚至更晚.

开发的过程中,组内有技术经验的人也对我们有所指导,而前端与后端开发人员的交流沟通从未停止,PM则为我们做各个方面的把关,每个人都在认真地工作.

于是,在我们的努力下,学霸的M1版本开发成功了.

这个M1阶段给我的感觉就两个字:坑,累. 我想,如果我们没有那么的团结,那么的积极的话,这个项目是不可能完成的,至于为什么你懂的.

M2阶段,这是大家都忙的不可开交的时候,几门课设都临近验收,一门一门课程陆续结业,考试,重要的必修课的考试也很近了,在这么重的压力下,我们团队的精神仍然不可磨灭,各种各样优化的尝试都在不断地进行,大家也是见缝插针,有时间开发就开发一点.没有浪费时间.即使是现在,还有很多新的优化内容被不断提出.

我想,我们的项目不一定是最好的,最漂亮的,但我们的团队一定是最认真,最努力,也最团结的.

2.链接到以前问题的博客

http://www.cnblogs.com/13061176Terry/p/4830498.html

细节问题

1.《构建之法》书上P77页讲到了两种命名方法：Pascal形式和Camel形式。

Pascal形式：所有单词的第一个字母都大写

Camel形式：第一个单词全部小写，随后单词随Pascal形式

书上说到一个通用的做法是：所有的类型/类/函数名都用Pascal形式，所有的变量都用Camel形式。但是实际上的情况是：所有的类型/类用Pascal形式，所有的变量/函数名都用Camel形式。与书上说的不完全相同。
是C/C++语言的命名规则不同，还是有其他原因？
网上有不同的规则：

http://www.linuxidc.com/Linux/2013-01/77893.htm

http://blog.csdn.net/jinzhilong580231/article/details/7717647

2.《构建之法》书上P79页讲到了goto：函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
goto有什么危害？如何更加合理的运用它？

https://en.wikipedia.org/wiki/Goto

http://blog.sina.com.cn/s/blog_6908039c0101f5hx.html

http://baike.baidu.com/link?url=guvhXPkY7ZbDrxJbjcWTsBhLk3Jx2trpDT5A_YSsVke6k9JAMm_OTsi7lRQqlyGjF2cyKjBCFH_wDbR_aR9SYa

3.《构建之法》书上P79页讲到了虚函数：

1) 使用虚函数来实现多态；

2) 仅在有必要时，使用虚函数；

3) 如果一个类型要实现多态，在基类中的析构函数应该是虚函数；

虚函数是如何实现多态的？

http://blog.chinaunix.net/uid-26851094-id-3327323.html

4.3.《构建之法》书上P80页讲到了析构函数需要注意的点：

1) 把所有的清理工作都放在析构函数中。如果有些资源在析构函数之前就释放了，记住要重置这些成员为0或NULL;
2）析构函数也不应该出错。

这两个注意点我一个都不懂。所有的清理工作指什么？为什么要重置一些资源为0或NULL?析构函数出错一般会是什么情况？

概念问题

5.我们团队打算以功能团队模式来完成团队作业，那么功能团队中有一张图（P105）：Dev，QA，UX，PM，沟通&协作。这是指团队主要只需要4部分（Dev，QA，UX，PM）就可以了，还是得需要一两个人作为沟通协作其他成员的人？

6.我们在团队任务的时候是需要哪种流程方式：写了再改模式（我们一般会这么做），瀑布模型（我们应该不会这么高大上的方式），统一流程，老板驱动的流程，渐进交付的流程（MVP,MBP，我对这个比较感兴趣）。

7.我们在做敏捷开发的时候，如何正确地有效地规定近期目标？如何有效地进行沟通？

8.敏捷开发(Agile)有几种开发的方法论：特征驱动开发（FDD）、Srum、极限编程(XP)、其它。
这些方法分别适用那些项目？我们在今后的敏捷开发的过程中应该用哪种方法论？前3中方法论是否是最好的，它们有哪些验证，还有那些常用的方法论？

9.对于团队中代码检查测试，我们每个人能发挥什么作用？为了使最终的工程尽可能详尽，让人满意，我们应该如何开展代码测试？书中的单元测试，功能测试，集成测试，场景测试，系统测试等会对测试产生什么影响？我们应该在什么时候开展这些测试？

其实当时的问题大多是设计原理方面的,通过看书以及实践,这些问题很快地被消化掉了.各种测试方法也已经在实际中得到运用，所以说软工课上我学到了很多很多

3看看以前读过的文章，新的体会。

确实有新的体会

还记得在《No Silver Bullet - Essence and Accidents of Software Engineering》中，布鲁克斯提到的附属性(将概念上的构思施行于电脑上，所遭遇到的困难),这一点说得确实对,当我在做前端的时候,就发现自己的许多构思都被安卓的一些硬性规定所限制,还有一些方面,比如说界面布局,就这么简单一个事,就那么几个位置,在实际操作的时候就发现非常恶心,甚至对齐都不是那么容易做到的,还有等间距什么的,都要好好研究...... 另外就是配合性(在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难),我们程序的接口真的是一改再改,改了无数次,因为前端在开发的过程中会遇到各种各样的情况,所以接口之间就需要自我协调,互相协调,前端对后端的需求更是在随时改变,那么后端的接口也要不断地修改,可是修改的时候还要考虑其他使用这个接口的人员,这一点就非常地麻烦,需要各方商议,达成一致意见.在M2阶段,还涉及到整合的步骤,这个就对一致性的要求就更高了,我们各个组之间做了好多的讨论,才在接口方面达成一致.

还有《The Cathedral and the Bazaar》中提到的市集开发模式,我觉得我们的团队在这个模式下做得很好,虽然我们接到的这个学霸版本让我们很无语,不过我们每个人对自己还是有着比较明确的要求,也有责任感,所以能将Android端开发出来.

另外一点,也是感受最深的一点,就是《Worse Is Better》中优先分级将简单性放在第一位,确实有道理.对于我们这种接受了棘手项目的初学者,如果在设计时不做到简单明了的话,一定会出现很多很多无法预料的错误.其实就连简单明了的设计,也会出现不少错误,不过这些错误,因为它们出现在简单的思路中,所以比较容易捕获.我想,追求高大上是要分场合的,你要是有能力,有经验,还对项目开发理解透彻的话,要尝试的话未必不可;否则的话弄得云里雾里,又复杂又漏洞百出,还调试不出来,这不就是傻么.