既然是心得，风格会比较随意，想到哪里写到哪里……
我们的团队项目，个人认为算是略微有点曲折的。一开始选了一个大得夸张的题目，然后还和别的小组冲突了，然后换了题目，虽然新题目是我提出的，但是其实我对这个题目感到很虚，在我看来做一个这么感性的题目总归不是一个很稳、很容易出成果的选择。不过已经不可能第三次换题目了，那就这样吧。
后续才进入正式开发，开发过程我个人感觉是比较良好的（恐怕很快就要被啥都写不出来的现实打脸）。个人觉得我们组的每个人都是非常认真负责的优秀的同学，而且大家也都比较熟悉，所以平时也经常水群什么的（可能因为我是个水群狂魔吧），比较活跃。虽然我不能说我们写出来的成果有多么优秀，但能够和这些优秀又负责的同学一起工作一个学期对我来说是很可贵的体验。
心得的话，先说一下人事以及合作方面。
呃我是我们组的组长……但是我也不知道我为什么会变成组长……反正无辜背锅，本来并没有那么想当组长，也不认为自己特别适合当组长。毕竟大家都是同学，谁也不比谁优秀多少，不可能真的把自己摆在一个“更高”的位置上，无非是做做协调工作而已，也没有真的特别逼大家出工作量。按照老师的标准的话，我这个风格在公司里肯定是要死的（笑）。不过其实感觉大部分组都是这样的吧……之前看到有个组（忘记哪个了）组长能力特别强，但是我们组其实大家都差不多。个人感觉现在的情况大家合作非常融洽，也都很勤奋，所以也没必要去刻意怎么样吧。
合作方面，其实个人有一些要反省的地方。我属于个人风格比较强、想法比较多的人（虽然想法很多都是错的23333333），而且也很容易对自己的想法比较固执，情绪也比较容易激动。又因为我组长的身份（虽然其实一起写代码的时候并不觉得自己需要组长这个身份，但毕竟还是多少会有影响），所以感觉我很容易把自己的想法push到他人身上去。其实并不是很想这样push，但是当自己真的认为自己是对的（虽然实际上不是）而且真的想表达自己的想法的时候，并没有那么容易听取那人的意见。当然如果后续的讨论证明我的想法是有漏洞的，我当然会放弃，但往往漏洞不会很快被发现，反而是过了很久才冒出来一个坑把我们埋了进去……而且我这种作风有时候会导致我的队友不太明白整个代码到底在干嘛。我经常觉得，假如一开始我不要那么push自己的想法的话，也许很多问题可以避免。
我们是三个人在写数据库 + 服务器（现在越来越觉得这个分工神奇而不合理……），之前就出现过一个很大的设计上的坑，现在也没有完全填干净。当时因为太忙了（我大概要从五月一直忙到七月了……），情绪比较激动，加上代码问题比较大，所以当时合作也不太融洽。当然对后续没有太大影响，主要是因为后来没那么忙了心情就好了（逃），但是这些个人风格问题我还是需要反省的 。
emmmm然后是规范方面。
其实我一开始有想过要不要规范化开发的，但是当时觉得（其实现在也这么觉得）我们的项目本来自由度就很高，所以规范化可能性不大。
就算是现在我们的项目也不是特别规范，每日汇报就是每日水群（当然这个我们做的很好）；周计划肯定是可以规划出来的，但是更长远的计划我真的觉得不可能计划出来。
首先我们根本不可能知道后续的开发要侧重哪个方面，我们必须要做出alpha版本之后去跟用户沟通才能知道。包括设计文档也是同理，我们只能写出现在已经开发了的，和已经确定要开发的基础功能的设计文档，后续的根本没法写，说不定写了半天最后被用户嫌弃了。
其次对于开发中需要的大部分技术我们都只停留在听说过的阶段，根本不知道难度如何。我们不可能所有人把所有知识都查清楚了再开始写代码，谁知道自己要写哪一块、做什么内容呢，等所有知识学透了一个学期也过完了，最后半成品都做不出来一个。这个问题其实在周规划中同样存在，我们不可能花整整一周只是去调研技术，如果我们用前半周调研技术，那么在前半周的调研出来之前是不可能对后半周有一个明确的规划的。
另外老师经常引入的一些神奇的名词我是真的不知道是什么意思……燃尽图我真的是在昨天才知道是啥……为什么人类不能用一些简单的语言表达
当然一定程度的规范度肯定是需要的，我们现在也已经做了一些了。
规范方面个人觉得比较重要的是一些实操规范。
比如说，as gradle这些工具的版本问题。这个我一开始也想到了要统一版本，但是我当时以为这是一件非常简单的事情，结果实际上是个大坑。（重一点的IDE都是坑，我已经明白了。）而且一开始并不想对大家提太多要求，所以没提这个事情，现在就要处理了。不过这个问题其实并没有额外消耗工作量，也不会为此额外改代码，只是现在觉得这种问题一开始处理了会比较好。
再比如说，测试问题。一开始我一方面是相信大家有测试意识，另一方面不好意思强迫大家一定要写测试，而且我也确实不知道ui有啥好测试的，所以没有要求大家写测试，只是自己在默默给自己的代码写测试，导致自己编码速度其实比较慢。之后跟数据库的另外两位同学一起工作的时候，出于美感半逼着大家写了测试，但是并没有强行要求UI写测试。上周我们还是决定UI要写测试了，现在再写测试套件有点晚也会有点麻烦，但毕竟还没有晚到来不及。
还有一个似乎不知道怎么分类的心得，就是我们离用户确实太远了。主要还是自己脸皮薄，不太好意思去找人推销自己的app吧。
最后，最重要的，编码方面。
个人觉得学到的最重要的事情就是一定要提前查清楚资料！！！最好先去看几个开源库。我们写的东西怕不是都是人家写剩下的渣渣，能够看别人写的东西的时候一定不能自己写一堆乱七八糟的东西出来。
之前提到了数据库组有一个很大的问题，其实就是设计问题，到最后我们吵了一架我心里感觉不对，跑去看了一下午别人写的开源代码，才终于明白我们设计错误在了哪里。假如我们能够从一开始就查清楚资料，就去看别人写的代码，那是多好。可惜的是我们总是只看一点点资料，然后想当然地开始写，最后写出来的东西真的是辣鸡。
第二件很重要的事情就是，写代码的时候一定要先设计好。
我们当时一开始的设计是不清晰的……是一边写，一边想这个方法放在那里，那个方法放在哪里。这真是一种低效而愚蠢的做法。最后我们拿了张纸出来，一个类一个类，把他们的方法都列了出来，并且写在了wiki上。但这个时候已经太晚了。
我以前从来没有写过大项目，包括个人作业、结对编程也是自己瞎jb开始写，因为框架很小、脑子一想就能够想清楚，所以不需要很多设计。但是现在明白，设计完全不是多余。
同样地，事先也应该规定接口。
这个对我们数据库比较重要，因为我们数据库要给UI提供接口的。（一想到我们那个接口的奇异程度，再想想我自己写同步数据还要用自己的接口，就觉得我好像挖坑把自己埋了……）一个比较好的方式是从一开始就把接口规定好，后面自己爱怎么实现怎么实现。（其实这个经验在结对编程里应该已经吸收到了，但……实操的时候……呵呵呵呵呵）但是我们实际的做法却是自己先随便写，最后再把接口归纳出来。我们之所以这么做是因为一开始什么都不懂、摸着石头过河，不知道自己能写出什么东西出来，不敢规定。现在想来，也许在有了一定的了解之后就应该开始规定接口了。