完结撒花

团队博客作业

这个作业属于哪个课程 课程链接
这个作业要求在哪里 作业要求
团队名称 你的代码我的发
这个作业的目标 项目总结以及组内成员总结
Github地址 https://github.com/GrapeWell/yifenhuanbao-1

一、团队成员

姓名 学号 角色
周昊 201731062333 组长
徐裴 201731062402 组员
黄啸风 201731062430 组员
李涵 201731062406 组员
颜依婷 201731062505 组员
周小萱 201731062601 组员

二、团队成员总结

周昊

第一次博客传送门

问题解答

问题1:
    从书中第二章所提到的设计有实际意义的软件工程作业看,就是说现在的计算机专业布置的作业很书中所说的一样,大部分不是软件工程作业,从我暑假做的JavaWeb项目中就能感受到两者的区别。那么就是说一个学生团队,里面每个人的技术水平参差不齐,各自的学习方向也不一样,那么怎么才能提出一个适合的、能够完成的软件工程项目,以达到在校积累项目经验的目的?
答:
    闻道有先后术业有专攻,一个项目的提出,其实提出的时候,每个人都不知道是否能够完成项目,如果在项目提出的时候回答这个问题,那多半答案是可能可以完成、大概率完成、可能完不成。所以说,在学完这门课之后在加上其他类似的课程之后,项目能否完成是可以被量化的。项目可以被分解为多个任务,每个任务又可以被分解为多个小任务,每个小任务都会根据难度、代码量去估算花费的时间,算在一个人头上就是花费的工时。通过计算总的工时和预定的工期,就能够明确项目到底是否能够完成,当然这是在不出意外的情况下,就是理想状态下的。

问题2:
    看了第四章-二人合作后,很有意思,尤其是结对编程,两个人坐在一起,看同一台电脑,使用同一块键盘,有点二人合奏钢琴曲的意味,但是这种方式运用在编程中,是否造成了一种资源的浪费?两个人一起编程,那谁来写,谁来监督呢?还是一个人当组长,另一个当组员的这种团队的关系吗?
答:
    结对编程在完成第四次个人作业的时候体验到了,结对编程最好的地方就是写代码很快,两个人的想法覆盖面更广,而且都很有效,但是就是天平也不是一定是平稳的,当往其中一方倾斜时,说明一个人的任务变得很重了,明明是结对编程但是一个人在完成两个人的工作,这时候天平的倾斜可能会导致结对的破裂。在博客里面也说过我认为1+1=1才是最好的。

问题3:
    看了第六章的敏捷开发的介绍和特点后,感觉敏捷开发是交流大于了软件开发的过程,似乎经常都在交流、沟通,强调效率,那么怎么才能够保证软件的质量?这样做出来的产品真的可靠吗?如果敏捷开发团队的组员水平参差不齐,效率变低,又怎么办?
答:
    使用敏捷开发如何去保证项目的质量?质量的保证在与代码的评审是否能够做到位,遇到的bug、error是否能够解决,交流与沟通恰恰是保证项目质量的一种方式,通过不断地交流,会有意想不到的想法,就和结对编程一样,思路会拓宽的,这就是团队的力量。团队成员参差不齐,考验的是团队的负责人、项目经理,怎么做到每个人都发挥出自己的力量,那是管理的问题,最好是人尽其才。
问题4:
    看了第十六章-IT行业的创新后,现在信息发达,好点子层出不穷,我想问,就是一个大学生,或者一个大学生团队怎么才能在大学这个阶段进行创新?当自己有好点子后又怎么才能凭借自己仅有的能力和经验将它实现,如何锻炼自己的创新能力?
答:
    创新,对于大学生这个阶段来说是最好创新的,因为有想法,有平台,不用顾忌很多东西,同时创新是来自于探索与实践,在实践中反思。
问题五:
    看了第十二章-用户体验后,就是说用户体验,应该是用户使用过后的体验,那么在做产品的时候,是通过什么方法或者什么方式去设计一个用户界面使得大多数人都能够普遍接受的?是通过量化的数据吗?如果一旦,一个产品的用户体验极差,那么这个产品是回炉重造吗?
