2017软件工程实践总结

一、蓦然回首

(1) 对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?

一开始就特别期待能够找到一群靠谱的人,从一而终,结果被破坏了。一开始就期待能够玩出新花样,期待栋哥所说的一起出去玩,结果无疾而终。

上软工实践课之前,就是一门心思想着体验一下项目开发的全过程,好歹我也能假装自己有过项目开发经历,如果能够再接触一门语言就更好了,现在,目标基本是实现了。跟队友体验过如何从零开始开发一个项目,也入门了Android。同时,也完成了从“把github当仓库”到“真正使用github来进行代码管理”的转型。

但是在文档编写方面还是没能得到训练,因为基本上都是PM在写这些东西,我接触的不多,就是负责编码,所以这方面没能达到之前的预期目标。

(2) 总结这门课程的实践总结和给你带来的提升,包括以下内容:

  • 1、统计一下,你在这门软件工程实践中,完成了多少行的代码?

    差不多4500行吧。

  • 2、软工实践的各次作业分别花了多少时间?(做一个列表)

    作业 简要描述 用时(小时)
    第一次 开班博客 3
    第二次 数独 5
    第三次 部门管理软件设计 2
    第四次 部门管理软件实现 5
    第五次 团队作业 119
    第六次 个人技术博客 4
    第七次 华为软件云评测 5
    第八次 课程总结 7
    总计 150

  • 3、哪一次作业让你印象最深刻?为什么?

    数独作业,因为没做好,所以印象特别深刻。

  • 4、累计花了多少个小时在软工实践上?平均每周花多少个小时?

    累计150个小时左右,平均每周10个小时。

  • 5、学习和使用的新软件

    AndroidStudio、Gitkreken、Typora

  • 6、学习和使用的新工具

    git工具、processon在线协作绘图工具、以及各种markdown在线编辑工具、

    VisualStudio单元测试工具、墨刀在线模型设计工具

  • 7、学习和掌握的新语言、新平台

    Android、java、AndroidStudio

  • 8、学习和掌握的新方法

    原型设计、单元测试、查看错误报告、代码调试、模拟测试数据、团队协作、百度

  • 9、其他方面的提升

    熬夜能力以及挨饿能力大幅度提升


二、人月神话

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

定义:

三个以上的个人实践根据某种规则密切联系成为一个统一的整体,我们称这样的总体为团队实践。

性质:

团队实践应具有以下性质:

  • 团队中的个人都要遵守统一的团队规则
  • 在形式上,个人之间是独立的,可以并发执行
  • 在内容上,个人实践是紧密联系,缺一不可的
  • 个人实践之间应该两两互不矛盾。这个包含两个层面:个人的代码不会影响其他人的结果,同时自己的代码不会受其他人的代码影响。

鉴于以上性质,加上自己的实践,总结出以下经验:

  1. 每个人都有自己的习惯和风格,但是在团队中,就必须以团队准则为准,习惯和风格应该统一化,便于交流。而且团队必须要有自己的规范,包括代码规范、文档规范等等。在同学录作业上,因为没有时间来制定具体的规范,所以导致在编码过程中出现了很多的问题。有的时候看不懂别人的代码想要问写的人却因为时间及没办法详细解释,就会在一个地方卡很久,时间就悄悄地溜走了。
  2. 并发性很重要。千万不能因为其他人的某个模块还没写好,自己就不知道怎么往下继续写自己的模块,然后一边焦急的等待别人又不断地催促着别人。这样很容易引发矛盾。特别是在诸如要以前面的人的输出作为输入的情况下,要自己去模拟数据进行测试。
  3. 为了每个人之间的代码尽量不互相冲突,那么就要尽量做到不碰别人的代码,最好是连别人的代码文件都不要去碰。在同学录的作业中,一开始没有这种规定,所以最后导致每个人都在疯狂的往同一个文件里面写代码,改代码,最终的结果是编码5分钟,解决冲突两小时,关键是还不知道究竟哪一个才是对的,改来改去,可能前脚刚修复的bug后脚就被人改回去了,然后就会发生出现bug之后互相推卸责任的问题,“这不是我写的,不是我的问题”,“这个我刚才明明改过了,又被谁改了,我又得改”……然后就炸了。
  4. 因为在团队编程的过程中,其实也是要个人进行编程,很多时候别人是帮不了你的,那么这个时候就要自己学会调试bug。因为我们做的事Android,所以我有一些关于写Android的建议:
    • 善用Log函数输出调试信息,这样可以很方便的就看出到底程序是执行到那里崩溃了,不用一行行去调试,效率大大加快。
    • app在模拟器或者真机上运行的时候突然崩溃了,一般都会弹出一个错误报告,千万不要随手就关闭了,要认真去看这个报告,这个报告明确指出程序崩溃的原因以及问题出现在哪个文件的第几行,可以省掉很多事,直接找到病源然后对症下药。尤其是在对付空指针的问题时。javaa最常见的问题就是空指针,一旦出现空指针,那么多代码谁知道到底哪里跑出了一个空指针,但是错误报告会告诉你在哪里,这就让它无所遁形,又快又准。

