软件工程实践2017——实践总结

首先感谢老师以及助教在这一学期的辛勤付出！

作业链接

一、请回望暑假时的第一次作业，你对于软件工程课程的想象
- 1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
  就目前来说，了解了软件工程开发的整体流程以及区别于个人开发的团队协作，在整个过程，对于Git有了更深理解，不再像之前那样教程写什么跟着输什么，理解命令下版本库产生的何种变化，出错如何去解决。在开学伊始，对于软工实践，其实是想借这个机会去熟悉某种开发框架，理解这个开发框架，但是课程结束，对于各种开源库仍然只是达到会用的程度，更惭愧的是使用开源库过程导致程序产生错误的时候，一般无计可施。
- 2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
  - 统计一下，你在这门软件工程实践中，完成了多少行的代码；
    Sudoku个人作业（注：十多万的Additions中输出文件占了大多数）：
    
    第二次结对作业的代码量（注：十多万的Deletions是因为当时更新文件删除了程序输入文件）：
    
    团队随堂小测的代码量：
    
    团队项目的代码量：
  - 软工实践的各次作业分别花了多少时间？（做一个列表）
    各次作业分别花了多少时间感觉难以估计，基本上每次作业按日均5小时的编程时间，其跨度也有好几天。
  - 哪一次作业让你印象最深刻？为什么？
    随堂小测（同学录），这是小组团队协作第一次试水，其中也出了很多问题，诸如代码耦合度过高，随意更改他人代码，分工不够明确，处理不完的代码冲突等。而且在这个时候，团队对于Android处于开荒状态，对于Android并不熟练，三个小时左右的限定编程时间我们愣是肝了好几天。也是有了这次的经验教训为之后Alpha，Beta阶段的冲刺奠定了基础。
  - 累计花了多少个小时在软工实践上？平均每周花多少个小时？
    又是难以估计的一道题，正好一直有在用一款插件能查看编码情况，因为不是付费用户，所以最多回溯到十四天前的记录，以下截取部分详情，主要是Beta冲刺以及Beta冲刺后一些小修小补，在当天课程较少的时候用的时间较多，课程多的时候编程时间有所压缩，另外，其间穿插着两次考试，所以编程时间也有所缩短。
  - 学习和使用的新软件；
    Android Studio，Teambition，Typora，Visual Studio
  - 学习和使用的新工具；
    墨刀，ProcessOn
  - 学习和掌握的新语言、新平台；
    暂无掌握新的语言，学会更好的使用GitHub
  - 学习和掌握的新方法；
    原型设计，单元测试
  - 其他方面的提升。
    熬夜能力++，跑赢Deadline能力++
写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 对于一些业务场景的处理，有时候会想着正确的处理方式是怎么样的，而又一时查找不到业界内是如何处理这种典型问题的，因此陷入了死胡同。而在这次实践过程中，自己感受较深的是，自己的解决方法够不够合理，只要合适即可，没有所谓唯一正确的答案。这次实践，对于自己负责的模块用了蛮多粗暴的解决方式，比如主页光点的随机排布，按照我一开始的理解方式应该是自定义View实现光点并且利用坐标实现随机化，使用动态ID为每一个光点设置响应事件，而在实践这一过程的中间，遇到了算是蛮多问题，例如如何保证光点不重叠，如何解决光点个数超过屏幕所能容纳的范围，而最后想出了一个比较暴力的方案：使用瀑布流加不规则排列的方式利用系统自维护的组件来实现这一方案。在后续跟自己的直系学长交流的时候，确实也被他讲这一方法真是简单粗暴，但是效果能出来就行。
- 团队协作中，严格遵守团队中制定的各种规定，这样才能保证团队协作能顺利进行，并且团队中明确分工。实例其实就是之前一直所说的来自随堂小测——同学录随的惨重教训。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？
- 合理安排时间，软工实践要做，其他课程也不能落下。
- 我依然觉得更换队员意义不大，当然在这次实践中，我不是作为更换的队员，以下所讲也无法以身说法。虽然说更换队员的初衷在于更好模拟团队中人员的变动，但是在实际中，我却觉得徒然增加被换队员的工作量。软工进入尾声，同样，其他课程也进入尾声，两三门的实践课也正等待着大家上交期末成品，这时候大家都比较紧张的复习之前因为软工而有所落下的功课，准备其他实践课的成品，此时来一个更换队员，当然并没有触及大部分的利益，但是对于被替换的队员，他们的工作量确确实实的增加，与新团队磨合，熟悉新团队各种规范，阅读新团队项目代码，这些工作量不算小（是，一个良性的团队遵循各种规范，写好文档，有利于新加入的成员快速与团队磨合，但是并非每一团队都能做到，当然这也是大家需要进一步努力的地方）。当然如果得到的回应类似于“工作比你们现在辛苦多了，身在福中不知福”，那也没得讨论了。其实在实践前期，对于类似更换队员之类的变动，还是能接受的，那时候时间还比较充裕，有更多的精力可以花在这上面。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章人、绩效和职业道德）
- 萌芽阶段：团队作业开始-随堂小测同学录
- 磨合阶段：随堂小测同学录的开发环节-Alphat阶段前期（大致三天左右，随堂小测主要是Android端人员之间相互磨合，Alphat阶段则是全体成员之间的磨合
- 规范阶段：Alphat阶段中后期，明确分工，讨论事宜，有条不紊的进入开发
- 创造阶段：Alphat阶段结束后还未展示，那段时间团队正努力赶工，也比较真是感觉团队正在进行创造

五、怎样证明你学会了软件工程？
- 1）研发出符合用户需求的软件：必须公开发布，有实际的用户，一定的用户量和持续使用量（3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
- 2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件：有项目规划/需求/设计/实现/发布/维护，有定时的进度发布；而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
- 3）并且通过数据展现软件是可以维护和继续发展的。而不是找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
  项目GitHub地址，在该地址上可以看到项目规划、原型设计、需求分析、发布版本以及迭代更新等信息。
  Alpha版本发布后用户使用情况（图来自PM），Beta版本数据正在加载......：

六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87