答:
    在这次项目开发过程中,真正的体会到了用户体验对用户有多么的重要,用户使用其实不看你怎么实现的,就是看你的界面美不美观,响应速度快不快,功能是否满足需求等等,看用户体验好不好,还得说管它是好马还是坏马拉出来溜溜,让别人用你的项目,你从用户的反馈中就可以知道项目的体验是好还是不好,然后在根据反馈去完善项目。

收获与总结

收获
    当pm很累,不管是沟通还是对自己技术的要求,各方面的能力的要求都很高。这次也学会了服务器部署,git管理等等。
总结
    在这次旅程中,我是开火车的司机,自身车技不好,对我来说路程些许颠簸,看组员们的那些总结都挺好的,但对我而言,我觉得这次是半失败的,项目是做完了,但是管理过程上面,代码管理的不好,沟通方面也不到位,感觉一个项目做下来,除了开始的时候,是大家的想法的综合,后面的大多都是我一个人的想法吧。


李涵

李涵同学的第一次博客传送门

问题解答

问题1:结对编程

    在项目的实际开发过程中,也有了一定的结对编程的经验,两个人甚至整个团队之间的默契和沟通真的是其中相当重要的一环。沟通顺畅的结对编程是可以起到1+1>2 的效果的。但如果沟通不畅会导致项目进展缓慢,代码问题增多反而不利于开发。

问题2:需求分析

    面对分析所得需求和现实所需之间的差距,也没找到什么好的办法,敏捷就完事了。在面对不停变化的需求,唯一能做的就是不断改变自己。

问题3:用户体验

    至于之前第一次博客所提到的年轻人所追求的多功能与中老年人所偏好的简单实用两种不同需求之间的冲突,我所能够想到的就是功能选择,软件设计为灵活的插件模式,只提供最基本的功能,但是可以提供可实现各种功能的插件用户可以自行选择。

学会的新技能

    测试 无论是单元测试,还是项目的功能测试和测试用例的编写我都在项目的开发过程中积累了一定的经验。

总结与收获

总的而言,学的还是挺多的。

  • 首先,写博客,这学期真的写了很多的博客,整个人都很开心。
  • 熟悉了github的操作,很久之前就开始用GitHub了,一直都是在下载,学习别人的代码,上传自己的代码还真是第一次。
  • 虽然是第二次使用敏捷开发,但是暑假的那次太赶时间了并没能体会到敏捷开发的妙处。这次的开发经历还是令我对敏捷的开发流程有了更加深入的了解。
  • 用到了很多实际开发中需要用到的工具,比如墨刀等。
  • 还是测试,项目开发初期很长的一段时间内,我因为自己设备的一些问题,无法参与到项目实际的代码开发流程中,于是就从事了项目文档的编写和测试工作。之前小组中大家都没有对B/S web项目的测试经验,我就借此机会学习研究了一下项目测试方面的知识,收获颇多,学习测试的过程也对我的编码有了一定的促进作用。

黄啸风

第一次博客传送门

问题解答:

问题1:

      在上这堂课前,我是抱有很大的疑惑的,我们也没有真正按照团队模式进行项目开发过,虽然后面我们也没有按照“秘密模式”的团队模式进行,无法对其进行亲身体验的回答,只能结合自己在项目开发的过程和书本上学到的东西来回答,我们项目开发采用的是敏捷开发模式,在开发过程中,我们有经常进行会议报告,项目进展汇报,但是在这样的情况下,我们的项目仍然还是在后期面对许多的麻烦,如果是如秘密模式那样执行,团队对项目进展没有一个较好的把控,那么也不好及时的做出项目开发规划,我认为这是相当严重的,所以个人认为这个秘密模式还是不太推荐,但是我们可以吸取一些它的优点,在项目开发过程中,不应该给予团队成员过大的压力,但是正常的进展报告,会议交流是必要的。

问题2:

      我们的项目开发采用的就是敏捷开发,在这次项目开发过程中,有遇到这样的问题,进度跟不上,然后每日例会的时候汇报自己的进度及问题,如果某个队员真没有及时完成规定的任务,完成了任务的队员会一起帮忙讨论解决,然后自己再加一点班,尽量让任务解决,不拖延,有了同伴的帮助一般都能较好的跟上进度,这就是每日例会带来的好处,它也是真正的能够给队员和项目带来帮助的。

