【团队冲刺总结】一个编码人员的反(tu)思(cao)

2022-10-04 15:50:14

　　消失了半个多月了啊，算算时间，好像确实有近个把月没有好好的写博客来了。我一直很想写博客的，之前有老师问过写博客的动力是什么。我想了想，我觉得可能是我比较喜欢看书吧，不管是专业书还是小说（好吧，我承认，对自己感兴趣的书才会去收藏，阅读），看多了总有股想自己写写的冲动。然而，并没有足够的能力和文笔写出来。后来发现有博客这种要求并不是很严的东东，也就喜欢上了。

　　之前这段时间实在太忙了，好多并行任务挤到一个点上去了，也就忽略了博客了。好在，这段时间终于扛过去了，团队冲刺的这段时间喜怒哀乐也经历了很多：学习，敲代码，找BUG，修BUG，和队友讨论，甚至还因为某些观点不合和PM西瓜吵了几次，总之，这段时间感触多多，收获多多。接下去的时间内应该可以挤出时间来写博客了，把这段时间的感触，收获写写。

　　这篇就写写这次团队冲刺的一些感悟吧。　　

1.站立式会议

　　这点还是有些东西可以写的，本来我们团队把每日站立式会议理解错了，我们一开始是认为这次开会把任务发布下去，等稍微有些成果的时候再来开会总结，并继续发布下次任务。因此，一开始我们是两到三天开一次会，因为团队成员可以说都是新手，前期用来学习的时间教多，能做出成果出来的较少。

　　后来才发现理解错了每日会议的意义，每日站立式会议不仅仅只是汇报自己已完成的任务和接下去要做的事，以及自己碰到的困难。我觉得会议的重点再于让团队里各个成员都能清楚的知道团队项目目前的进展；团队各个成员进展；我是否需要先停下自己的任务，先去帮助队友等等。而且，会议还是个讨论项目的好机会，毕竟平时有问题基本都是QQ联系，文字描述不好说清各种问题。

　　当然，更重要的就是要让PM随时掌控项目的进展，我这次做的只是个编程人员，PM西瓜每次开会前都会先整理一堆内容，辛苦了！

　　记得最深的一次站立式会议是说完会议主题之后的讨论，那次的讨论是关于数据处理的某个逻辑。之前有在每日冲刺博客上说过，附上链接：【Alpha】Daily Scrum Meeting第三次。还好PM西瓜即使终止了争论，过后西瓜又对争论点详细分析了下，这个问题也算是解决得不错了。

2.Github工作方式

　　这点太有话写了。毕竟还因为Github的工作方式跟西瓜大吵了一顿，不，是讨论，讨论！因为之前有过一次Git工具使用的作业，在那次作业多花了点时间琢磨，自认为已经算是掌握得差不多了（ㄒoㄒ我错了）。

　　这事是这样的，团队项目就放在一个总仓库里，我一开始的想法是，团队成员都需要有直接push的权限。你说代码是需要复审的，直接push不行。那好，我们建两个分支，我们只push到dev上，dev到master上的合并由你来，这样算是复审了吧。你说这样要是不注意push错会出问题的。这个简单，不是有版本回退嘛（其实版本回退也不是那么好用的，血与泪的教训）。你说github正确的团队方式是需要通过pull request的。什么，pull request,那个不是给团队外的人想做贡献用的吗，如果是你说的那样，那还要Team这个干嘛，而且每次同步最新版都得clone不是特别麻烦嘛。（原谅我年轻不懂事，乱说话）······

　　跟西瓜的那些对话，现在都还记得特别清。当时，西瓜算是被我说服了吧。不，应该说我一直不同意西瓜的方式，西瓜只能暂时先采用我说的方式试试看。试看。看。。结果直接出大问题了！！！

　　当时项目刚起步，很多没考虑清楚的，比如到底哪些文件不需要加入仓库的，而且也没跟队员强调一定得Push到dev分支。结果，有一次，因为队员的编码不小心修改过了一些别人的代码，而且是重要的代码，然后还直接push到了master分支上面，加上事先项目没设置好忽略文件，把工作空间也加入了仓库，结果直接导致了程序的崩溃，根本连编译都过不了，更不用说运行了。

　　经历了这次大问题后，西瓜特意花了时间去查找和总结了Github的团队工作方式，并花时间教会了我们怎么操作。这里也得感谢下刘乾（@SivilTaram）同学，他也给我们讲解了一些。这次算是一次大大的教训吧，不要太高估了自己，也不要总觉得自己的才是对的，尝试去试下别人的说法，或许能更好的解决问题。还有，网上的资料并不是全对的，要懂得自己辨别！（那个谁，是谁写的pull request是专门给团队外的人使用的，我信了！我居然信了！！我还坚定不移的信了！！！）

　　最后，附上西瓜大大的团队github教程,特别详细的哦。GitHub团队项目合作流程

3.编码规范

