• 软件工程-提问回顾与个人总结


    提问回顾与个人总结

    项目 内容
    这个作业属于哪个课程 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ
    这个作业的要求在哪里 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/3377
    我在这个课程的目标是 培养专业的软件开发能力。
    这个作业在哪个具体方面帮助我实现目标 对这门课程一学期的学习做一个反思和总结。

    一、对应的提问博客

    第一次阅读作业

    二、对博客中的问题进行解答

    1、提前写好单元测试应该可以算作提前做好规划设计的一项具体要求,正如大二下OO课程中要提前写好规格一样;

    然而对于编程经验并不是特别丰富的大部分人来说,这个过程往往困难重重,因为实际的编码和提前的设计会存在不小的差异;

    那么,如何解决这样的问题,是否是经验不够的原因?或是设计的不合理?或是有什么其他的诀窍呢?

    解答:

    ​ 经过一学期的实践,我觉得这个问题主要从两个方面:

    ​ 一是项目规划对每个子任务是否足够明确,如果对于整个项目以及对应划分的子项目都有比较明确的规划,那么设计与实现的差异往往仅体验在过程中的细节而不会影响对应API的功能,也就不会因为过程代码的变更导致与测试产生矛盾;

    ​ 二是代码风格,如果代码的可扩展性灵活性较高,那么即使需要根据实际情况对代码进行少量变更也是一件比较容易的事情不会带来太大的工作量。

    2、书中这一章节具体地阐述了这样地问题,但是并没有说明应该如何避免或是当发生这样地问题时怎样解决;在实践中,我们应该如何在这些极端中寻找一个合适的平衡点?

    解答:

    ​ 我觉得主要在于分清楚主次,首先需要对一个项目框架有非常深入的了解,不需要搞清楚所有的细节再动手,但是必须要先清楚整个框架结构,才能知道哪些部分是至关重要的必须搞清楚才能动手的,哪些部分是次要的可以一边实践一边摸索改进的。

    3、这是一种我一直在追求的编码规范(虽然在稍大一点的项目中一直做得不好)…

    常规的做法,就是按照自己的设计不断地把大函数细化;

    但是实践中常常有一些函数代码和功能不够简练,却无法再进行分离细化,遇到这种情况应该怎么做?

    寻求其他的函数设计?

    或者可以允许项目中少数函数出现这样的情况?

    解答:

    ​ 这个问题,我觉得是一个比较泛化的问题,难以一概而论,理想的情况当然是书中所说,只做一件事并且做好,但是一件事可大可小,并且有时候做好一件事说起来简单实现的代码却是比较复杂的,我们应该尽可能做到代码的简练,尽可能将方法函数细分以使其足够灵活。但是实际中我觉得这样的要求可根据相应情况做一些调整,不一定非得强求。

    ​ 以我们的项目物理网站为例,刚开始接手代码的时候,真的觉得控制器代码风格非常差,部分方法很长很长,我们也力求将其做一些改进,但是最后发现部分方法确实无法进行过多的优化,只能通过添加注释以及改善代码风格使其结构更清晰,同时因为我负责大部分的自动化测试工作,阅读了大量的laravel框架的底层代码,我发现即使是其底层代码,也同样存在很多较长的方法代码,这样的情况是无法避免的,但是得保证代码的结构总是很清晰的。

    4、这种当面开会的形式有助于更好的实时交流,但是是否会影响到审查的效率?尤其是一个问题需要冷静思考的时候。是否可以将工作分为多个阶段,比如先进行各自思考审查,然后分两次讨论,一次初步汇总,方便大家提出各自的问题,第二次进行最终汇总。

    解答:

    ​ 我觉得开会的效率的确是一个比较容易被忽视的问题,最重要的一点在于事先得计划好这次开会需要探讨什么问题进行什么交流,否则真的很容易出现一种情况就是:为了开会而开会,大家到会的目的是应付一种程序,却忽略了开会的目的是汇报工作的同时进行有效地沟通并一起解决各自遇到的问题然后对接下来的工作进行进一步的规划。

    5、程序员则觉得自己开发的功能必须有几个高级选项,才显得有水平。

    这样的心理可能确实是存在的,当然实际并不可取,因为是否实现某一个功能应该看用户的需求,但是对于某一些软件中的“高级功能”,的确有一定需求;

    但是也带来一些副作用:

    1、需求不是很明显,但是却需要耗费大量的时间;

    2、部分“高级功能”难免会存在用户使用困难的情况,这在某些时候反而影响用户体验;

    针对第一点,开发时应该如何拿捏这样的度?

    针对第二点,或许可以通过添加使用说明这样的方式解决一些用户使用的困难,但是仍然带来了一些不便利的因素,能否有更简单易行的方案(占在用户的角度)?

    解答:

    ​ 这个问题,我觉得应该交给用户来解答,作为一个开发者,应该尽可能地去了解用户真正的需求和体验,可以多收集用户的反馈或者自己团队内部去多方面地体验自己的产品,也就能真实的感受到哪些需求是真的有价值的即使花很多时间也值得,哪些需求性价比较低可以暂时不考虑。

    三、各阶段学到的知识点

    1、需求阶段

    ​ 需求阶段最重要的就是近距离的接触用户并进行有效的沟通和调查。我觉得主要分为核心需求,加分需求和次要需求。

    ​ 核心需求也就是客户最急需的需求,是必不可少的,整个项目至少需要实现这些需求才能被用户所认可;

    ​ 加分需求也就是并非必须,但是如果具备相应的功能能大大提升用户的使用体验;

    ​ 次要需求也就是用户并不非常看重,使用频率不高,这些需求可以根据相应的时间条件做相应的取舍。

    2、设计阶段

    ​ 设计阶段最重要的在于明确且合适的规划。

    ​ 明确也就是对项目的各个阶段各个模块的要求有明确的定义,不至于盲目入手而影响工作效率。

    ​ 合适主要指的是相应的规划是否具有可行性,对项目的规划既不可过度乐观也不可过度悲观,得先有一个大概的实施方案一次确定这个部分具备可行性,然后其中具体的细节再留到实践中解决。

    3、实现阶段

    ​ 实现过程最重要的在于团队合作的效率。

    ​ 尤其是遇到一个问题,如何进行有效的沟通和调整快速的解决,如果自己遇到问题长时间无法解决却不和团队中其他成员进行沟通,再或是某一个同学在某一个模块困难较大进度缓慢团队却没有丝毫的调整,这都会严重影响团队工作的进度和效率。

    4、测试阶段

    ​ 测试阶段最重要的就两个字:全面。

    ​ 不要仅觉得产品的主要功能没有问题即是完成测试,应该想到如果有大量的用户使用我们的产品,那么触及边角情况的概率将会大大增加,所以也就要求我们在测试时尽可能覆盖到所有的边角情况,至少需要保证对于所有的异常情况,产品不会崩溃最好能有具体明确的提示。

    5、发布阶段

    ​ 发布阶段不仅仅关乎团队内部,我觉得关键点比较多,比如如何让用户快速上手我们的产品,比如尽量保持与用户的沟通以获得相关的使用反馈等。

    6、维护阶段

    ​ 维护阶段心得不多吧,我觉得比较重要的是处理问题的效率,比如用户反馈了一个问题或是团队发现服务器出现了某一个异常情况应该尽快解决并做二次测试以保证问题的确定解决。

    四、理解和心得

    ​ 一学期的软件工程应该说还是学到了很多干货吧。从一开始的前端后端开发,再到后来逐渐接手自动化测试,对网站的开发已经有了不少的了解和实践,并且第一次进行这样的6人以上的团队开发,对自己的意义也是非常重要的,收获了很多以前无法得到的经验吧。

    ​ 整个过程给我最大的感受是,要做好一个系统的项目,真的需要太多方面的知识,曾经我们做过的课程设计实现过程相对是比较单一的,大多数情况都是用一种语言写一个工程,程序功能也是以一种比较单调的方式呈现出来。然而在这次网站开发的实践中,我发现这一个项目从头到尾真的涵盖了各个不同方面的知识,不管是部署维护,或是代码的编写,都需要我们对相应的知识有系统的了解,这对每个人的学习能力有相当的考验。同时,软件工程开发中,不仅需要具备较强的编码能力,还需要具备良好的沟通能力和团队合作意识。

    ​ 最后,要感谢课程老师和助教整个过程的悉心指导,也很荣幸能和一些优秀的同学合作学习。完成了这样的项目,我收获的不仅仅是知识,还有经验,自信和友谊。希望软件工程课程越来越来,同时自己也要再接再厉,继续加油!

  • 相关阅读:
    HDU 2444 The Accomodation of Students (判断是否是二分图,然后求最大匹配)
    HDU 1045 Fire Net (二分匹配)
    Leangoo如何颠覆传统项目管理软件?
    团队协作神器:Leangoo
    Leangoo-让工作更简单
    leangoo 轻量级项目协作和列表管理平台
    团队协作中的“贵族”leangoo
    使用leangoo实现多泳道任务看板
    项目管理工具到底应该为谁服务?
    《精益创业实战》读书笔记
  • 原文地址:https://www.cnblogs.com/zgj982393649/p/11100581.html
Copyright © 2020-2023  润新知