问题3:

      我不认为软件开发的思维会制约自己的客观思维,在这次项目开发过程中,我们就是首先针对的对用户进行需求获取分析,然后才开始进行项目开发,并不是一昧的以自己项目开始,只会编代码的软件开发者是不合格的,同时软件开发者有自己的特点,这也是软件特色,我反而觉得会很好。

问题4:

      对于这个问题,我只能根据自己的项目经验和学习的书本内容来回答,在项目的需求分析,软件设计,测试阶段,不应该进行过多的会议,这样会耽搁太多的时间,得不偿失,但是在开发编码阶段,我觉得每日例会是很重要的,这个时候这个时间就花的很值,对项目的帮助更大。

问题5:

      完全的平衡每个用户的需求是不可能,我们能做的就是尽量的把握用户关心人数较多的需求,从而舍弃或者降低一些其他的需求,因为有的需求会对其他需求造成矛盾,所以同理心的存在是必要的,毕竟用户是第一,有了同理心才能跟好的融进用户的群体。

收获与总结

      经过学习,运用书本上的知识到项目开发中,着实让我受益匪浅,让我学会运用敏捷模式于项目开发中,通过项目实践对实战经验大为增加,另外还有团队之间交流合作,每日例会以及任务安排让我明白团队的分工合作以及任务汇报交流也是非常重要的,就是在这样的模式下,我们的这次项目过程比我以前的经历显得更加的标准程序化,软件开发的效率比以前大为增加。另外的技术知识倒是其次,团队开发流程,测试方法,代码规范等等的学习才是更大的收获,让我对软件以及软件工程的理解更深。


颜依婷

第一次博客传送门

问题解答:

问题1:
     第五章在个团队模式中,应该怎样选择适合自己团队的团队模式,团队模式很多,不可能一个一个的尝试,那样会耽误项目进度,但是如何选择才可以最有效的提高项目开发效率呢?
答:
    在项目开发中,可以供选择的开发模式有很多。在书中第五章也提到,当在面对不同的用户或者软件需求,所选择的开发模式是不同的。在书中也介绍了很多案例,分别举例在不同的场景下使用不同开发模式的优点以及缺点和不足,来判断是否应该选择该开发模式,所以团队模式的选择要结合项目本身,从时间、成本、效率、软件需求各方面来评估,进行选择。

问题2
    第八章在投资力度和用户满意度的相互关系中,因为很多用户自己的要求都不一样,那么产品生产出来后,或许有些地方就可能令其中一些用户不大满意,所以在开发产品之前,又该怎样评定在哪些部分投入力度大一点,哪些部分较弱一点来平衡每个人的要求,从而提高用户的满意度呢?
答:
    对于一个软件项目,应该抓住用户对于软件的需求,对于不同的用户集体可能有不同的需求,应该结合软件面向的群体来对该群体用户进行需求的获取。在书中第八章内容也提到对于不同的利益相关者,展开不同的需求获取途径,不同的用户对于一款软件的需求部分可能有所不同,然后通过跟用户面谈、市场调查问卷等各种方式获取需求,然后软件分析人员再根据不同用户的需求进行评定最后的着重部分。

问题3:
    第十章典型用户和场景部分,在开发软件之前,需要做一系列的工作定义用户角色,还有定义典型用户的模板,但是在现实生活中是很多变得,为什么要拿一套固定的模板去套用,那就该放弃那部分不符合典型用户模板的人吗?其中在用户调查中,我们所知道的很多用户可能并没有按照自己的真实情况进行填写,那么我们所选择的典型用户中还是会和我们定义的模板要求有差距,那又该如何平衡呢?
答:
    在软件项目开发中,因为不知道软件所面对的用户群体到底是哪种类型,都是很多变的,所以就需要模拟不同的用户角色,可能很多用户并没有按照真实情况来填写相关内容,但是也不能排除没有相关情况。在书中第十章也有写,对于典型用户的定义,应该选择受欢迎的典型用户和不受欢迎的典型用户,但是最主要的还是要明确定义软件的用户对象,从软件定义的用户出发选择典型用户和场景。

