软件工程实践2017——实践总结
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
- >实现的目标：首先是在代码编写方面，软工实践带来的是大量的代码量的积累。量变引发质变，让我对Android和java有了个更加深刻的认识。其次是对软件的团队开发有了一个深入的认识，而不是停留在一种感性的方面。软件的团队开发，远不同于个人开发，需要有相应的编码规范和相应的接口注释，团队间还要有团队成员之间的沟通联系，这样才能促进项目的完善。最后，还有gitkraken的使用，这个在我之前的博客就说明了[它的强大][2] 不足方面在Android的动画处理的理解还不是很了解，在代码规范和架构方面有一些没有符合团队的要求。主要还是因为没有养成相应的规范习惯，有时候在编码的时候会不由自主的按照自己之前不好的方式去编码。前几次项目pr因为不合规范被退回来重改了几次。还有就是在Android适配方面几乎不懂，使得软件在编写环节只是针对自己的机型。2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
-
1.数独作业（其中输出文件占大部分）
2.结对编程作业（部门匹配，输入输出文件占大部分）
3.团队作业--课堂小练手
4.团队主项目--stardust
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- > 1.磨刀不误砍材工 我们团队因为大家几乎都是零基础，所以pm在开始的时候，给大家定了一个指标 -- 编写一个小练手。这个在我们之后的团队项目的编写给我们很多的帮助。 2.遇到困难不要气馁 我们团队在进行课堂小练手的时候，遇到了很大的麻烦。我自己之前没有涉及过gitkraken的使用，在这个环节被占用了大量的时间，很抱歉的拖慢了团队的项目进程。也很感谢团队的小伙伴，耐心的教导才使得我能够快速的解决git的问题。这里我自己也写了篇gitkraken的使用（[戳这里][4]）,希望个小伙伴点帮助。 3.沟通是解决问题的关键 我们的团队很好的进行的了站立式会议的讨论，虽然这个会议花费的时间并不是很多，但是对团队项目的进展帮助是巨大的。具体可以看[pm的博客][5]（写的挺好的） 4.自我能力的提升 当你很认真的做完一件事情后，你会收获很多。这次的软工实践真的让我学到了许多，可能你有的时候会感觉现在的功能实现不了很烦躁，可能你的进度赶不上团队很自责。但是当我们把所面到的困难都解决掉的话，书本上的知识就会转化到自己的知识库中。在这次项目的实践中，我觉得最神奇的就是android开源库的使用。android的集成化之高，真是让人感觉很是惊奇。特别是在动画处理这一块，开源库集成的很好。三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
- > **对学弟学妹的建议：**选软工这门课一定要选实践课（听说你们下一届要强制变成必修了），要不然软工的实践课真的，你会感觉没有什么意义。没有团队的合作开发，你根本体会不到课本上所说的团队合作流程。还有就是通过软工实践你才能够体会到团队编程和个人编程的巨大差别，这个我想在以后的工作方面应该对自己是一个很大的帮助。尽量选择一个比较靠谱的pm，这样的团队的成员将会是更加上进的，团队内部的编码氛围也会比较好。当然你学到的东西也会更多，提别是像我这样自觉性比较差的人。这里也很感谢我们的团队，压力才有动力！ **下届要不要中途换队员：**个人是支持换队员的，但是换队员要使alpha阶段和beta阶段的缓冲期长一点。就像这次的换队员，中间的时间太短，使得新来的队员没法一下子融入团队项目中。想象一个在Android团队的队员被换到一个开发web的团队，如果他没有一点的php基础，这时候重头开始，在看懂团队前期开发的基础已经很难了。又想在短期时间内对新的团队做出贡献，可以说是非常有难度的。四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- > 1.萌芽阶段 -- 团队小练手 2.磨合阶段 -- 课堂小练手（同学录） 3.规范阶段 -- alpha阶段冲刺 3.创造阶段 -- beta阶段（UI改变）五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
- > 1.用户调查  2.teambition分工  3.[github代码管理][3]以及代码接口注释六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
参考论文文献：
[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
七、个性发挥，包括图文、照片和创意等
