阶段性团队反思
关于随堂小测的反思
其实暴露问题应该是庆幸，问题越早发现越好。
问题1： 代码规范
反思1
注释太少，MVP中途抛弃，时间紧迫都是借口，编码的不规范直接导致耦合度极高，处理本地冲突浪费的时间极多，无意中代码被其他人改动都毫不知情。mainactivity只有景钊写的头注释，还只是类头注释，里面的函数没一个有写注释的。此后这种情况一律返工，每个函数都必须写注释！说明这个函数是在做什么，input和output参数都代表的什么意思。公共模块的每一次修改，必须写上注释，且注释中需注明改动者是谁。而且自己的commit必须干净，没有个诸如“加入头注释”这种commit，也就意味着你开始不写注释就得先回退，加上注释再commit，所以请在一开始就好好写注释。
反思2
每个函数如需要改动，只能由写此函数的人做改动！
比如，A先写了适配器，B在后续写到别的模块时候需要向适配器传参，就直接改动了A写的适配器代码（且没有注释改动原因），后来A发现了冲突又改了回来，于是这个函数被反复修改了数次，在AB沟通后才得到解决。
还有的情况是，调bug调着调着发现虽然bug在自己模块但是由于队友A的模块逻辑出错导致的，但是现在是凌晨两点半队友睡觉了怎么办，不管了咔咔咔把他模块修复了。队友A第二天醒来感觉世界都变了。
并且，所有函数必须向下兼容！某些函数未必只有B模块调用了，若轻易改动其他调用的地方就全崩了。如果后续需要增加传参等其他操作，更好的办法应该是override或新写一个函数，但其实这件事情本不该出现，本应该在设计阶段就得到解决。
反思3
不要用toast或者无意义的log（如Log.d(hahaha,kkk);）来调试！！
重大调整
安卓组每一次的pr，由先由龙江一行行review，他说过关才行。如非特殊情况，编码人员必须服从leader，有意见向我反馈。
服务器端的两位同学互相review。
问题2：分工混乱
开始的分工明明非常清晰，到后面才发现一踏糊涂，甚至出现我不知情的情况下swap了工作，等我问起进度的时候问小胡导出做的怎么样，小胡说给立强写了，问立强怎么样，立强说给昭锡写了，问昭锡怎么样，昭锡说还在写。woc还要我手动遍历一遍链表？
反思：有内部调整必须向我说明。能够让我随时了解进度。
问题3.出bug互相推诿
归结到底还是分工不明确的问题。比如模块A和模块B的交集出了问题，问写A模块的说我模块没问题，写B模块的说B模块没问题。那跳转逻辑是谁写的？不明确。
反思：跳转逻辑统一由发起跳转方实现。并且以后由leader去review，尽量避免前面的功能受后续代码影响，如果还是出事我依然首先去找写该模块的人。出了事不能一句“我代码没问题”、“我运行的时候都好好的”、“不知道怎么回事”推诿。
个人总结
立强：
- 对于今晚修复问题的感受：修复自己的问题花了蛮少的时间，然后就一直测试自己的邮件发送逻辑，最后锁定到了，景钊发送给我的电子邮件地址没有及时更新。因为这部分写的很混乱，所以本该景钊写的跳转逻辑我写了，向intent添加数据的时候给我布置了很多坑（之前一直巨怕这问题，现在啃完之后已经无所畏惧了，收获）。然后我们约定好了公用一个电子邮件列表的List，我就直接写我自己的逻辑了，最终是景钊提供给我的电子邮件没有及时刷新。!!!我觉得如果向这样给人提供数据的，必须在Log中自己全部输出一遍，并且不要注释，不然造成麻烦浪费的时间不是一般的多！
- 对于之前分工合作的，和上面一条一样，必须分工合作，分模块情况下，别人启动自己写的界面，如果有传输数据进来的必须写好相关数据的类型，并测试！！！！！！！！！！！
最好能够多看几遍git教程，虽然经过这么多次的折磨估计基本都会了。
觉得函数的注释超级有必要，之前问个昭锡导出数据库传的参数什么竟然都弄了大半天我没听懂，结果就只要穿个string当目录名，这还是小的，后面导出相册竟然要我自己写，还要我导出权限？被这个弄蒙蔽了，我调用别人函数，我还要帮别人申请一下权限？（申请权限这样的应该列入工具包，刚好最后又交给昭锡写了申请权限，现在昭锡应该很熟了。）接着说函数注释，导出相册传的参数根本看不懂，看不懂到了一个地步，我都没见过的数据类型，变成了我要用的参数？Bitmap，从来没听过，后面知道了。
同学录真的花了太多时间，虽然这个里面的原因是因为android开发的没有做好。而且听说了其他人用web写的时候震惊了，好像网页实现起来巨快，迅速完成，然后就能节省很多时间做软工冲刺，结果。。。。。。弄了这么久。估计明天还要接着弄
景钊：
这次的同学录的编写过程总的来说可以用一波三折来形容。首先是代码规范的事情，在代码规范方面因为之前自学都是盲写，没有系统的按照相应的代码规范，这次在团队编程上面编写代码，就有很多没有按照代码规范来。代码上面的注释信息太少，这些都使得同队的队友在合作编程上面造成了很大的困难。这在接下来的团队编程上面给了我们很大的经验，在自己个人的模块编写上，要有相应的块注释进行注解。其次是在gitkraken上面花费了很大的时间去。因为之前没有团队合作的项目经验，对git的操作和使用没有深入的研究。虽然之前组长有布置过git的操作和使用的教程，但是没有相应的操作去理解，使得看教程也只是停留在表面上。可以说这一次的小练手给了我们很大的帮助，减少了我们接下来的团队合作上在git上面花费的时间。还有就是模块的划分不清晰，这个主要还是大家对mvp架构的了解不够，在编写接口上没有落实到位，导致各个模块的衔接很不清晰，最终还得去查看别人的函数来协商解决bug。最后就是自己在android这方面的知识掌握的不全面，输入的东西不够导致在想输出的时候，找不到相应的方面，或者用效率很低的方面去解决问题。项目经验不够，自我的代码规范没有强调，Android方面的知识还是需要边学边补充。
昭锡：
“有代码的地方就有冲突”，一次软工实践小测试就将这句话体现得淋漓尽致。在整个编码阶段各种冲突，各种漏洞，各种更换他人代码，总之还是代码耦合度过高，合作过程达不到并行的效果，一个人总是在等待另一个人的模块，导致1+1小于2甚至小于1的惨状…但是经过这次小测试，团队合作的一次试水，之后的合作编码应该能成功一点吧……………
小胡：
这个同学录的作业，本来要求是三个小时完成，我们硬是熬了4天才完成。因为选择了android，而这个是我们不熟悉甚至是陌生的东西。所以这四天，不断学习，不断测试，不断找bug，不断修复，不断commit，不断merge，还有恐怖的不断conflict，这些这些，硬生生的把我们3小时应该要完成的作业扩展到4天，而且是很充实的熬了4天。看着别的组早就做完了作业，我们却还在苦苦的探索，不禁想着是不是一开始选错语言了，就应该找一门熟悉的语言来完成呢？当然不！我们的最终boss是需要用android来terminate的，所以对于同学录这种小兵当然要拿来单做试炼石了，不然直接打boss肯定gg。事实证明我们的选择是对的。在这次作业过程中，我们暴露出了很多问题，这些问题是一个团队想很好的合作必须要克服的，包括技术栈不足，彼此之间的磨合等等一系列不可避免却又非常严重的问题。当今晚总结和反思的时候，不禁庆幸我们选择了用android来完成，试想一下如果这些问题在打boss的时候才暴露，那又会怎么样呢？所以，这次的作业其实很大程度的模拟了我们之后要做的项目的过程，如果只把它当成一次作业，那么他就只是一次3个小时的作业，除此之外并没有什么用。但是如果把它当做是我们团队项目的一个小练手，当做是战前的磨合和排兵布阵，那它的意义将远超一份作业。所以，这4天的奋战，值。