问题4:
    第三章的团队对个人期望中,我有的疑问是,如果当个人由于一些原因无法完成团队安排的任务时,团队该如何合理的分配任务,又该如何处理个人的行为呢?怎样才可以使团队以一种最好的状态一起合作呢?如果团队中个人的功能完善后,又该如何帮助其他人做自己不熟悉的部分呢?
答:
    在软件开发中,应该针对每个人的实际情况对任务进行合理的分配,如果当意识到个人无法按时完成任务时,应该提前提出来,然后让团队一起商讨解决方案,不然会因为个人的原因而降低团队开发效率。在书中第三章也有讲到,要衡量个人能力,根据实际分配任务,个人也要做到对自己任务的负责,书中也举了相关案例分析团队合作会遇到的问题以及解决方案。在一个团队中,每个人应该在完成自己那部分内容的同时在自己能力范围内的帮助团队人员,使得团队以一种积极向上的氛围进行项目的开发。对于自己不熟悉的部分,可以帮助队友查相关资料,做一些自己可以帮到的小事。

问题5:
    第三章在介绍全栈工程师部分,将全栈工程师比作街头卖艺的单人乐队,结合实例我所理解到的意思是全栈工程师就像是即会写乐谱的作曲家还是会满场奔走的演奏家,那么按照这个比喻来看,如果有了全栈工程师那么你就可以把整个项目从头到尾自己一个人完成了,那么那些学习想前端或者后端并非全栈的同学又该如何做选择呢?
答:
    作为一个全栈工程师在开发过程中不需要沟通成本,各个技术都懂,在小公司中可以降低团队沟通成本,但是现在很多全栈工程师是前端后端都会,但是都是会一点点,做不到专门研究相关前端后端人员那样的细致以及专业,全栈就是一种经验,一种思维,资深的全栈工程师都是经验堆出来的,并不是你自学前端后端都会就可以了,即使那样你可能学的也只是一些皮毛,而且现在技术更新也是特别快,很多东西可能在你学习的时候流行而当你工作的时候就不流行了。对于想学习非全栈的同学,可以学习自己喜欢的部分,专注学习,将那部分内容学精,或许以后技术会更新,但是在你很精通的前提下,再学习新的部分还是比较容易的。

收获与总结

    经过这学期的学习,更加深层次的了解到一个开发项目的详细过程。在阅读书本的过程中,了解到项目开发中从开发模式的选择、如何做需求分析、用户体验、软件测试再到最后项目的发布这一系列过程,使得在以后的项目开发中可以更加的得心应手。在这一次的项目开发中,我也学到了对一些软件的操作,对于框架的使用,对于不懂的部分就百度相关内容,寻找解决方法。
    在学期的学习过程中,感悟最深的就是团队合作写项目,就像是一次团队成长一样,每个人用心的完成自己那部分的内容,遇到问题自己解决或者提出来大家一起讨论,每个人都为了项目付出自己的努力,也没有出现谁不做的情况,组长也是很负责的组织着大家的工作,让我感受到了团队协作的力量,这是一次很愉快的团队合作,这学期的学习过程也是非常愉快的,虽然中途因为项目进度和项目问题等原因而焦头烂额,但是最后通过大家一起解决了问题并发布了项目还是很有成就感的。


周小萱

第一次博客传送门

问题解答:

问题1:
    我们作为大学生应该如何做到不受以往经验的影响去以另外的角度思考同样的东西的同时保持专业可行性呢?
答:
    学习完之后我的理解是,在日积月累的知识存储的过程中,我们的大脑已经习惯性的保持了对某事物的专业性思考方式,在以另外的角度思考的时候是会下意识的保持专业性,就和肌肉记忆一样,那么就剩下以另外的角度去思考而不受以往经验影响这个问题了,在学习课程做项目的过程中,因为是负责前端,所以常常需要切换成用户的角色去体验我们项目的功能,反而能够发现更多的问题,这样再去做的时候就能更好的进行开发。

问题2:
    作为大学生怎样才能培养PM项目经理具备的能力呢?
