软件工程实践总结

文章目录
  1. 1. 再回首
  2. 2. 人月神话
  3. 3. 个人建议
  4. 4. 团队分析
  5. 5. 阅读笔记
  6. 6. 学会软工

再回首

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~18 Alpha版本十天冲刺集结令
2016-11-19 Alpha版本项目测试
2016-11-19 Alpha版本项目总结
2016-11-24 Alpha版本之事后诸葛亮
2016-12-03 Beta版本之冲刺计划及安排
2016-12-08~16 Beta版本七天冲刺集结令
2016-12-19 Beta版本项目测试
2016-12-19 用户试用与调研报告
2016-12-29 宣传推广方案

3、展现软件是可以维护和继续发展的

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

分享到 评论