您的位置:首页 > 其它

个人作业——软件工程实践总结

2016-12-30 19:33 288 查看

一、再回首

1、对比现在的你和开学初博客开篇的课程目标和期待

开学的目标现在的情况
学习软件开发的完整过程经过一个学期理论和实践的学习,在经历过需求分析、系统设计、编码、测试、交付验收等环节以及alpha和beta版本的开发,大体上掌握了软件(web)开发的基本流程。
增强团队协作与沟通交流的能力加入了“我说的都队”小组,在强大的pm的带领下,小伙伴们配合得相当默契,团队成员之间有充分的沟通与交流,经常约在活动室一起敲代码。
掌握各种开发工具的使用能初步掌握常用的开发工具,详情请见第2点“学习和使用的新软件和新工具”。
合理安排时间、项目进度在两个版本的冲刺中,由于pm的合理安排和计划,我们小组仅仅在alpha版本发布前通宵过一次,其他时间基本按照计划走,稳得不行!
2、总结这门课程的实践给你带来的提升:

(1)学习和使用的新软件

原型设计工具Axure RP、MockingBot

Windows下的Markdown书写软件Typora

分布式版本控制软件git以及托管平台github /coding.net

Microsoft Visio画流程图、类图

sublime text编写前端代码

WAMP搭建本地web服务器

(2)学习和使用的新工具