答:
    作为一个PM项目经理最重要的能力或许不是编程的能力,而是与人沟通,协调合作的能力,以及懂得如何合理分配资源,发挥团队中成员的优势的能力。查阅资料以及自己的切身体会,我发现这样的能力单单通过书本是无法培养的,书中说要明白沟通目的,沟通主体,沟通语言,可是当实际上做起来的时候,却会遇到很多书中没有提到的问题,每一个沟通的主体是不一样的,性格不一样,所以沟通方法不会适用于每一个热人,所以要想提高这样的能力,除了看书之外,还应该多参加活动,特别是需要开口说话的活动形式,不断开口,不断锻炼自己,在和别人沟通的时候要更加注意哪些是合适的,哪些是不合适的。这样才能不断的得到提高。

问题3:
    对于编程语言和软件工程都没有说最好的,只有最合适的。构造出来的软件我们也说的是足够好的,而不是最好的。那么我们应该如何选择最合适的方法呢,又怎么去判断我们选择的是最合适的,如果逐步去试,那么在需要很快开发的时候如何把握时间呢?
答:
    这个问题在学习的过程中已经有了一定的答案,比如从开发流程来说,有写了再改模式,瀑布模式,再一步步到敏捷开发,整个开发过程再不断的进步,这是前人们已经为我们找到了合适的方法,他们的经验教训告诉我们什么样的项目适合什么样的方法,我们已经有了很大的优势,这样就不用逐步去试了。

问题4:
    做减法的设计是好设计吗第12章第一节中提到了遥控器的例子,在试用软件的过程中,我们往往会发现实践上用户常常使用的功能就是那几个,那么我们还有必要花大量的时间去开发和维护那些很考究技术能力但并不实用的功能呢,是不是还不如多花时间在用户经常使用的功能上。但这样我们的技术就很难得到拓展。所以做减法的设计是好设计吗?
答:
    嗯......这个问题在开发项目的过程中有一点变得清晰了,在做项目的时候,我们是优先做的主要功能,也就是问题中所说的用户常常使用的那些功能,但在做完这些功能之后,我们仍然会去做那些不常用的功能,为什么呢?因为不常用不代表不会用,这个项目是作为一个整体出现的,而不是某个单一的功能,部分功能的用户体验差,即便他不常用,但还是会影响到整个项目的体验感受,所以无论是常用的还是不常用的都需要花时间去开发,只是存在一个优先级的问题。

问题5:
    在第13章中13.5.1中提到了一个有错不改的例子,是关于excel中判断1900年是闰年的一个bug,但如果修改的话会影响到其他的软件,涉及到很大的工程量。可是在技术上却没有任何问题,那今后遇到了牵扯很大或者几乎没有影响的bug难道就可以不管它了吗?
答:
    我去看了书上给出的博客链接,里面给出了大大小小的出现bug的事情,出现bug的原因,测试用例不对的关系,也有考虑不周到的关系,博客中提到的比如说没有想到2008年会有366天,还有到2008/2/29程序改为了2006/2/29,以及广州出租车计价器无法识别闰年,损失了30万。
    同样是关于闰年的问题,Excel是为了要支持Lotus1-2-3的数据文件格式,所以延续了这个错误,如果要改正这个问题要牵扯到兼容性问题,会在现实生活中造成很大的麻烦,所以便没有改正这个bug,但是在广州出租车计价器这件事就非改不可了。所以同样的bug在不同的问题上的影响是不一样的。修改与否还是要看实际的问题影响大小而定。

收获与总结

收获
    掌握了git的使用,首先是通过博客作业中提供的方法,掌握了简单的git使用方法,其次更多的是在项目开发的过程当中,向团队的小伙伴们学习到的。
    再一个就是学习到了关于整个项目的开发流程,项目开发过程中要做那些事情,这一部分主要是通过课堂上老师的讲诉,然后在团队项目中一步步理解实践,加深体验。
总结
    学习过程中,感觉整个团队做一个完整的项目出来很不容易,也更加理解软件工程真的是一门工程,而不仅仅是像我最开始想象的那样,只要把程序做出来就可以了,开始编程前的需求分析,调查,对一个项目是否成功很重要,除此之外,在程序之外的文档也十分重要,因为程序不单单只是写给我们自己看,还有可能会给其他的人看,看得懂的程序是十分重要的,在团队开发中,一开始也犯了许多的错误,导致用户体验不佳,这是之前没有想到的,还有就是有一个测试别人项目的作业,在那次作业中测试许多其他团队的项目,完全是作为一个用户去体验的,所以能够发现许多的问题,当然也让自己对自己的项目反思了许多。可以说是一次很不错的体验。在这一学期的学习过程中,无论是团队间的合作,还是学会有步骤的开发项目,还是从别人的项目做学到的,都有很多很多,这次课程学到的技术不是关键,反而更多的是学会了对项目开发以及团队之间合作的方法。


