到一个小时前为止，小湖和小鲁第一个真正意义上的通讯项目初步完工。这是一个寒假努力的结果，巴特，我要说的是，结果往往不是最重要的。
要说通过这个在技术上学到了什么，可以说学到了很多，因为，可以说是第一次写文档，第一次订协议，第一次写出了上万行代码。也可以说很少。整个项目里真正的新东西，就只有一个java.io.Socket /java.io.ServerSocket， 其他的都是以前或零或整的知识点。
诚然，将这些东西整合到一起，使之真正有一个好的结果，确实是对我们能力的锻炼，但是，我觉得在这其中最重要的却与技术无关，那就是团队合作。
团队合作可以说是一个泛滥的词汇，几乎像喊口号一样被传唱到每一个角落，每一个本书里，无论做什么，哪怕天下无贼里面的小贼们都讲究合作。究竟什么是合作呢，我们为什么要合作呢，我们真正的做到了合作没有呢？
从广义上来说，合作就是合而作之。即将一切可利用的资源整合起来，通过有效地机制运作，得到效益最大的结果。
那么总结起来合作的三个制胜点是：
第一、领导者。
好的领导者需要审时度势。他需要知道的是“什么时候做什么是对的”，而不是“怎样去做这件事”。
“民主”与“专制”需要贯穿整个项目开发的过程中。真正的民主导致的必是一盘散沙，显而易见的例子是官僚主义的开会，低下的效率让他们一个月甚至连一件事都无法解决。
在集思广益阶段民主是被需要的，这才能显示出合作的精髓，1+1>2。此时领导者是完全放手不管么？显然不是，他需要知道讨论到什么时候就“够了”，他需要在适当的时候做一个专制的君主说“给我停下来！”。
然后呢，他需要专制起来，经过分析考虑然后分配任务，他需要说“你来做这个，你需要做到XXX”，而不是他的组员来说“让我做这个吧。”“我不要做那个。”
有一个经常可以遇见的情况是，到了开发的后期，大部分代码已经完成，或者进入初步调试阶段，或许是某个天才的组员有了一个创造性的idea，领导者需要做什么？说“ＮＯ”然后将之记录下来，成为下个一版本的“特色新性能”。显而易见的，文档记录是一个领导者的角色生涯的呼吸器。无尽的补充修改导致的是一个过于宽大而无法扎紧的口袋，你甚至找不到一个可以用来扎紧的绳。只要人类进步的脚步没有停止，就永远没有尽善尽美的程序，万事有度才能成事。
第二、机制。
每一个领导者都需要根据时间，金钱，人手制定一个机制。资源少时间紧，就需要讲究合理的妥协。时间金钱多，那么就需要更精致的作品。则管理机制，人员配比就不一样。然后才是根据机制写出更为详细的计划表。真正有效的机制是，对事不对人，即使临时更换了队长也能正常运作。
第三、团队推进者。
有了管理者和机制就好了吗，成员们会乖乖听话去做么，不会，起码傻乎乎听着指令做事的他的类里面一定有一行代码
Private duck duck；
渔民喜欢在活鱼里放一条鳗鱼或者别的什么捕食者，它好动活泼，充满着野心，原本傻乎乎的鱼儿们产生了一种危机感，一个个蹦跶着，生怕停下来被吃掉。
我们的团队也需要一个这样的角色，或者说领导者需要引导某个人成为这样的角色，其他人害怕被他“吃掉”，于是最大化的发挥出自己智慧与力量。当然领导者并不一定是或不是这个团队推进者，但他一定要知道谁有能力成为这个人。
写到这里，我想我已经明白了团队与团伙的区别了。毕竟谁都知道程序中队列是有序的，并且是可管理的不是么？