团队工作心得体会Ⅱ

工作阶段总结:完成前端功能的开发,以及前端与后端接口的设置与连通。游戏进入一个十分粗糙的版本。

  心得体会

首先,关于新知识学习阶段。由于此次我是从后端突然扔到前端开发,因此我对前端一些网页开发的语言知识,并不是很了解,只能强行上手。可以说,在整个功能开发过程中,我是十分痛苦的,因为对于js语言没有一个大体的认识,但看一些功能以及方法,函数体的话,不知道它究竟是怎么工作的,以及其语言特性。后来,在组长的建议下,我通过一些别人代码的例子,逐渐了解了phaser 和js语言的特性,这才让开发过程慢慢走入正轨。由此,我收获的经验是,面向example编程,不失为一种快速学习新语言的好方法。因为它不仅能让你从感性上认识该种语言的代码风格,还能在具体的函数体使用,变量使用,编程思想上,给予你全面的指导。

其次,在团队协作方面。其实,我觉得这次前端界面开发,是有一处败笔的。那就是,我和另一个组员一起在开发前端界面,虽然前面是说两个人开发的内容不重叠,各自开发各自的功能模块,但是,到了后面,就开始暴露出来了各种问题。第一,体现在,代码风格上。由于另一个组员的代码风格和我的完全不同,这使得我很难读懂他的代码,而且,在一些全局变量的设计上,两个人的命名习惯也不同,甚至出现全局变量和局部的冲突,这导致了整合过程中,出现了很多奇奇怪怪令人糟心的BUG,大大破坏了程序的完整性。其次,还体现在代码管理上,我们都用的是GitHub管理代码,但是我们两个人开发的代码都在同一个文件上,这就使得我们在同时开发的过程中,push和pull变得极其繁琐,既要兼顾自己的代码,又要兼容对方的代码,一旦修改了对方的代码,对方又不知道,极易使得代码突然崩溃。又或者己方改了代码,push上去了,而对方在push之前忘记了pull整合代码,这又使得己方的代码可能被覆盖。在开发过程中,我就有过,因为这种事情,导致我的本地代码和远方被另一个组员修改的代码多方面冲突了,而且回退版本也解决不了,甚至把本地的越弄越乱,最后,我只能选择,删库跑路(划去)。重新创建版本库,把自己的代码重新写一遍。

最后,还有一个感受就是在api前端后端接口对接上。真的,我们队的主要前后端功能都在一个半个星期前就完成了,但是对接现在却还是有些问题。因为事先没考虑到对接过程中的一些情况,就草草开始,结果到后面,对接的艰难无比。这体现在两个方面,一是前端不了解后端传入参数的格式以及意义,以及什么时候传入,而后端不知道前端需要什么数据,前端所需要的数据格式是什么,除此之外,还有传入和传出数据的数据流,以及一些特殊情况如不选择牌时,跳过时应该传入什么,这些都需要双方约定,一旦一个环节对不上,整个代码便会崩溃。经过这次对接的经验后,我的收获是,在进行api对接的时候,一定要先双方约定好再下手!!!即,双方先约定好每个流程,每个阶段,传入与接受数据的方式,格式,特殊情况的安排,阶段等,越详细越好,越通俗易懂越好最好是这个流程能在假设的情况下完完全全的跑通,没有任何逻辑漏洞。然后把这个api规定给写死,写成文档形式,然后让前端和后端都对照这个文档进行对接操作。Api对接文档一定要在开始设置接口前就写好,这能大大减轻后期对接接口时大改代码的风险。

原文地址:https://www.cnblogs.com/wispytrace/p/9175183.html

时间: 2024-11-10 14:00:48

团队工作心得体会Ⅱ的相关文章

团队工作心得

团队工作心得 六月已经过了一半,我们团队的项目的alpha版本也已经接近了尾声,但是由于进入了考试周,我们的组员们就很难像以前那样聚在一起写代码,现在由于要复习和考试,所以每个人写代码的时间非常少,所以可以从燃尽图中可以看出来我们的项目经历了一段加速下降的过程,然后最近又趋向平缓,以下就是我这半个月在团队项目中的一点心得. 团队进度需要量化 从老师说要用燃尽图和任务墙来量化团队项目后,我们组就遵守老师所说,每两三天都会对小组成员的工作进行了解量化,然后绘制成燃尽图和任务墙.由于我在我们组是主要撰

听大树(宋晓楠)老师讲《高效工作与时间管理》心得体会

偶然的机会,能够听大树老师的时间管理,经过这两天的反复思考和体会,以及阅读了几篇同伴的写得心得体会,我也想把我的心得体会写下来!共同学习! 先说说大树老师的时间管理观念! 图1 大树老师在讲解 总体来说,就是收集整理->搞定->回顾, 这样的一个循环过程 一.收集 这个从六个方面来说:工作.身体.心灵.家庭.圈子.财富, 具体的意思,我就不说了. 我就说说怎么收集吧, 从这六个方面分析,得出自己想要在每个方面达到的目的,或者自己希望有一个什么样的设想, 把这所有的想法都写下来. 二.筛选 对自