徐裴

第一次博客传送门

回答问题及总结

(1)Look Back at first individual assignment.

    回望第一次个人作业,我对于软件工程课程的想象和提出的问题:

    重新阅读我之前的博客,看到了我学习这门课的初心:

     “软件工程这门课将会记录我的学习,对我的学习起到监督作用,写下学习的过程更是在不断的勉励着我的学习。更重要的是这不仅是一门理论课,我们需要动手实践!我们无法改变之前的学习,但是我们可以做好现在。任何差距都是可以弥补的,只要你愿意为此花时间。”

    也看到了之前在阅读课本之后,所提出的一些疑惑:

    question one :这是来自教材的 “第五章:团队和流程” 的问题,我的困惑是:随便找来的七八个人,在这里被称为“乌合之众”,但是真的是这样的吗?什么又才能被算作团队?
    question two :这是来自教材的 “第七章:实战中的软件工程7.2.8” 的问题,我的困惑是:在讲到学习所有经验的那里,提到在学习过去的经验的过程中要避免让过去的经验妨碍解决现在的问题。是不是就不去学习前人的经验了呢?
    question three :这是来自教材的 “第十二章:用户的体验” 的问题,我的困惑是:文中的茶壶问题,用户对于事物的需求?哪种创新设计又才会得到人们的认可呢?是不是创新与设计必须应该根据人们的需求来设计呢?
    question four :这是来自教材的 “第十六章:16.1.5” 的问题,我的困惑是:课本中开始写道“要成为领域的专家才能创新”,我们不断的学习拿学位为的是成为某个领域的专家,然后在最后又写道往往很多创意来自于“领域外”的创新者。这不就是矛盾的吗?既然外领域的人比此领域的专家更有创意灵感,那么“只有成为了某个领域的专家,才能创新”又有何意义?
    question five :这是来自教材的 “第十六章:16.1.6” 的问题,我的困惑是:书中说道“技术是创新的关键”,在后面提到了有些人把“功能的增加”和“技术的创新等同起来”,那么功能增加了是否就是真的做到了技术的创新了呢?
当时的自己也是信心满满的呢,加油~

(2)Try to answer my previous questions.

    对自己提出的问题进行解答,并阐明。(是如何通过看书,实际,或者讨论弄明白的):

question one :
    现在看来,觉得自己当时对“乌合之众”理解有了自己的见解,而且现在我对“团队”又有了更深一步的了解。

    网上的解释(百度百科)是:“乌合之众”就是比喻临时杂凑的、毫无组织纪律的一群人。“团队”就是由两个或者两个以上的,相互作用,相互依赖的个体,为了特定目标而按照一定规则结合在一起的组织。

    现在我看来:举个例子,只是单纯的因为某些原因所以进行了组队。比如说就是单纯为了完成我们这门课的学习任务,然后再没有人进行组队的情况下,随便的找几个人进行组队。这是就是所谓的临时的凑在一起完成某个学习任务。因为真的想做好项目的人,会在之前就提前找人进行组队(这也只是我个人的看法)。在之后的项目确定,到项目进行,从α版本到β版本,如果不是一个真正的团队那么就会出现很多的问题。

    那么我就来讲讲我的认识,我认为“乌合之众”就是很随意的凑到一起,刚开始并没有什么自己的目的性,别人叫你做什么,就以此为自己的目标,在之后也只是为了达到这个目标而草草交差,其做的东西的使用价值不大,因为大家的用心度可想而知。而团队会让几个人组在一起,使得所有人觉得在过程很有目标,很有动力的。他们都有相同的目标,相同的出发点(至少在协商之后会达成一定的共识),在实践的过程中,大家进行了周密的计划,不断地通过交流,互相的学习,自我学习以此弥补自身的不足,并努力发挥出自己的力量,到最后完美的完成了之前的那个目标。

