关于团队方向选择，以及学习目标。团队人员技能评估。
看着标题感觉的要说明的范围很大，其实归到具体的项目上，排除外部一些限制。能说的就很少了
下午团队内部进行沟通，关于接下来的两个项目的任务分配，看着白板上一条条需求，一条条似曾相识的需求。哎，几年前就已经写过类似代码，为毛几年后还是这些需求，需求没话说。可是代码呢？
面壁中.....
为毛代码没有备份？为毛没有进行总结。回到头，还得一点点撸代码。
提出第一关于团队建设问题？
团队进步的过程中，需要进行必要的代码积累，否则，重复撸着几年前撸的代码，心情一定好不到哪里。把工作放在创造东西上面，而不是重复之前重复的代码。
第二个团队方向问题。
团队的几个人，每天除了撸代码，肯定有喜欢吃螃蟹的战士，学习新知识，关键是学了就学了，连一点痕迹也没有到，要都是这样，只学习不进行必要的分享。团队何来进步，难道就靠着，几年前的代码过活。靠着listview 走天涯。
第三个问题、
团队人员内部是否有竞争，如何避免不好的竞争？
竞争是必要的，弱肉强食，物竞天择。不变的规律，如果没有竞争，就会有惰性。那我理解的不好竞争，团队内部有小帮派，站队现象。不正常的技术交流，关于你的实现方式，我不赞同，不赞同也说不出来个所以然。反正就是不赞同。其他队员只要做的不符合自己的想法，就心里不爽。搞得团队分崩离析。如何避免站队，避免恶意打压竞争，leader 起到一个好的开端，制定一些团队内部目标。指定相关人员进行任务推进，没有闲工夫吵嘴，都在进步，就会弱化竞争关系
目标转移法，来处理。发现有不好的苗头立马进行沟通解决，不拖延。
这一点，看团队leader的管理能力。
团队方向选择
方向，向着开源，全员进步，多交流，沟通。团队积累。
基础架构封装
框架搭建，不同的思想，会产不同的编程方案。在一个框架基础上进行封装至少较为底层的是第三方的内容，扩展性受到限制。
如果是我，我会看除了第三方之外的部分，封装的好坏。而不会去评估三方的东西。
分层，面向接口编程，解耦。程序的可移植性，健壮性。可测性。
下午开会时候的劲头，已经没有了，写不下去了。
