my everying

时间:2020-11-28 13:35:02

evering -> everything

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

1)对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么
通过一门课程一个学期的锻炼,不能说我取得了多大的进步。项目团队工作流程有初步了解,初次接触了andriod并且在我专业课之余保证了一定的代码量。不过我能够充分肯定自己的自学探索能力。

2)总结这门课程的实践总结和给你带来的提升,包括以下内容:
1、统计一下,你在这门软件工程实践中,完成了多少行的代码;
个人结对约600行,团队我估计600的两倍到三倍。

2、软工实践的各次作业分别花了多少时间?(做一个列表)
个人一 1070
结对一 1710
结对二 1840
以上三次作业有记录时间,其余团队作业没有记录时间。

3、哪一次作业让你印象最深刻?为什么?
ofcourse团队作业。时间持续最久,最令人头疼的团队作业。为此我学习了android,使用了github上别人的项目,独立地解决遇到的问题。此外作为组长我需要调动分配,亚历山大。

4、累计花了多少个小时在软工实践上?平均每周花多少个小时?
无法准确估计。主观感受是,我在每个deadline前三天的课余(白天和晚上)全部交给软工了。再加上其它间歇的时间,估计有作业的每个礼拜有24个小时的时间在做软工。我主观认为我花在软工上面的时间太长了,以至于舍弃了一些应该用在别的课程上的时间。

5、学习和使用的新软件;
android studio,visual studio

6、学习和使用的新工具;
没有

7、学习和掌握的新语言、新平台;
一些android,写了一点点python;Stack Overflow是解决问题的好去处,各种问题在必应国际版搜索关键词也能找到符合的结果。

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

9、其他方面的提升。
锻炼了检索信息的能力

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

在一些方面我是负面教材。在贝塔冲刺中我需要完成将pdf和与之分离的画布结合起来,我说干就干,使用最直白,最字面的方式完成它:获取pdf展示组件里的pdf的图片,再把它和画布合成。我费劲千辛万苦,搜索pdf展示组件里存储pdf画面的部分并且尝试把他从这个对象里取出来,花费了两天时时间探索,再花费一天时间寻找解决比例不合的情况,其中我对一些我的解决方法感到十分自豪,brilliant! 冲刺最一天我的确达到了我要的预期效果,但结果我没有把它整合进项目里。事后冷静思考,我所有的工作完全是自娱自乐。

没有整合是因为队友完成了文件切换的功能,而我不是在这个基础上开发的。这首先体现一些交流以及协同工作的问题。但是从根本的层次来讲,我的方法是不是一开始就不合理呢?

不兼容文件切换不仅仅是合并冲突的问题。我的方法使每台手机在查看完pdf后在本地生成新的结合pdf。这就是不合理的。这些事情应该提交到服务器来做,再提供下载,而不是每个人都生成一份独立的文件。

另一个方面,我们的pdf展示使用了github上的项目,而我对此太着迷了,一切都以迎合它为出发点。它没有显式地提供画笔的功能,于是我另一个最直白的解决方法是蒙上一层透明的画布,假装他们是一起的。本应该紧密结合的功能,实际上是如此的独立。我应该要做的是完成一个个性化的的pdf展示器,它提供画笔的功能,因此能够较好的解决两种画面的位置关系问题。

基于以上两个问题我的beta冲刺可以说是一场空。我的确解决了很多问题,做了很多的工作,但是我扣错了第一颗扣子,所以我没有办法展示我的工作成果,我没有办法邀功。问题在于我的盲目,看见局部解默认找到了最优解。

结论:不要凭借第一直觉开始打代码,‘’‘团队交流很重要’

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

对于另一次迭代的i:

  • 我建议没有实践兴趣的不要选择这门课,特别如果只是缺少实践学分要凑数的话。这门课要求大量的精力,来玩玩的话浪费自己的时间也加重队友负担;
  • 对于能力不强的同学也需要考虑受不受得住,可能需要在短期内学习新的语言并且运用,但是只要感兴趣并且积极学习,能力不会阻碍你;对于能力强的人这门课会给你大的展示空间,会得到满足感;
  • 我建议每次早点把作业排上日程,熬夜效率低下且不利于健康;

对于课程:

  • 我建议个人作业和结对布置在暑假,留更多的时间给团队作业;甚至在团队项目在暑假就把题目确定,撰写文档等;同时可以在暑假学习需要的语言。
  • 我不建议直接换队员,学习不是马上就好的事情,在新的团队发挥不了立即作用。我建议抽取人员后,各小组说明招聘信息,按职位上岗。

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

我们不如书中表达的那样理想,学生团队实际上更松散。萌芽/磨合/规范/创造中我们大于磨合小于规范。

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

对于各项来说,
(1)我们的软件没有来自大量用户的反馈;
(2)在作业要求下,我们完成了有项目规划/需求/设计/实现;在冲刺阶段我们使用了项目燃尽图约束我们的进度(详见阿尔法冲刺贝塔冲刺),但它的走向不如我的预期规划,也因此“足够好”的版本没有诞生;我们有熬夜;
(3)我们的代码没有说明文档,没有bug的发展资料。
我觉得满足全部的要求对于我来说太苛刻了。于个人而言,有限的时间与精力,我没有办法做得那么好。

六、我自己的话

软件工程让我非常劳累,尤其在我熬夜的时候,那种厌烦情绪是真实的。但是时间让我遗忘,现在回想起来,情绪已经变得很模糊:模糊的焦虑,其中有时候会有一些成就感。但是信息时代,这些数据都还清晰存在呢。邮箱里我最害怕打开的新评论提醒(来自老师的疑问);桌面的文档;相册里的那张我们穿着短袖在食堂拍的第一次会议照片,它被十天连续的我们穿上秋天的衣服的冲刺照片挤到了后面几页。它们提供明确的时间信息告诉我结束了。

还有什么也一起结束了?我对于新学期的个人展望结束了,现在到了验收时间。期望高于现实可以理解,但我也因此很久没有“履约”的快乐感觉了。

我不觉得自己学到了很多东西:一些简单的语言使用,一些粗浅的对于各种文档的理解。这门课程给出太多学习目标,大部分都在期限里被简单处理了。我最大的收获是开阔眼界。我看见别人卓越的写代码的能力和他们丰富的项目经验,看见我从来没有主动探索的领域还有很多新的知识。看见使我不至于因为没有比较或者像是井底之蛙而懒惰地前进。

我在凌晨的夜里富有自我批判精神。我感叹自我能力的不足,包括时间规划上的和写代码上的。我用睡眠时间弥补过失,我认为这是自我能力不足的证据,这太病态了。我期待自己成为一个不加班的程序员,良好的时间规划保证我在一定任务量下尽早成工作;强大的个人能力允许我完成额外的任务。我大概就是要表达一个我还有很多路要走的意思;然而现实意义上的路——距离我毕业的时间——已经不长了。

我在贝塔冲刺结束熬夜的后一天去跑了半程马拉松,我真切地为自己的健康感到担忧。不过我顺利跑完了我的项目。我的软工也是这样,花费我的力气,让我担忧,当你还在那个进度条的中间前进的时候,会真情实感地感到疲惫。不过到了终点然后缓一会,就好像能重新来过。我想要说,哪怕是我自己,在某个事情已经是过去式的时候,也没有办法再引用当时的感受,不能说“而已”这样的词语。所以我不后悔我当时没有做得更好,我只希望自己在今后做得更优。