zoukankan      html  css  js  c++  java
  • 福大软工 · 最终作业

    福大软工 · 最终作业 - 软件工程实践总结(个人)

    福大软工 · 最终作业 - 软件工程实践总结(个人)

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

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

    大一的时候经历过一次的博客作业,软工作业开始前我去回顾了一下之前写的那些博客作业,心情既羞耻又感慨,但更多的是感激和遗憾,感激过去的自己的学习和成长方便了现在的自己,遗憾过去的自己没有完成好现在的自己看来可以做得更好的事。之前的遗憾加上到了大三但自己还是没有什么拿得出手的技能的恐慌,我怀着这次一定要好好做好的心情开始了门实践课程,但总的来说,我对我这一学期的实践经历特别失望,虽然并非是一无所获,但是距自己的期望有着很大的偏差,一方面也许是期望定得太高了,另一方面是这一学期的自己确实差劲。

    在这门课程中我的所学所练所得大概可以分为以下两方面:

    • 专业技能
      • 编程语言方面,C/C++的编程能力有了一定的提高,接触了vs的单元测试和性能分析,对代码质量的要求也有了一点点的提高。接触入门了Python和PyQt,但没怎么用,只会皮毛;
      • 软件开发的一个流程有了实际的认识和体会,软件开发不只是代码,还包括了需求分析、测试、维护等诸多环节,对将来所能从事的工作有了更多更深入的了解,在这一系列过程中画图、文档编辑能力意外增强;
    • 综合能力
      • 沟通交流的能力,在结对作业中和对友进行了很好的合作和配合;
      • 学习能力,每次的作业的要求里几乎都有从未接触过的东西,每次完成作业前都要去学习掌握一些新的知识或者技能,学习或者可以说是面向百度的学习能力有了很大提升。

    存在不足的方面有:

    • 编程能力还是太差,实践过程中真正有编程成果的编程活动只有个人、结对作业,学习语言中的编程,团队编程中没用的右侧弹窗。这方面特别需要再多动手;
    • 团队合作能力特别烂,始终没能融入团队,自己能力太差导致我的团队体验很差,也很抱歉自己给团队的成员带来了很不好的团队体验。
    • 自我调节能力太差,认识到了自己真的很没用,迷茫绝望,但只是一味的沉浸在丧的情绪里没办法把自己拔出来,越陷越深,让负面情绪拖着自己不采取实际行动做出改变,浪费了很多时间和精力,对不起过去的自己的期望,让将来的自己觉得遗憾。

    总之,自己目前离着合格的计算机专业本科毕业生还有好长路要走,离优秀更是遥遥无期,打算考研,让自己能够离目标越来越近。

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

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

    写废的不计数,完成的主要有:

    • 个人作业:413(词频统计);
    • 结对作业:1061(升级版词频统计);
    • 团队作业:0(完成的只有一个右侧的隐藏弹窗,百行左右,但是根本没用上,算是0吧);
    • 学习代码:436(学习过程中写的代码)。

    总共是1910行,特别少,很遗憾。

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

    作业名称 耗时(小时)
    福大软工1816 · 第一次作业 - 准备 4
    福大软工1816 · 第二次作业 - 个人项目 21
    福大软工1816 · 第三次作业 - 结对项目1 16.5
    福大软工1816 · 第四次作业 - 团队展示 0.5
    福大软工1816 · 第五次作业 - 结对作业2 22.6
    福大软工1816 · 第六次作业 - 团队选题报告 0.5
    福大软工 · 第七次作业 - 需求分析报告 8
    福大软工 · 第八次作业(课堂实战)- 项目UML设计(团队) 6
    Alpha 冲刺1-10 20
    福大软工 · 第十一次作业 - Alpha 事后诸葛亮(团队) 1.5
    福大软工1816 · 团队现场编程实战(抽奖系统) 6
    Beta全过程 1
    福大软工 · 最终作业 - 软件工程实践总结(个人) 5

    不完全统计,好多时间算不清楚。

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

    提一个让我挺梗的,分最低的吧。团队选题报告这次算是第一次正式的团队作业吧,因为业务上的不熟练,第一次安排任务时的说法是分批干活,这一次多干的人下次少干,我被分到了下一批,这次作业没有任何任务,周末的课堂汇报我因为回家看病也没有参加,最后根据我们组要拉开干活与没干活之间的差距,多劳多得的分配原则我的百分比很低,本次作业分数很低。没有干活分低很正常,之所以提这次是因为一方面这次作业的分数和之前个人结对作业相比是跳崖式的下跌,所以心里有点咯噔,另一方面,也是更重要的一点是,这是团队的第一次任务,但是我全程都没有任何参与,无论是事前的准备,还是课堂的汇报,这种一无所知的开始是很让人恐慌的,团队经历的开始并不十分美丽,一个不完美的开始挺让人失落的。

    4、累计花了多少个小时在软工实践上?平均每周花多少个小时?同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答;

    从个人学习进度表上看是223小时,按16周算每周是14个小时左右。

    开篇博客的回答是:

    我的期待是少熬夜。现在对将来任务的具体情况还不太清楚,先将时间初定为十小时吧,上不封顶,但求效率

    从时间上看,算是超额完成预期了吧,而且还有些与软工相关的时间没有算入统计。但是很遗憾没能够在花费的时间里实现“但求效率”,虚耗了很多的时间。个人、结对作业的时候目标明确,知道哪些要做,然后围绕着要做的事去拼命地学,虽然很苦花得时间很多但很充实,最后的成果也让我特别满意,团队作业的过程中经常陷入不知道有什么要做、不知道哪些是我要做的、不知道我能做什么的迷茫之中,花的时间多但是不知道自己做了些什么,瞎操心但没有事做,瞎忙活但没有成果,付出时间收益很低,效率极低。总之就是前期和中期花在软工实践上的时间特别多,几乎每天都在做软工,一天由三部分组成:日常生活、上课和软工,后面倒是很长一段时间都陷在与软工有关的丧里了。

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

    • Axure(原型设计);
    • Typora(Markdown文档编辑);
    • Xmind(画图);
    • pycharm(打码,少用)。

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

    • vs的单元测试、性能分析。

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

    还都只是入门阶段:

    • Python;
    • PyQt;
    • GitHub。

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

    • VS的配置、单元测试、性能分析;
    • 代码规范。

    9、其他方面的提升。

    • Word文档的编辑;
    • Markdown文档的编辑;
    • 语言组织能力;
    • 对自己的认识。

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

    • 对于个人:
      • 在个人实践中我的最大经验教训是要做好时间规划安排,预留缓冲区,应对意料之外的事。比如,在进行个人作业过程中,我经常在作业刚发布时悠闲码字编码,导致deadline前的爆肝,前期悠哉效率极低,后期爆肝太伤身体,所以完成任务要做好时间规划,要在心中将deadline提前。
    • 对于结对:
      • 两个人之间的沟通交流是比较方便的,所以一定要做好;
      • 任务的划分和进度的安排要合理,接力式的任务安排特别不好,因为众所皆知鸽子的叫声是“马上就好,明天能叫,不好意思,就差一点,咕咕咕咕”,人类的本质是鸽子,一方鸽了另一方空的时间浪费了,任务进程就会很紧张。同时也要尽量减少两个人任务的重叠交错部分,因为两个人同时有空的时间还是挺少的;
      • 要及时向对友汇报进度,让对友知晓作业的进度,特别重要的一点,deadline前一两天的晚上睡前告诉对友自己睡了,不要突然消失,对友会很生气,这种剩我一人孤军奋战的感觉,特别惨淡,尤其在deadline深夜。
    • 对于团队:
      • 团队的人员组成要合理,至少要保证合得来;
      • 团队的任务分配和安排要合理,尽量不要出现有些人闲的没事做,有的人一堆活没做但却没时间做交不出来,有人叫着任务太多太重;
      • 团队中的每个人最好要定期汇报进度安排,让组员都知道发生了什么,不能完成的任务尽量交付出来,避免影响团队的整体进度,另外,团队需要一个进度的监督者;
      • 团队要有凝聚力,不要一味强调个人,分得太细,也要适当的考虑合,当然要有第一点作为基础才比较好做到这点。

    三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,对于同期的TA们,对于后来的学弟学妹:

    1)你有什么想建议、告知和期许想要告诉他们呢?

    • 对开学初的我说声抱歉吧,没有办法从一至终的坚持,辜负了当时的期望,凉了当时的热血,还有要对开学初的我批评一下,不要以为大一的我真的那么水,回头看总是觉得容易不过如此,身在其中还是挺茫然挣扎的,相信当时的我也是尽力了。

    • 对后来者,这门课是一门参与感很强的实践课,经历过后或多或少都能有所收获,收获多少取决于你的投入吧,希望你们能够用心投入不留遗憾吧。

    2)特别地,特别地,下一届要不要中途换队员(强制的、彻底的从一队换到另一队)?假设依旧是一个90+人数的大班

    我觉得还是了,被交换的队员要面临很大的压力,既要对原组之前做的任务做好安排,又要对新的组去了解,和新的组员进行沟通,而且不同组使用的开发语言、工具很有可能不一样,这又是一个繁重的学习任务,这学期课程多,这门课的节奏又快,被换的太惨了,所以还是不了吧。

    3)身在一个格外大的班级,竞争强劲,你认为一个组的人数应当在多少比较合适?

    一个组的力量不是简单的人数的相加,团队的凝聚力很重要,但是人多也不一定就不好,记忆罐头那组人数最多但做得最好,PM优秀有领导力,团队氛围特别好。大概6-8个人左右吧。

    4)个人/结对/团队作业应该控制在怎样的规模?

    既然我已经结束这门课了,我是不是可以建议规模越大越好。

    从这门课的学分2分,以及这学期的课程数来说,这门课的作业规模有些太大了,几乎全部的课余时间都要花在这门课上,有点让人招架不住。但我认为这一学期的个人、结对、团队作业都是那种乍一看好多好累,真正做起来确实好多好累,但是拼一拼都是能够做完的,从这一点上来说,这些作业的规模还是比较合适的,让我们看到了自己究竟能到逼到什么样的程度。

    5)这学期下来,你最感谢的人是谁?有什么话想要对TA说呢?

    我最感谢的人是我的对友肖地秀,结对的经历很愉快,团队中她给了我很多帮助和鼓励,这一学期在软工作业上几乎都和她捆在一起了,超级感谢她,为她爆灯( • ̀ω•́ )✧

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

    我认为现在的团队应该算是处于规范阶段了吧,萌芽和磨合阶段是必然经历的,团队作业的前两次团队展示、选题报告让我们互相认识,经过需求报告、UML到Alpha冲刺,团队出现过交流沟通的问题,出现过任务互相阻塞的问题,但是解决问题的过程中大家加深了彼此之间的了解,对于完成作业的合作流程也越来越熟练,到了Beta冲刺,大家对于彼此之间的了解基本确立,大佬们挑起了团队的担子。最后的创造阶段目前还未达到,估计还有很长的一段路吧。

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

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

    必须公开发布,有实际的用户,一定的用户量和持续使用量 (3 天后能保持10 - 100个用户);而不是: 做没有用户使用的软件

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

    有项目规划/需求/设计/实现/发布/维护,有定时的进度发布 ; 而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄

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

    而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料

    4)对着这个检查表:http://xinz.cnblogs.com/p/3852177.html 检查一下,自己如果去企业面试,这些常见的问题是否都能回答,并在此总结。

    请在随笔中用数据证明上述内容或侧重选择之一。

    • 我们团队开发的软件针对的用户是消息多的年轻群体,这类群体具有快速处理消息的需求并且乐于接受新鲜事物,并且消息的处理是频繁需要的,因此产品发布之后,会具有一定的用户量和持续使用量,具有一定的实用价值;
    • 一次次的作业发布为软件开发制定了大方向,一次次对作业完成的规划划分了这些大方向,形成了一项项计划和安排,我们团队在计划上完成的还是挺不错的,用leangoo看板管理进度安排,但是由于沟通交流和时间紧张,在完成计划上存在着一些拖拉的情况,偶有延迟交付的情况发生,但最终能够交付出满足基本需求并且有一定完善的软件;
    • 团队用GitHub管理源码,每阶段也都有博客作业或报告作为文档,但没有很严格的代码管理,也没有很好的资料整理记录,没有规范完整的测试,开发的规范性,软件的可维护性有待提升。

    六*(选做)、阅读软件工程中关于代码质量的的经典论文,从下列文献中选择一篇或若干篇,结合自己的实际做一个阅读笔记(例如,自己写的代码质量如何,是不是一个大泥球,如何衡量自己代码的质量)?从以下参考论文中选择一篇或若干篇:

    参考论文文献:

    [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

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

    • 经历了软工实践后的收藏夹:

    • 经历了软工实践后的文件夹:

    • 经历了软工实践后的我:
      又是一次遗憾。

  • 相关阅读:
    Bresenham画线算法
    DDA算法
    GL_LINES & GL_LINE_STRIP & GL_LINE_LOOP
    贝塞尔曲线
    弱引用
    Lambert模型
    ShadowVolume
    Phong Shading
    求反射向量
    Vertex Modifier of Surface Shader
  • 原文地址:https://www.cnblogs.com/z031602148/p/10247452.html
Copyright © 2011-2022 走看看