软工实践作业之个人总结

作业原文

一、请回望暑假时的第一次作业，你对于软件工程课程的想象

1. 对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
   在和他人合作编码的方面得到了锻炼，不仅是在刚开始一对一的结对编程，后面的团队作业也是。写代码不单单是考虑实现相应的功能，还要尽量让代码规范易读，加上必要的注释，不然别说别人，自己过段时间可能都看不懂，这是一个值得注意和保持的好习惯。还有对团队合作的工具，主要是 github ，又熟悉了些，确实很强大，但是自己还不能熟练地使用。
   不足自我感觉还是自学的能力，上手比较慢，后来也只是能够大致满足团队开发需要的程度，没有很深入。

2. 总结这门课程的实践总结和给你带来的提升，包括以下内容：

   • 统计一下，你在这门软件工程实践中，完成了多少行的代码；
     两三千吧。一些实现按钮功能的代码只是按钮名字不一样，算数的还得再少个几百行。
   • 软工实践的各次作业分别花了多少时间？（做一个列表）

   作业	所花时间
   阅读思考与期望	5h
   个人项目实战之数独	20h
   结对项目第一次作业	3h
   团队第一次作业之团队展示	1h
   结对项目第二次作业	15h
   团队作业之选题报告	1h
   个人技术博客（alpha）	5h
   团队作业之需求规格说明书	1h
   团队作业之采访学长	1h
   团队作业之系统设计	2h
   团队作业之UML设计	2h
   团队作业之同学录	7h
   个人作业之华为软件云	3h
   团队作业之 alpha 冲刺	50h
   团队作业之 beta 冲刺	15h
   软工实践个人总结	3h

   • 哪一次作业让你印象最深刻？为什么？
     课堂小测同学录那次印象比较深刻，算是第一次真正意义上的不同。数独那次作业就还是自己一个人捣鼓，虽然过程艰难，但是又见识到了不少东西，也是乐在其中。结对那次碰上国庆，分工之后各弄各的感觉居多。同学录是第一次真正意义上的团队合作编程，一群人在一起，分工之后又各自协作，最后把各个模块整合在一起。这才是软件工程吧，和原来自己一个人打代码就很不一样。
   • 累计花了多少个小时在软工实践上？平均每周花多少个小时？
     算上各种，估计150h吧，平均每周10h吧。
   • 学习和使用的新软件；
     Visual Studio、Android Studio、Github Desktop
   • 学习和使用的新工具；
     ProcessOn、CJson
   • 学习和掌握的新语言、新平台；
     Java、Android
   • 学习和掌握的新方法；
     单元测试之类的
   • 其他方面的提升。
     github 熟悉了些吧

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

还是同学录的那次随堂小测，算是软工实践的一个缩影。一开始是大家一起讨论确定需求，确定要使用的工具，再确定好分工，完成后，再把各自的模块整合起来。我们各自的模块感觉都完成得挺顺利的，但是最后整合起来却不尽如人意，大家一起找 bug 找了好久。各个模块的接口啊规范啥的，我们在编写的时候有注意，希望整合的时候不要出什么幺蛾子。现在回想起来，这样还不够，感觉还需要一个专门测试的人员。各个模块没有经过充分地测试，只是简单地跑出了一个成功结果，整合起来还是很容易崩的。找 bug 也不清楚具体是哪个模块的错，找起来也就更心塞。模块化，单元测试，代码规范，这些积木还是细致点好。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？

对下一届实践的建议，当然是一定要选实践啦，真是很难得的课程，选了不后悔系列，和其他的大作业完全不一样呢。软工的理论课感觉像职业规划，还是实践课好玩。对于要不要换队员，我没有离开队伍，也认识新加入的成员，就没有什么特别的感受。希望能不是强制要求换队员，而是允许申请加入其它队伍这样自愿的形式。初衷是模拟以后工作的真实情况，可我觉得没什么必要非要坚持。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）

萌芽阶段、磨合阶段、规范阶段、创造阶段都经历过吧，因为大家本来就是低头不见抬头见的同学，前面的萌芽和磨合阶段都很快，规范阶段再确定一下规范，就到创造阶段了吧。

五、怎样证明你学会了软件工程？

1. 研发出符合用户需求的软件
   必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
   团队的软件学士之路有在安卓园等平台发布

2. 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
   有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
   这些团队的 alpha 冲刺 和 beta 冲刺 可以证明的

3. 并且通过数据展现软件是可以维护和继续发展的。
   而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
   这些团队的 github BeiDouQiXing 可以证明