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

一、再回首

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，方便维护和继续发展。

七、关于我

hi，我是来自计2的郑扬涛，很高兴能够在软工实践课上与你相遇。为了锻炼自己的软件开发能力，选择了此次别样的实践课。可以说很幸运，拿到了第一件领骑衫（那个第一次上台拿衣服的少年就是我啦），结识了一群有爱的小伙伴。在生活中我只是个路人甲，不善言辞，只是努力做好自己的事情。两年多以前，作为一个萌新菜鸟来到了福大读计算机系，接触到了代码，开启了一段新的旅程。后来慢慢发现，读CS还是挺适合自己的，同时也接触到了ACM-ICPC这个比赛，入了算法的坑，也取得了一些微小的成就。以后梦想成为一名算法工程师，靠算法改变世界！