question two :
    在进行实践的过程中,我也渐渐的认识到了这个问题,因为我们在一些自己不是特别熟悉的领域进行实践的时候,往往会遇到一些自己束手无测的问题,有些人喜欢去网上搜索已有的解决办法,但是有的人喜欢自己去专研解决。其实我在这个时候,第一反应就是求助,因为我自己搞的话,花费的时间很多,但是去查阅资料,去问别人的话会来的很快。但是我个人觉得,这其实并不好。但是借鉴是在所难免的。

    如果是在紧急的时间段遇到了问题的话,我的建议是问别人和进行查阅,参看前人的经验,但是有的是时候,每个人下载的软件版本不一样,所处的环境不一样,有的问题也不会得到解决,甚至有的问题再网上你根本查阅不到。这个时候,在自己弱小的力量下,是很难快速的解决问题的,你就需要求助组员,毕竟人多力量大。在我看来我们这个阶段所遇到的问题,其实并不会太难,都是初级的学习阶段 ,其实我觉得现在网络上那些前人的经验对我们的阻碍作用并不大。但是不能养成那种一不懂就进行搜索的习惯,有时候反思一下自己为什么会报错,为什么没有效果,其实对自己的学习很有用,而且即便是在网络上看到了前人的经验(或者使用此方法解决了问题),一定要对问题吃透。还有就是,我觉得再解决问题之后做好记录其实是一个挺不错的方法,毕竟那么多的错误,你不可能一直记得,或许在过几个星期,就会忘记,做好记录,对于之后实践,可以节约相当大的一部分时间。

question three :
    其实在我现在看来,很多时候,至少是在初期的时候,我们是要根据用户的需要来进行的。因为那个时候,我们的能力水平并没有到达一个层次,对于市场的需求等等,不能做到很好的认识。那时候自己的见解并不深厚,有时候很容易做出错误的判断和决策。只有进行了一定量的累积,从质上有了改变。那个时候我们就会进行自主的创新,但是这并不是否认之前不能进行创新。在有一定的把握,技术达标,相信自己的宣传度,以及带有支持性的时候,我们是可以创造出需求的。那么在这个需求上我们又怎么会没有自己的创新和设计。这里想到了数据库老师讲的一句话:“现在我们所能够学习到的可能就是只有这些知识,但是说不定以后你们就会创造出新的知识和算法,那个时候我就会给我学生讲到,现在我们学习的这个知识是我以前的学生做出的。”这不就是这个问题最好的解释吗?

    那什么样的创新设计才会得到认可,只要符合道德,合法,并且得到了一定范围的应用的,又怎么可能没有得到认可。达到用户期望是不可能做到完美的,就像软件,只要用心的做了,用户用着还行,真的解决了问题,并且对它进行维护,升级的软件的就是肯定会被人认可的。

question four :
    我对此的看法仍旧如初的坚持,并不是要成为领域的专家才能创新,创新任何时刻都可以,任何人也都可以。只是在创新一个东西之前,我们对自己索要创新的东西,哪个东西处的领域是肯定是必须要又一定的了解的,不然又怎么会有创新。只是一般在某个领域的专家,在学术上创造的东西的量会更多。

question five :
    对于这个问题我的观点也是没有什么改变的。有些时候功能的增加并不是创新,但是有些又算是。因为一个软件是必须要具备基本的功能的,有些人在此上添加的功能可谓是无用功(比如在一些比较正式的软件上),但是比如社交网站的新功能可能就会带来更多人的喜欢。这里必须要解释一下,什么是创新。(这里的创新是百度百科里面的解释)创新是指以现有的思维模式提出有别于常规或常人思路的见解为导向,利用现有的知识和物质,在特定的环境中,本着理想化需要或为满足社会需求,而改进或创造新的事物、方法、元素、路径、环境,并能获得一定有益效果的行为。这里有一个词很关键,获得一定的效益。所以综上所述,有些时候功能的增加并不是创新,但是有些又算是。

