标签：
M1
M1是我们项目的开始阶段，也就是项目从无到有的阶段，也是我们项目所用的知识从零开始的学习阶段。就我自己而言，从从来没有写过javascript代码到比较熟练的实现我们项目所需的各种功能，我觉得我学到的还是比较多的，至少从代码量上来说，我原来是没有像M1阶段写过这么多代码的时候。我觉得写代码就像写数学题一样，练习的多了，有的时候虽然自己感受不出来，但是实际上总是会有收获的，就像书读百遍，其义自见一样。在M1阶段我的工作大概是这样的，首先先简单学一下html，为以后写js做基础。所以前两周就是在“瞎画界面”，最后画出了几个巨丑的页面，然后带了一些简单的功能。虽然最后也没用那几个页面，但是知乎看来，那两周自己的尝试并不是徒劳的，自己手画html为我以后的比如dom操作等与页面交互有关的js实现打下了基础。如果直接让我写js的话，也许有些功能能够实现，但是如果不会获取页面中的元素的话，那些需要交互的功能就无法实现。所以有了前两周的基础之后，第三四周的前端进展速度明显加快。而且这个时候后端的好多API早就已经提供出来了，因为后端那几个人写的都非常快，所以我们就可以写一个功能、测试一个功能，一个功能完成之后再进行下一个，遇到问题的时候赶快和后端沟通，就这样一个一个的实现。还有就在一轮答辩的前一天，发送短信的方法还没有弄清楚，我们的PM一直弄到凌晨4点多在群里发了一个消息，短信方法终于探索清楚了，然后他就发了一个怎样实现的教程。而且，这个时候，我和一个负责前端的队友没有睡，正好一个前端一个后端，在第二天早上把短信这个功能实现了，在第二天展示的时候也成功的将发送短信功能展示了出来。总的来说，M1阶段是一个从无到有的阶段，我学到了很多东西，而且让我有了处在团队中的感觉。
M2
M2阶段虽然名义上是一个多月，但是实际高强度的码代码的时间大概也就两周多吧，也就是正好数据库，数学建模，编译都要交大作业的时候才正式开始，前几周一直是设计和学习阶段，没怎么也没有那么多时间写代码。一开始是想将前端代码重构的，所以第一周就削了vue.js，而且看起来也不是特别难，但是刚要实际开始写的时候。卧槽，怎么其他科这么多作业，怎么可能写的完！所以，我们在第一周之后的组会上面就决定还是不要重构了，还是在原来的基础上实现更多的功能，而且我们M1的时候主要是实现的社团后台的界面，并没有实现学生会员的个人界面，所以M2的重点就转移到了实现更多的功能之上，同时又继续用了sementic-ui画了几个和原来风格相似的页面，实现了社团人员管理，申请管理，站内信等功能。现在想一想，那几天真的是要死了，连续四天通宵，每天都是天天亮天了才睡，然后也懒得去吃饭，懒得拿外卖，所以一天就吃了一顿饭，对身体的伤害肯定还是比较大的，但是真的是没办法，虽然已经延期了一次，但是工作量还是太大了。而且，那几天也正是编译补测那几天，所以我还要抽时间调编译，之前我一次都没去测。所以那几天不抽时间写编译是不可能的，我可不想写这科挂那科，那样的话真的是太苦逼了。所以M2总结一句话就是，超高强度的作死。到现在作息时间还没调整过来呢，晚上三四点钟一点都不困睡不着，早上不定闹钟就10点多才能醒。而且M2阶段还有点小插曲，本来我们是想要改变第一阶段的代码管理方式的，所以第二轮就用github了，虽然原来也用过几次吧，但是没这么系统的用过。一开始还写了个前端代码管理方案：
（首先理清一下前端代码修改的流程，前端不像后端可以直接在服务器上进行修改，前端一般是在自己的电脑上改好了之后再上传的服务器上进行调试的。因为直接对着putty修改html和js的代码实在是太不方便了（至少我这么觉得，vi用的不是很熟练），所以我们原来一般是采用以下的流程：
本地修改->上传到服务器->进行调试->{本地修改->上传到服务器->进行调试->}->上传到服务器最终发布的路径中
现在由于加入了github来管理代码，所里流程也发生了变化
本地修改->上传到服务器->进行调试->{本地修改->上传到服务器->进行调试->}->上传到github->服务器从github上pull获取最新版本）
我估摸着这个流程肯定是不太正规，但是总算是能保证无论如何也要保证每次服务器pull的时候，远程为一个可用于发布的完整工程。我自己觉得这样还不算太麻烦，但是吧，前端到后来也是着急，根本就没按照这个来，直接改完了就传到服务器的port80里去，有个页面我写了一宿功能都实现了，后来一看怎么都没了呢，原来是又让别人给覆盖掉了。当时自己本来身体就虚，这么一惊吓，真的是受不了。。
问题链接：http://www.cnblogs.com/fusluv/p/4830967.html
1.书里不经分析的盲目优化是不可取的，虽然我们的项目并没有用到太多的优化，我也就是遇到了DOM操作简化等优化，不过我还是觉得应该一早就考虑到之后可能会做哪些修改，拖到项目规模比较大的时候真的是没办法修改，比如我们M2第一周学vue.js的是时候，这个东西真的是不错，写起来也不麻烦，要想完全重构真的是没那个精力了。所以一开始还是要规划好，多考虑考虑再动工。
2.市场需求这个问题，我没做太多的了解，但是至少我觉得起码自己要觉得这个需求很切合实际吧，别弄个自己觉得自己写的代码都不切合需求就行，那样的话，写着也没动力..
3.小组人员水平，我在7个人里面水平应该是最低的，成绩也是最低的（所以我才感觉这学期像个噩梦，那些厉害的还是游刃有余..），但是我却是前端负责人，可能是因为我花的时间比较多吧，本来啥也不会，后来前端的问题另几个人也要来问我。现在想想，成长还是比较大的，本来这学期软工是想抱大腿的，大腿没抱成，反倒是累成狗了。
4.创新者不是先行者，有的时候真的是这样，最开始有想法的人往往没有付出实际行动，最后是其他人实现这人的想法的。现实生活也是这样，而且不还是有那些创意公司么，就负责想创意，不负责实现，教会徒弟饿死师傅我觉得不是特别可能，师傅总是有过人的地方，徒弟也总是会有自己擅长的方面，毕竟这个IT市场实在是太大了，都分一杯羹也分不完，至少现在是这样，以后我就不清楚了。
5.“商业价值和科学价值如何做出平衡，到底是为了金钱还是为了追求编出特别巧妙的程序的快感“，我先把原问题粘在这，因为这个问题当时提的实在是有点太大了，现在我是回答不了。金钱肯定是有，没钱吃土哇，但是吧，人不能就这么点追求，有的时候总得有点理想么不是。而且，我还想做点和本行业没太大关联的事，培养点其他的兴趣爱好。生活不一定过的多辉煌，但是总得有点意思吧。
总的来说，和之前的理解还是差不多。与其说是差不多，倒不如说是在经历了两次迭代开发之后，体会更加深刻了。
首先是银弹问题，我还是觉得银弹的寻找有必要的，虽然不是刻意的寻找，但是总是要继续的学习，继续的寻找更加便利的方法。而且也一定要注意基础，没有基础的大楼是不可能建成的。
大泥球问题，这个问题在我们的开发中显现的非常严重，当时总结的那些能够造成大泥球的原因基本全碰到了，真的是想到了也没避免了...以后还是要注意吧...
其余的那几个问题，体会没什么变化，也没什么亲身体会，就不赘述了
需求：学习了调查用户需求的方法，而且在需求的详细设计方面，我们还学了NABC方法。
设计：bottom up和top down两种大类型吧，我们这次主要是自顶向下，不断细化功能。而且在API设计的时候前端后端一起讨论并评估实现的难度。
实现：这个没啥能够细化的体会，觉得这是个积累的知识释放出来的主要阶段。当然，一定是要在需求分析正确，设计合理的基础之上的
测试：主要有单元测试，压力测试，不同平台的兼容测试等测试方法
发布：一定要有发布说明书，让别人主动探索你们的项目是不太现实的。而且发布之后还要有个总结事后分析
维护：不断发现和修复bug，增进用户体验。
首先还是要肯定这门课的意义的，但是也许由于还是在探索阶段，所以还是我以一个学生的角度来谈谈这门课的不足。
1.时间规划问题，时间还是有点不合理，尤其是在这一学期，放在下个学期或者大四可能会好一点，正好这学期全都是大课重课。讲真，要是真的能够把我们一开始的设计全部实现的，再多耗一倍的时间都有可能弄不完的，最后有些功能没实现还是有点遗憾吧。
2.考核问题，倒不是说这样的考核方式有什么问题，就是监管起来真的有些漏洞。虽然学生并不是要想小孩子一样看着，但是比如说结对编程中真的是一个人抱另一个人大腿，完全是一个人做的又该怎么发现的。团队作业也是一样。虽然我一开始也是想抱腿的，不过我现在还是挺庆幸的自己没抱成，反倒是学了很多东西的。
3.阶段展示的问题，总是占有课程时间。虽然可能老师就是这么安排课程时间的，但是往往是一堂课的开始，显示各个团队汇报一下，一汇报就是一节课多了，搞的这门课就变成一堆PM的汇报课...不是我不想学习其他团队的长处，我是真的每兴趣听别的组在那汇报那么长时间。。
最后还是祝这么课越来越好，感谢这门课的那些探索者，希望学生也能学到更多的东西，这学期我自己也算是画上了一个圆满的句号。
标签：
原文地址：http://www.cnblogs.com/fusluv/p/5128554.html
