一、再回首
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这个比赛，入了算法的坑，也取得了一些微小的成就。以后梦想成为一名算法工程师，靠算法改变世界！