(3)Are there any new questions?

    是否产生了新的问题?请提出:

    在进行小组项目的时候,现实和计划的其实还是有很多的差别。那么对于这个有什么有效的解决办法呢?

    在我们项目进行的时候,就自己来说,总是会觉得有时候自己的完成度很差,现实和计划的差别有时候还是蛮大的。虽然给与我们的时间已经是很充裕的了,但是自己在实践的过程中,觉得突发的情况还是蛮多的,导致自己对的进度相对来说比较慢。

    但是最后在小组长的调节带领之下,觉得我们小组在项目的进行上面真的是比较的有序,每日的例会也是带来了很多的好处。

    那么还有没有其他的有效办法可以解决类似的问题呢?

    还有就是自己在学习的时候,总是觉得自己学习的东西在项目中的应用的效果比较差,有时候学习起来动力自然就减弱了。那么项目在进行的时候,进行新知识的学习,是一步一步的学习,还是先借鉴别人已经有的类似的案例呢?
    这个也是我在进行小组项目的时候比较突出的一个问题了。

(4)what new skills have i acquired?

    经过这学期的学习,你掌握到了哪些以前没有的技能,你是如何掌握的:

新的技能:

    巩固了之前对于javaweb粗浅的学习,现在觉得恨过功能在是实现上遇到问题也知道大概是哪个方面的了。而且有些地方的实现上面,看到了自己的很多不足,有很多地方可以进行优化。

    现在觉得其实每一个东西的实现方法有很多,但是其原理都是大同小异的,只是看你怎么写。

    为了能够再进行项目的时候不那么的困难,我再此期间还对Java进行了学习(只是皮毛,语法之类的)。

    还及进行了一些js代码的学习书写(虽然现在也只是粗浅的学习,但是发现先了自己下一步想要学习的内容~)。

How?

    通过看一些图书馆借阅的书籍和看哔哩哔哩上面的教学视频,跟着教程进行的学习。通过小组人员的教授(效率真的很高哦,这样,速成~)

    而且还明白了一个道理,一定要一边的学习,一边的尽行实践,因为有些东西是别人在敲,自己没有动手那些东西都是印象不够深刻的,而且学习的时候一定不能只是进行那一部分的练习,那样的学习效率也是不高的,需要自己进行一些独立思考的练习才行。

(5)What profound experience? And my conclusion.

有什么深刻的体会,对自己一学期学习过程的总结:

    在此次的小组项目中,大家都真的很努力呢,也觉得自己有时候真的是很想早早的保质保量做完自己分配到的任务,但是每次感觉都做的没有完成的特别好,也觉得有点自责,但是组长和组员们都很热心,教我怎么我弄,给我讲怎么弄。很开心能够遇到这些伙伴,能够和他们一起完成这么棒的项目(至少在我的心中觉得我们做的很棒)。我真的要卯足劲把自身的技术能力给提高,觉得这方面真的很欠缺呢。

    而且我现在认识到进行小组项目的时候,一定(必须)具备高度的自觉性,别总想着别人,也别拖着,感觉自己就有点,在这里批评一下自己,真的没有合理的安排时间呢,所以在最后的那段时间里面,我也在增强这方面的自觉性。

    经过了此次的小组项目,我觉得其实自己的收获也是很多的。在和同学的协作上面,让我懂得了一定要对自己的任务守时,而且在进行项目的过程中,一定要有高度的自觉性,这一点是非常的重要的。在学习上面,我也是对之前的知识进行了很多的巩固。以前都是自己写写前端的代码,大那是这次被分到了后端,自己也进行了很多的实际的操作,真的感觉自己学到了很多那些所谓的那些实践之后的经验。

    以前在进行学习的时候,我可能更加注重的是,自己需要报所有的知识点给学到,但是现在看来,其实纳言的学习的效率并不高,因为你自己在进行学习的过程中,只是依靠视频里面所讲的那些东西,其实印象里对那些知识点是不够深刻的。但是如果是结合项目进行的学习,对于自己来说,知识点会吃的更加透彻,因为那些东西是自己在动脑去写,在思考,而且遇到的问题都是新的。(因为在视频里面的教学练习一般没有错误,都是别人调试好了的)

三、资料提交

资料提交网站
在这里插入图片描述
    说明:项目的文件包含以下四个,需要完整的下载才能运行。
数据库文件单独一个。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

posted @ 2019-12-14 18:55  恭喜發財  阅读(226)  评论(2编辑  收藏  举报