　　从第一次学习的C语言时，老师就有强调说良好编码风格的重要性了。如果只是自己写的程序，或许还体验不到，顶多是忘记了某些变量，某些方法的含义，但花点时间还是能想起来的，毕竟那是自己曾经敲过的。但，如果是团队合作开发的项目。我只能说，那个谁，对，就是你，带眼镜的那个，你要是再敢试试用a来命名，我就。我就。。我就用a1来命名，没错，就用a1。看你还敢不敢。

　　这次我们团队的编码规范我觉得做得很不错，当然最大的功劳应该是西瓜，编码规范的文档是由西瓜整理出来的。然后我们团队特意花了一晚上的时间来讨论编码规范文档的内容，规定了各种命名方式，注释方式等等。

　　前期时，我是负责前端界面的编写，因此我对各种控件的命名打的交道是最多的。刚开始编码时还没习惯过来，也还是随便命名，后来发现，需要命名的控件太多了，有重复了，怎么办啊！！这时才意识到原来编码规范文档不是一份用来交作业的文档，是用来参考使用的。于是，开始按照着文档里的各种规定来给控件命名。一开始经常有些规定忘记了，需要不断的打开文档查看，觉得有些麻烦。后来又意识到不是可以 Crtl + F 的嘛，这下查找也快多了。用着用着，时间久了就大概成了一种习惯了。

　　到了后期，我是直接把编码规范文档的链接放在桌面（编码规范文档放在github上排版更酷，更方面阅读），如果是熟悉的规定，直接敲了。如果不确定，都习惯性的点击链接，打开文档，Crtl+F。我觉得编码规范对我最大的帮助就是我命名的时候不再是随便来了，以前我也很讨厌一个命名要打那么长的字符，但现在，你单单给个tvName我都想削了你，这是tv什么Name,你好歹给详细一点。

　　好吧，我还是得承认，虽然编码规范的命名部分我学到了很多，但风格方面还是有自己的习惯，老是忘记要按照文档来。比如文档说注释方法的注释最好用/** */，但我实在不习惯，好多次还是直接使用//。但空行方面我做得还是不错的，团队里的那个谁，对，就是你，再敢时不时的空个四五行出来，我就。我就。。我就。。。恭喜你猜到我要说什么了，没错，我就空个八九行出来，看你还敢不敢。

　　最后，附上西瓜大大整理的编码规范文档，值得参考哦。编码规范

4.框架使用

　　其实，框架用得好的话，可以省下不少功夫。但也不可以太过依赖框架。助教（@沉默的代码）说过，如果离了框架就干不了事的在HR面前会大大减分哦。

　　这次的团队项目引用了很多框架，打开build文件你会发现，dependencies那边居然满满十来行代码，如果你打算clone我们的项目试着跑起来的话，建议你先退出，重新进，然后去洗个澡，吃个苹果，运气好的话没准就已经编译完成。

　　其实，我一直不清楚，为什么我clone Github上面的项目到本地跑时，总是会一直卡在下载依赖包那边，老半天都过不去。这次团队项目也出现过这种情况，队友引入了一个依赖包，我同步最新版，结果下载了二十几分钟，就是一直在下载，编译过不了。后面退出，重新打开就自己好了，不知道为什么。以后有时间得好好研究下这个问题，Github上面的好东西可不少，要是都没办法跑起来的话，那损失也太多了。如果你知道怎么搞定，麻烦赶快告诉，我已经漏掉好几个Github的干货了。

　　好了，接下去开始写写团队项目引入框架的坑。我觉得我就是助教说的那个离了框架就干不了事的人，怎么办！！！我是负责前端界面的，到目前为止还没写过自定义控件（囧），都是引用的别人的框架。像什么侧滑菜单啊，进度条啊，圆形图片啊，弹窗啊，之类的。我都是在逛Github上面时，发现有好东西，就fork到自己那里，能用上更好了。其实，我也是算是个刚入门的安卓新手，很多自定义概念并不是很清楚它的原理，而且这次项目时间少，为了能在短时间内就能有成果出来，只能不断网上查找别人写好的框架拿来使用。但这有很大一个问题。

　　因为时间少，所以不断的使用框架，同样因为时间少，来不及深入了解框架，导致了我引入了很多可以说是有重复的框架。比如这个框架已经提供了弹出，按钮等，但我还需要一个进度条，所以又引入了一个框架，结果新引入的框架不仅提供了进度条，还提供了弹出，按钮等。所以，我已经想好了，等继续学习安卓，能力够了后一定要把这个团队项目的界面再重新搞一遍，把不需要的删掉，深入去学习框架，而不是像这次这样为了能实现一个功能就引入一个框架。

　　最后，来个吐槽吧，引入了个afinal框架，结果发现不知道是自己对它了解不深，还是它提供的功能有限，好多思路用它都无法实现，最后气得都想不睡觉了！！！附上队友使用这个框架的体会。【Alpha】Daily Scrum Meeting第七次

5.代码冲突

