ASE课程总结 by 冯晓云
开始的开始,采访往届ASE班的blog:http://www.cnblogs.com/legs/p/4894362.html 和北航软工M1检查:http://www.cnblogs.com/legs/p/4973542.html;
最后的最后,写下这篇总结,沉淀反思,与自己开诚布公;
其实这是同一件事:前事不忘后事之师。
具体的项目实现见我们的置顶博客:http://www.cnblogs.com/legs/p/5149065.html
具体的项目分析在报告中已经详细描述,其他几个同学的总结也已经基本涵盖,所以总结的重点不在项目本身~
项目选题:
其实这部分是我最想吐槽的,(课前要我们提交的方案:http://www.cnblogs.com/legs/p/4892151.html以及课上一些项目的简介),最后大家都跑UWP平台的必应词典去了。其实大家的调研未必深入,大抵是觉得跟着bingdict有肉吃。我们组又希望可以做一些自己的工作,所以没有选择必应词典项目向UWP平台的移植,而是结合林建平同学提交的方案,和必应词典查词功能结合,去完成一个新的在线取词功能,于是做了一些关于取词方面的调研,又和必应词典的负责人进行了讨论,包括我们最后的pdf阅读器方案,也是在那个时候敲定的。但是由此而引发的一系列关于adobe,foxit不得不陈的血泪,就是另外几个long story了。
在项目选题过程中,初心还是不错的,也进行了积极努力的前期筹备,但进行的技术调研不够,对于一些技术问题过于乐观。
团队组织:
构建之法里简述了不同的团队开发模式,如果非要选择一个的话,我们的团队应该是“业余剧团模式”。不但是因为我们几乎都没有软件开发的经验,甚至是相应的知识储备也不足。以我为例,C#和xmal都是边做边学的~所以在选题确定之后,我们首先对软件的各个功能模块进行了切分,并且定义了接口的数据格式,来方便各个模块“多点开花,齐头并进”(http://www.cnblogs.com/legs/p/4930117.html)。实际却是为了达到这样一个目的:各自研习,互不干涉。为了防止一人不在,项目停工,我们在每个方向上都进行了尽可能的考量,安排了人手。这对于项目初期的推进效果显著,却也为后来的种种麻烦埋下了种子。其实这样的各司其职的模式,更适合建立在稳定成熟的开发流程和专业的开发人员基础之上,即所谓的“交响乐团模式”下,才能真正的提高生产力。
在这个项目里,每位组员选择了不同的角色,并且随着项目推进,任务动态分配。
课程推进:
前期的两个个人项目,占用了我们很长的时间,压力也比较大,最后估计权当是提高编程能力和进入学习状态,并服务于最终成绩判定了。
但是课程对于团队项目似乎是越来越鸡肋,毕竟当时上课秋丰老师讲的东西,我们都半懂不懂,而我们在项目开展的过程中亟待解决的问题,却不是课程上短短的一两个小时可以解决的。老师可以和我们分享经验,帮我们指点雷区,最后每个坑都跳一跳的还得是自己。老师可以向我们指明先进生产力的发展方向,git,TFS的详细使用方法还得“实践出真知”;然而这又好像是课程本来的样子,我们虽然学步,但l路总要自己来走。哦,我似乎明白了为什么课程要把师生关系放在第一节讲:教练与学员~详情可翻阅构建之法第5~13页,教学相长,共同进步嘛~
课程的推进服务于项目,课程的内容又抽离于项目。那些懂得的,记下来;那些不懂的,终会懂得~毕竟我们的终极目标,是跑啊~
项目实现:
这是很值得被记录下来的故事~项目检查的时候,秋丰老师如是说。
但是坑深且复杂,而且不在我负责的部分,所以仅是列举。多谢后来人,戒之慎莫忘。
“业余剧团模式”下,一切看似有条不紊的进行着,第一个大坑来了:负责逻辑控制的同学,决定使用dll互相调用的方法来实现各部分代码的交互,简单来说,A,B都会被编译成DLL,其中A调B的dll,B也调A的DLL。注意,这是一个深坑;
本身设想的是设计插件,但是经不完全调研,现有技术并不支持这么做。(然后被review的时候被各种challenge),然后决定利用win32 adobe的阅读器实现,注意,这是另一个深坑;
在alpha release的时候项目完全不知何去何从,秋丰老师热心开脑洞,帮我们设计了planB,plan C,plan D。。。没想到后来忽然柳暗花明,成功实现了foxit SDK的调用。然而由于版权问题,注定无法release~
深坑,不忍卒讲:一个在Beta进程中去完成一个pdf阅读器,并就美工问题剧烈讨论的故事~一个始终不做release版本最后server是谁起的都没弄清楚的故事~
在这条道路上,我们似乎画地为牢,又似乎和正确的道路渐行渐远,认真回忆起来,也确实值得反复咀嚼。不过长歌当哭,必在痛定之后。
团队合作:
哦,团队,我们还是个“业余剧团”,什么,我是PM,负责更博并催更博吗?开个玩笑~
其实我们团队的模式是相互驱动,毕竟大家的任务区分开来之后,能掌控全局的就没有人手了。所以争吵,妥协,无可避免~但对彼此任务的不理解,消磨着彼此的耐心。比如说,我最开始负责的词典翻译部分,是解析在线查词api返回的释义,从json格式抓取出来之后还要完成数据格式转换拼接成string,控制模块才愿意接收,所以后来的popUI的数据转换也必须自己完成。这不仅降低了效率,也人为的割裂了词典和我们的软件。所以从这时候开始,我们和词典负责人没有再次接洽,查词只是作为一种工具存在。老师在review是总是提说能不能和词典的其他部分结合,所以我们加入了导入导出生词列表的功能。毕竟从数据格式上,他们已经是两个东西了~比如说,没有设置测试员,自己设计好的模块,自己搭个环境全方位调试好,测试好,还要等对方做好才合起来检验~比如各个同学相继返校考试或其他,耽误了工作进程,各司其职又导致项目停滞。。。其实完全可以设置一个负责测试,同时也能掌控全局,协调各方的职位,PM~然而我们实际的PM,却只是完成自己项目之余volunteer负责组内各项事宜的人,组内的很多事情也是大家激烈协商,友好妥协的结果~
我们是一个饭团,也是一个成长中的团队。
个人进步:
blog可查,我的任务均顺利完成,返校时间短,团队项目没有在我的部分受到限制或拖累。
最后美工部分受到各种质疑,我只表示,删张图只是注释一下的事情~
从小白到伪小白,我的技术之路前进了一大步~
关于团队合作,关于软件开发流程学习,亲身走过一遍,受益匪浅~
经验教训:
必须充分调研,在时间有限的情况下,依赖尽量成熟的标准;
建立科学有效的管理机制,包括版本控制和人员控制;
平衡项目和工作,重要的事情才不会变成紧急的事情;
团队工作能力第一,沟通第一;
和团队以外的人加强沟通,聆听他们的建议,帮助项目成长;