浏览器自带的开发者工具(说实话之前没怎么碰过这个...

JavaScript单元测试框架——Qunit

在线思维导图——百度脑图

阿里巴巴矢量图标库——iconfont

在线教程网学习前端知识——w3school

(3)学习和掌握的新语言、新平台

html、css、JavaScript

(4)统计一下,你在这门软件工程实践中,完成了多少行的代码

不到1k行代码。主要原因还是在于中间出去参加了两场ACM比赛,大概有十几天不在学校。所以PM考虑实际情况后,分配给我的编码工作量比较少。

(5)学习和掌握的新方法

面向搜索引擎编程

前端没学过,只好边学边用

(6)其他的提升

大学第一次通宵献给软工,竟不觉得困...

写前端界面,然后强迫症又加深了...

二、人月神话

1、经验总结

别试图想先学完一个语言,再开始进行编码工作,直接上手才是硬道理

文档工作不是表面功夫,认真对待对后期将有极大的帮助

团队成员之间的沟通交流非常重要,特别是前后端的配合

对pm分配的任务,觉得有疑问的地方要及时提出

站立式会议时间不长,要充分利用机会进行总结,三省吾身

项目进度安排要合理,将各个功能点分配好,避免出现熬夜赶工现象

团队成员聚在活动室一起敲代码,效率绝对比自己一个人敲要高

2、实例分析

主要说说沟通交流方面。

齐民要试验php后台连接cpp编写的分配算法,于是直接跑到他的宿舍去,按照他要求的输出格式对代码进行修改,在有效的沟通交流之下,很快就可以改好了,比在QQ上一来一回的效率高到不知哪里去。

跟胡总的前后端配合,前端页面写完了,后台要接上来,比如分页什么的有问题了就得找下后台,界面布局有问题了又得找下前端,因此前后端之间的交流是必不可少的!

某个前端页面出现莫名其妙的bug,最底下有一大片空白的页面,关键是只有这个页面有这个问题,然后用浏览器自带的开发者工具查了半天也没发现,后来直接请教前端大佬,不用一会就解决了。所以有时候多跟经验丰富的同学交流是很有帮助的,会让你少走一些弯路。

三、个人建议

想认真学习软件工程这门课,选栋哥的课准是没错的

想水的可以考虑出门右转了,这个课注定不适合你...

万事开头难,不要轻言放弃,既然选择了hard模式,就请坚持下去

利用空余时间,提前简单了解git和github的使用,不让其成为团队协作的障碍

多与团队成员沟通交流,不要单打独斗,记住软工是一个team

要求有较强的自学能力,软工不会教你某一门具体的编程语言

学会learning by doing,不懂没关系,以做促学

善用Google、StackOverflow等网站,能解决你开发中面临的大部分问题

懂得合理安排时间,不要赶在deadline前才临门一脚

编码不是软工的全部,不要排斥写文档、写博客,用文字记录点滴是有益的

四、团队分析

阶段对应时期主要表现
萌芽组队虽然小组成员都是来自计2和计3,但是平常也没多少机会接触。所以组好队之后还是有一个熟悉与融合的过程。在此期间,每个人对自己在团队中所担负的职责、角色定位还不是很清楚。
磨合选题在组队初期,我们小组的技能点就是往Android开发方向的,就想着在软工实践课能够开发出一款实用有情怀的app。在选题方面,一开始想过做一款为学校部门、社团服务的app,但是团队成员有着自己不同的想法,以致于出现了较大的意见分歧。后来,选题又改成了类似“赏金猎人”的东西。但是再后来,万万没想到,我们接手了导师互选系统的网页端项目。选题一改再改,团队也在此期间得到不断的磨合。
规范alpha选题确定,需求确定,等一切都稳定了下来,大家开始慢慢地配合,慢慢明确了自己的角色和职责。开发、讨论、交流也慢慢变得规范起来,都能够遵守相应的规矩。
创造beta构建之法中说,达到创造阶段的团队知道为何而战。哈哈,我们的目标一开始就很明确,是为了栋哥的自助餐而战的,因此大家在每个环节都努力做到最好。“高度自治,不需要领导的实时教诲和介入”,确实,PM通过在github上发布121个issues来计划整个项目,给每个人分配任务和功能点,大家都能够自觉主动地去完成。
综上,我认为我们的团队可以算是达到了
创造
阶段!

五、阅读笔记

题目:Open source software development should strive for even greater code maintainability(开源软件的发展需要有更好的代码可维护性)

大意:对开源环境下源代码可维护性的研究结果进行探讨

主旨:开源软件的发展关键在于软件发布之后的维护

文章指出,代码维护主要有以下两种:

corrective maintenance:对已经存在的功能进行排错

perfective maintenance:为系统添加新的特性

作者通过测量五款开源软件的可维护性指数(Maintainability Index,MI)来评价各个软件的可维护性,MI值越高说明软件的可维护性越好,并得出了以下结论:

在实现相同功能的情况下,开源软件的代码质量要好于或至少等同于闭源软件的代码质量。

对于开源软件在不同版本可维护性上的表现(MI值波动明显),同时考虑到20%的代码产生80%的维护问题,因此对开源软件需要做更细致独立的分析。

随着时间的推移,开源软件的可维护性也会逐渐降低,因此需要考虑预防性维护(preventive maintenance)。


读完论文之后,发现代码的可维护性是十分重要的。回过头来再看自己编写的代码,主要分为三块,C++编写的分配算法,html写的前端界面,JavaScript编写的测试代码,这三部分代码的可维护性应该是逐渐降低的...主要原因还是在于对语言的掌握程度,掌握的不深入不能够灵活运用,很多时候仅仅只是为了完成一个功能而去编写代码,没有考虑到以后的扩展性以及维护性。但是说大泥球吧,应该也还不至于,至少在提出需求变更的时候,还能看得懂一个多月前写的代码,并进行相应的修改和扩展。


六、学会软工

1、研发出符合用户需求的软件

毕设导师互选是每个高校都必须面临的问题,开发此系统是符合潜在的用户需求的。而且该系统以后可能会被用于数计学院的工作中。

2、通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件

我们团队有完整的项目规划,并且定时发布项目的进度。

时间主题
             2016-09-25                          团队选题报告            
2016-10-16任务计划
2016-10-22需求规格说明书
2016-10-29系统设计
2016-11-07~18Alpha版本十天冲刺集结令
2016-11-19Alpha版本项目测试
2016-11-19Alpha版本项目总结
2016-11-24Alpha版本之事后诸葛亮
2016-12-03Beta版本之冲刺计划及安排
2016-12-08~16Beta版本七天冲刺集结令
2016-12-19Beta版本项目测试
2016-12-19用户试用与调研报告
2016-12-29宣传推广方案
3、展现软件是可以维护和继续发展的

github链接:点我跳转

仓库里有完整的软件需求说明书等文档,详细的commit记录以及issues,方便维护和继续发展。

七、关于我



hi,我是来自计2的郑扬涛,很高兴能够在软工实践课上与你相遇。为了锻炼自己的软件开发能力,选择了此次别样的实践课。可以说很幸运,拿到了第一件领骑衫(那个第一次上台拿衣服的少年就是我啦),结识了一群有爱的小伙伴。在生活中我只是个路人甲,不善言辞,只是努力做好自己的事情。两年多以前,作为一个萌新菜鸟来到了福大读计算机系,接触到了代码,开启了一段新的旅程。后来慢慢发现,读CS还是挺适合自己的,同时也接触到了ACM-ICPC这个比赛,入了算法的坑,也取得了一些微小的成就。以后梦想成为一名算法工程师,靠算法改变世界!
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: