zoukankan      html  css  js  c++  java
  • 提问回顾与个人总结

    提问回顾与个人总结

    项目 内容
    这个作业属于哪个课程 2020计算机学院软件工程(罗杰 任健)
    这个作业的要求在哪里 提问回顾和个人总结
    我在这个课程的目标是 提高自己工程能力和团队写作能力,能成为一名有一定经验的软件开发人员
    这个作业在哪个具体方面帮助我实现目标 对自己这学期进行回顾与总结
    以前提问题的博客 博客链接

    问题回顾

    问题1 单元测试一定要有最熟悉代码的人(程序的作者)来写吗

    ​ 我现在给出的答案是:不一定。

    ​ 这一点我在结对编程作业的时候深有体会,在该次作业中我负责实现(UI)的内核部分。尽管代码是我写的,我在测试的时候仍然有情况没有考虑到,而这种情况导致了我正确性出现了问题,当发现的时候已经很晚了。

    ​ 这是为什么呢,我认为:测试主要和应用的情形有关,测试的时候只看你在某这种情况下能否得到某这种结果,它大多数时候是一个黑盒,和是否了解这份代码的关系不大。就比如(lzy)学长会对我们的代码进行测试,难道他需要熟悉我们的代码吗,显然是不需要的。

    ​ 单元测试我认为由专业的测试人员来做是最好的。对于最熟悉代码的人来说,只是在改错的时候会好改一些。

    问题2 我们是否应该使用goto

    ​ 很遗憾,对于这个问题我无法给出一个新的答案,因为这一学期的学习过程中并没有使用到(goto)也没有阅读到相关的代码。

    ​ 我现在仍然持和作者相同的观点:只要有助于程序逻辑的清晰体现,什么方法都可以使用。

    问题3 为什么要进行结对编程?

    ​ 当时我是认为结对编程是没有必要的。这一学期的学习让我感受到结对编程并不是我想象中的那样用处不大。

    ​ 首先是在结对编程作业中,有时候写代码完全有可能出现一些自己都没有意识到的错误,这个时候另外一个人可以适时地指出错误,相当于一边写一边审,这样代码的质量就得到了保证。特别是代码量较大的大工程中,这种工程的(debug)往往会比较复杂(写扫描线时深有体会),结对编程看似降低了效率实则节省了不少时间。

    ​ 其次是在网安大作业的时候,我和我队友一起学习了(RSA)(SHA256)算法并把它们实现。因为我们是一边学习一边编程,在遇到问题时互相交流,一起思考,对这两种算法的理解逐渐加深。因为我的编程能力和算法水平比队友高一些,在实现过程中队友表示学到了一些以前没有学到的其它算法和编程技巧。最终在大作业完成后我和队友两个人都彻底理解了这两种算法,结对编程提高了我们的学习效率,这是母庸置疑的,正所谓三个臭皮匠,顶一个诸葛亮,两个人思维的碰撞肯定是要优于一个人的。

    问题4 要成为领域的专家才能进行创新吗

    ​ 怎么说呢,我现在既不是什么领域的专家也没有进行什么创新。对于这个问题我仍然给出我当时的答案:我想那些所谓拿手领域之外,是没有本行那么擅长,但是和本行有一定关系的领域,他们有一定程序的了解,但是没有行业内的专家了解的深,从而思维会比较容易发散一点,少一些惯性,可以从一些不同的角度来看问题,从而比较容易做出一些创新,正所谓当局者迷,旁观者清吧。

    问题5 如何衡量一个人在团队中的绩效?

    ​ 我想这是一个很难具体量化的东西。不过从这学期的体会来说,我认为可以综合以下几个方面来考量:

    • 工作能否按时完成,因为一个部分不按时完成可能影响整个团队的进度。
    • 工作完成质量,这决定着最终成果的效果。
    • 工作难度,如果工作比较困难,那么完成后有更好的绩效理所应当。
    • 对团队的贡献度,举个简单的例子:(PM)。这个角色将我们整个团队融为一体,变得更有凝聚力,让大家整体达到了(1+1>2)的效果。

    ​ 此外,还可以根据个人自评和组内互评进行综合评价,尽管可能会有一些主观色彩,但是在相对简单的环境下,这种办法还是相对客观的,最后可以让个人对别人的互评结果进行评价。

    ​ 总的来说,衡量绩效是需要多方面考量的,希望在以后的生活中能对这个问题有更好的解答。

    新的问题

    问题1

    ​ 在(alpha)阶段结束后有一个强制转会阶段,我们组走了一位同学也迎来了一位新同学。因为我们组是在(beta)阶段才进行的前端开发,所以新同学开始工作开始的很顺利。但如果新来的同学需要接手离开的同学的工作,是否会比较困难,特别是在项目规模和难度较大的时候。新同学如何更好、更快的融入团队中呢?

    问题2

    ​ 我们组的(PM)是个相当负责的(PM),除了完成自己的一些本职工作,在小组的开发过程中遇到困难时,他也参与其中,这给他带了较大的工作量。那么(PM)是否需要参与到项目开发中呢,在组员遇到困难时(PM)应该做些什么呢?

    在实践中学习

    ​ 正所谓”做中学“,在这门课的实践过程中我也学到了不少东西。

    需求阶段

    ​ 学到了(NABCD)模型,其中(N)(Need)(A)(Approach)(B)(Benefit)(C)(Competitors)(D)(Delivery)

    ​ 我们的产品需要弄清楚客户的需求,然后能用我们独特的方法给用户带来好处,而且能超过我们的竞品。同时,我们需要想办法推广我们的产品。这样能够清晰的明确我们项目的目的。

    设计阶段

    ​ 主要通过完成技术规格说明书以及功能规格说明书这类以文字为主的文档来对我们需要实现的东西进行描述,帮助我们进行分析与设计。

    实现阶段

    ​ 这一阶段学到了如何把控项目的完成情况。

    ​ 比如每日例会都会对昨天完成的任务进行总结即每日都会有进度报告。

    ​ 在(github)上我们会开相应的(issue),在完成后把(issue)关掉。根据燃尽图便能清晰的看到我们的工作进度。

    测试阶段

    ​ 测试不能只在项目的最后进行。如果项目后期发现了问题,问题的根源往往是早期的一些设计,很可能牵一发而动全身导致大面积重构。所以一定要边开发边测试,确保软件从开始到最后都没有问题。

    发布阶段

    ​ 发布的时候需要考虑到用户的使用难度,我们在(alpha)阶段的时候只做了核心没有做前端,这对用户是很不友好的,愿意用一下我们(API)的同学是真的大好人(笔芯)。以及发布时的文案怎样更吸引人也是值得考虑的一点。

    维护阶段

    ​ 用户的反馈对于开发团队来说很重要,用户们能帮助开发团队更好的发现问题,认识到自己的思维盲区。如果(bug)较小应该及时修复,如果(bug)比较严重则需要考虑对整个项目进行大更新。

    心得体会

    个人项目

    ​ 个人项目让我初步认识到了单元测试的重要性,单元测试的质量直接决定了我的代码的质量。

    ​ 同时,在(lzy)助教的指导下,我学会了如何进行高质量的代码管理。比如提前配置好(.gitignore),一些不必要的东西不要上传到(github),不仅慢而且会显得仓库很冗余。还有(commit)的时候的描述一定要清晰易懂,这样才能搞清楚这一次提交所完成的工作。

    结对项目

    ​ 在这次作业中,我感受到了契约式设计的意义。我们在编写之前就约定了核心类相关的接口设计,比如几何对象怎么表示,用什么容器来存储这些几何对象等。这也是我们实现松耦合和高内聚的基础。我们我队友各自主要负责一个模块,最后可以和别的小组实现的模块互相拼接,有着极高的灵活性与自由度,这种松耦合和高内聚也非常有利于团队项目的开发,毕竟不可能一个人完成所有的工作。

    团队项目

    ​ 这是这门课中持续最久,也是最重要的一个项目。

    ​ 我也是第一次在7个人的小组中和大家一起经历这么长实现一个项目。最大的感受就是团队协作的重要性,每个人要做的不仅仅是完成自己的工作,还需要和别的组员沟通交流,团队任务不是个人任务,闭门造车不可取,与别人的交流必不可少。不然的话这个项目只会是一堆零散的碎片而不会形成一个完整的项目。

    ​ 同时,在团队项目中,大家共同学习,互相促进,尽管不同组员之间负责的工作内容可能有一定的差异,但是在交流的过程中多多少少也会对组员的工作有一些了解,有时候也可以给负责其它工作的组员提供一些不同角度的对问题的看法。

    ​ 在这过程中,我不仅扩展了自己的知识面,还锻炼了自己的人际交往能力、团队协作能力,这是一笔宝贵的财富。

    最后,感谢老师和助教这一学期的辛苦付出,祝这门课越来越好!

  • 相关阅读:
    POJ-1189 钉子和小球(动态规划)
    POJ-1191-棋盘分割(动态规划)
    Java实现 LeetCode 730 统计不同回文子字符串(动态规划)
    Java实现 LeetCode 730 统计不同回文子字符串(动态规划)
    Java实现 LeetCode 729 我的日程安排表 I(二叉树)
    Java实现 LeetCode 729 我的日程安排表 I(二叉树)
    Java实现 LeetCode 729 我的日程安排表 I(二叉树)
    Java实现 LeetCode 728 自除数(暴力)
    Java实现 LeetCode 728 自除数(暴力)
    Java实现 LeetCode 728 自除数(暴力)
  • 原文地址:https://www.cnblogs.com/MountVoom/p/13154783.html
Copyright © 2011-2022 走看看