近期开发工作的一点心得体会

近期,本人加班加点地完成了多个软件版本的开发工作.总结起来,有以下心得体会: 第一,软件的第一个程序版本非常的重要,它直接决定了产品的好坏.就像大楼的地基一样,软件后续版本的需求都是在第一个版本的基础上完成的,如果"地基"没有打牢,后面对程序的增删改都会很困难,让人感到似乎掉进了一个"无底洞"里面. 第二,软件的详细设计文档非常重要,千万不要将之放在无足轻重的位置.要想对程序的基本功能有一个大致的.快速的了解,最普遍的做法就是查看它的详细设计文档.如果这个文档写好了

读《构建之法》的心得体会

读<构建之法>的心得体会 软件工程涉及的范围很广,对于即将投身IT业的学生而言,软件工程的内容又非常重要.读构建之法,尽管本书介绍了不少IT业正在使用的理论和技术,但是,这本书的主要思想并不是介绍所有的新思想和新技术,而是从这些新思想.新技术中总结出对自己在未来的工作中有用的东西. 在整本书中,印象最让我深刻的是“两个人的合作”这一章节.现代的软件产业经过几十年的发展,软件的结构随着用户需求的不断增加,软件的功能不断朝多元化与复杂化发展.不管是两个人的合作还是团队的合作,谈到合作不免提及规范这

Git的基本使用方法和安装&amp;心得体会

1. git的安装和github的注册.代码托管.创建organization.邀请member. (1)git的安装 因为我电脑是windows系统,所以下载的是git for windows.在官网下载非常卡,直接百度搜找百度那个下载就可以.下载后选择路径一直next就行了. (2)github的注册 没什么说的,虽然界面是英文,不过要是连这种程度的都看不懂你还是洗洗睡吧.按要求填完邮箱账号密码等常规东西就注册完了. (3)创建organization the organization's

阅读文章心得体会

阅读文章心得体会                         阅读了几篇文章,感觉大泥鳅这篇文章和我们的团队项目特别贴近,感觉有很多感想想要分享一下, 我想专门就大泥球这篇文章和我们团队项目的改进过程谈谈自己的感悟. 首先文章中说到的大泥球,其引申义在文中是指一个架构随意的.没有明显约束条件的系统,这样的 系统是因为在完成阶段由于各种原因成长失控而导致的结果,为了维护突然出现的各种问题,不断选用权 宜之计在系统整体上进行维修,打上一个接一个的补丁导致整体的无序性,重要的信息在系统的元素之间

工程训练大赛心得体会

从开学的筹备到期末时的比赛,工程训练大赛真的用了一学期的时间在其中付出了很多收获也很多,熬过通宵体验过什么叫做心急如焚,比赛前几个小时尝试过从新做小车,有时候真的不知道自己的潜力到底有多大,以前需要几天甚至几个星期才能做出来的车,在大家齐心协力的合作下几个小时就被做出来了,我想最令人难忘的就是在赛前把车子摔坏了,然后大家齐心协力一起重新做一辆车,并且在比赛前完成所有的调试工作. 大家都说团队合作很重要,刚开始我也不知道要怎么团队合作,走过不少弯路,知道比赛将近的时候我们小组完全凝聚起来了,小组之

薛大龙博士-信息系统项目管理师培训班学习心得体会

首先,非常庆幸本人通过了2016年上半年信息系统项目管理师考试,自己的辛苦付出没有白费. 本人在IT公司工作近10年,主要负责团队管理.项目管理等工作,2016年决定报考信息系统项目管理师,由于平时工作非常忙,考试也有一定的难度,为了保证能够顺利通过考试,我有幸找到了51CTO学院,更有幸结识了薛老师,参加了薛老师的软考培训班,现在把自己的一些心得体会分享给大家,仅供参考. 1.信息系统项目管理师考试有一定的难度,并且答题也需要有套路,如果单靠自己学习教材,通过考试还是有难度,因为我们学习的时间

构建之法—心得体会

构建之法——现代软件工程 ——心得体会 对于软件相关专业的我们来说,学习了很多的专业课程,像算法,数据结构,编译原理,软件工程等.很多学生都会有这样的疑问:我学了这么多的课程有什么用呢?在工作中有多少会真正被应用到呢?也就是说,大家都觉得理论和实践之间有着不可逾越的鸿沟.邹欣老师的<构建之法:现代软件工程>一书很好地,并且巧妙的将理论和实践结合了起来. 软件工程牵涉的范围广泛,对于即将投身IT行业的学生而言,软件工程的内容又非常重要.但是,大学生们普遍反映软件工程的课程比较空洞,乏味.一个很重