三、前车之鉴,后世之师

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

关于对学弟学妹们的建议,第一点就是软件工程这门课如果没有选择实践课,那么基本是学不到什么东西,因为理论近乎扯淡。然后你会发现上课好无聊,然后就默默的拿出手机,默默地等待手机没电,下课去借移动电源,上课继续玩,或者干脆睡觉,或者直接翘课。所以一定要选软件工程实践课,不然大三上绝对是最无聊的一学期。

第二点就是要摸清老师的套路和习惯,慎重选择。如果听到要在团队中施行人员流动的,千万别选。如果见到小黄衫,不要激动,课上到后面就不值钱了。

关于下一届要不要换员,虽然我已经学会了接受,但是我还是坚持不要强制换,这是这门课最大的败笔。虽然换了没有想象中的那么坏,但是同样的也没有所说的那么好。想走的可以,但是不要强制。不管不强制会不会导致没人换还是什么的,反正我觉得强制换人就是不好。就算是怕因同学之间的几分薄面或是虚伪的不舍(当然也会有真心实意的不希望)而导致不强制就没人换的结果,以至于让老师做出强迫换人的逼迫,那么被逼迫之后,也许收获的会是不堪的真相。实在想要施行这种方式的话,建议直接分出一个班,明确说明要换,其他班不换,接受这种方式的就选这个班。


四、团队分析

我所处的两个团队基本都是属于积极的初学者,“我都不知道自己不知道啥”这句话说的太好了。

第一个团队:萌芽阶段是在第一周到同学录作业之后。磨合阶段和规范阶段是杂糅的进行的,持续时间也比较长,直到最后的冲刺,才算是达到了创造阶段。

第二个团队:我到的时候就是创造阶段,之前的事不大清楚。


五、自我证明

(这又是一个不知道怎么回答的问题……这还用证明?我还不会啊,怎么证?)

1)研发出符合用户需求的软件

Stardust在第一阶段就已经有实际用户在用了。

学士之路也在安卓园上面发布了,点击链接可下载使用

2)通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件

团队作业从最初的需求分析到文档编写再到后面的编码,都是一步一步的走过来的。每个人都有明确的任务以及github的commit记录,并不存在大佬单干和临时熬夜的情况,这个从团队的github提交记录都是可以看到的。

Stardust:

学士之路:

3)并且通过数据展现软件是可以维护和继续发展的。

软件的文档在github上也都有,对不熟悉项目的人了解项目是完全可用的。我转到新团队后就是看了一天文档,然后就可以融入他们的工作了。


七、个性发挥,包括图文、照片和创意等

给大家讲个短篇故事:

从前有个小矮人,叫凌鹄,他还有六个兄弟,被人们称作七个小矮人,后来在白雪公主的带领下他们开始了各种征战,最后凌鹄战死,飞到天上变成北斗七星中的一颗。



潘多拉魔盒:本文内容比较敏感,所以加了密码,请老师助教私聊我要密码。

最后,感谢老师和助教一学期的辛勤付出。

原文地址:https://www.cnblogs.com/jiuweilinghu/p/8119831.html