　　代码冲突这块算是家常便饭了，我就不信有哪个团队合作开发没碰到过代码冲突的。（什么，有？！我听不见，别跟我说）

　　合作开发中，就算分工得再模块化，总还是会有那么些地方是相关联的，也就是谁都会修改到的代码块。万一，不幸的你们同时修改了，github又不能自动合并，冲突就来了。跟冲突打的交道多了，其实也就没那么可怕了（当然，我说的是小冲突，大冲突别来找我，我也想躲这它，至从遇见过那么一次后我就怕了）。冲突有是有分类的，有的只是位置冲突，比如你把某个方法块放到最后去了，但内容没改。这点比较好解决。还有的就是对同一个地方进行了修改，这个就需要手工去判断该删掉哪个，该报存哪个，或者都保存。

　　其实，解决代码冲突可以借助AS来，AS提供了人性化的界面操作，很方便解决冲突的。这段时间跟AS打的交道多了，突然发现其实AS提供了很多很实用的工具哦，后面看看有时间没，单独整理份博客出来，欢迎关注期待哦。

　　解决冲突这边，git提供的版本管理其实也很有帮助，如果解决冲突到后面程序崩溃了，想退回版本可以用git，如果commit的记录有很多无用信息，又不想push到github上面去，也就是不想要那个commit记录，但回退版本的话代码又会没了，其实这些都可以解决，git就提供了多种回退方式，里面就有只撤销commit记录，代码保持最新的的方式等等。所以说，那么火的工具自然有它火的理由，不要只是接触过它就自认为自己已经掌握了，还有很多高级的用法等着去学。（不是在说我，不是在说我，不是在说我，三遍！！）

6.代码质量

　　代码质量这块，哎，我都有点不好意思写下去了。记得助教（@沉默的代码）说过，初学时，为了能实现功能，怎么乱怎么来。怎么感觉还是在说我！！！怎么办！！！

　　由于毕竟是刚接触的安卓，看完大概的书完后就要用来写出这么一个不像是Demo的项目出来了，压力确实很大。代码里面问题最大的就是重复量太多了！！还有就是相互之间的关联太深了，用专业术语来说就是，耦合度太高了。什么意思，举个简单的例子，登陆用户的身份有三种可以选择，不同的身份对应登陆后的界面有所改变。实现时并没有把身份单独抽出来写成静态常量，而是直接在代码需要的地方用""写上去，比如"user_teacher"，这会导致一个什么情况，当我觉得这个命名不好，需要再修改下时，必须到所有有用到这个变量的地方手工修改一遍。

　　至于代码重复量问题，很多都是直接复制粘贴的。这个界面有这个功能，这个控件，刚好另一个界面也都有，好，怎么实现，代码直接复制粘贴过去，参数以及id修改下搞定。结果，项目里面很多地方全是重复的代码，原谅我实在不会实现什么资源复用之类的。虽然自己在看代码时，也有些不好意思了，但心里也渐渐有些想法了，想着以后如果要重构代码时，哪些必须不能再重复，哎，要学的还是有很多的！

6.团队冲刺总结反思

　　总的来说，这次的团队冲刺收获还是有的，虽然成果并没有预期的那么好（理想总是美好的）。

　　栋哥说过，编码前的文档准备是为了编码的方便，想想开发过程中，我有真的好好的去参照那些事前准备好的文档吗？编码规范文档应该符合要求了，毕竟时不时的查看；原型应该也有符合要求了，设计界面时都是参照着当初设计好的原型来做的，然后在基础上稍作修改。哦，对，还有需求规格说明书文档！我去，怎么就把这个重要的文档给忘了！！栋哥不是说功能的实现要按照验收验证标准来的吗，不要自认为某个简单的控件简单的功能不需要就不写上去，要按照验收验证标准上的来！

　　这点确实是个不足的地方，想想当初为什么没有按照需求规格说明书文档来。我一开始是花了一周多的时间完成界面，然后开始参与业务逻辑的编写，这个时候时间已经不多了，而且每天西瓜也都布置了具体的任务，具体到要实现哪部分的内容，虽然我并没有参照着文档来，或许西瓜就是参照着文档来给我们分配的任务呢？当初确实有这样的想法，所以才没有去打开文档。

　　还有另一个想法就是，验收验证标准自己也有参与书写，因此编码过程中总是自认为自己清楚的知道需要实现哪些，不需要再去翻看文档。（怎么感觉我的自认为毛病很严重！！）还有最后一个想法就是，当初书写验收验证标准的时候，不管是对系统的理解，还是知识上，经验上都有所欠缺，然后实际编码实现时才发现，有些功能并不需要实现，有些控件去掉的话界面会更好看。因此觉得文档里的验收验证标准有很多并不成熟的要求，所以才不去参照着这个文档来。

　　好了，先这些吧。等会还有课，最后附上我们项目的github地址，欢迎fork,不过代码质量确实是有点不怎么好，还望您在吐槽的时候勿忘指教，Thanks!!! 　CourseManagement