项目组长成长记（一）

话说“不想当将军的士兵不是好士兵”，虽然还没有开始带项目，不过从参加项目（组织部和TIOO）的5个月以来，从我的项目组以及一直在跟的《码农》期刊上学习到了很多带项目的经验，特整理成该系列博客，记录我一步步成长的过程。

---前言

一、自身修炼：

这5个月来写代码的过程也在不断的总结，如何成为更专业更出色的程序员，因为之前两次住院对自己在心理负担、时间上的耽误，让我比别人慢了拍子，但路总得一步步走，下面是自己这几个月来对于自身感触比较深的几点：

1、时间管理

说这一点会感觉老生常谈了，其实越是比别人慢的人才更改做好自己的时间管理，拿做项目来说，我更加喜欢敲代码过程中配合着“番茄土豆”一起工作，番茄钟只要进行，投入的就会更多，毕竟会有一天那么多个番茄给自己带来满满的成就感。而且一个大段时间最好只做一个项目，就像下午2:00~5:30，我会花5个番茄的时间来做ITOO，剩一个番茄来处理其他事情，而不是在一个下午先做两个小时ITOO再做1个小时的组织部项目。大段时间更利于我集中精力去深入思考和分析。

2、任务规划

在为知笔记里写日计划和周计划以及写当月要做的重要的事情，所谓的GTD我后来认为也是建立在有一个良好规划的基础上的，这样让所做的每一件事都有计划和“被打断处理”，这样去工作，每单击一次鼠标都蕴含着思想。

这一点说起来容易做起来不简单，每个人都不一样，4月份我一直在找适合我的一种规划模式，不断的调整，我想不久将来或者下一篇总结里我会做的更好。

3、代码总结

敲代码是一件神圣的事情，就像我现在在写这篇总结时都会热泪盈眶一样，因为我知道这件事情是我走向更好未来的一个踏板，对于代码的思考如下：

（1）写代码之前，先把思路缕清，然后再去敲

这点是在一年前Bill告诉我的，在做组织部项目时候，我会在刚敲一条新线和完成这条线之后优化的过程用油笔写出来我的思路，前者让我更加迅速的熟悉逻辑，后者让我以后再遇到类似套路时只要翻出笔记就可以轻车熟路完成工作。

（2）开源工具的使用，官网、QQ群、论坛一定使用起来

刚开始使用MVC+EF框架时候，一个“easy-ui”的使用就把我打败的不行不行的了，在一次项目验收过程中游哥提出来这个观点之后真的是如获珍宝，API文档里的东西要远比百度中的提问更值得咀嚼，有针对性对比性也强。

就像在看一个EF系列博客过程中，去down了楼主的源码，才发现这个家伙对于Easy-UI巧妙的应用真的是如鱼得水。（链接）如果不去看他的源码，可能对于easy-ui的认识深度还需要再过几个月。

（3）多交流，多请教，多主动帮人调代码

开始时候不爱找人帮忙真的觉得那会的自己太过幼稚了，尤其是在刚接触一个新东西的时候，要知道这个东西在我这个集体里谁是擅长它的，自己研究出问题后去看他的博客，自己解决不了就去请教他，最终的目的要让讲解的人获得成就感，自己获得解决问题的solution。真实terrific.

主动帮助别人调代码也是这样，就像游哥说的，身边做个人自己敲代码的思路都是不一样的，大胆的去做吧，Vincent，加油。

4、树立威信

当然，这一点是作为一个项目组长必须要具备的。就像英语小组时候Bill就很有威信，包括现在我们组织部小马哥也是，大家都很拥戴，为什么？

想别人不去想、不敢想，做别人不去做不敢做，这是我看到的一些观点。敲代码也好，管理小组团队也好，自己都做不好别人谁还服你？多做少抱怨吧，作为组长肯定会受到误会与不满，多做少抱怨，别人的抱怨其实就是在让自己变得更加宽容。

二、代码管理

1、代码备份与提交

关于备份：我的经验每日离开机房之前对于当天所做的项目都进行一次备份，保证代码崩溃或者丢失之后损失能够降到最低。

关于提交：

（1）代码有错不提交；

（2）只写了接口没有实现的也提交。这样别人Update之后，会因为这个错误导致程序跑步起来。

这两点做不好往往会对组里的队员造成耽误，养成每日下班之前提交代码的习惯，这样对于组长有利于通过SVN提交代码的情况对大家进度进行了解。

2、代码检查

不定期进行代码规范检查，当然这样做的前提是项目开始的时候要下发“代码规范文档”，注释怎么写、变量怎么命名、方法体的长度限制、等等，及时发现问题及时纠正问题，避免堆栈现象发生。

3、数据库维护

最好在组内有个人专门负责数据库的变更以及维护，库有问题就找专人解决，避免互相扯皮同时保证进度，而且记录下来的问题对于我们更好的设计新库有很大帮助。

4、关于性能

（1）对于数据库的”I/O”操作，对每一张表最好有一个无条件的查询方法，即整张表的查询，而不是根据一个条件就执行一次”I/O”操作，仅仅查询一张表就对应了N多个各式各样的查询方法，应该是对整张表查出来之后再在这个实体里去筛选。

（2）尽量不在Controller里写大量的业务逻辑，把逻辑沉到B层里，如果一个方法需要集合许多个小方法，去调用吧，不要把他们“撺”成一个巨无霸，小心内存溢出。而且“方法过长坏味道”我们在设计模式时候就知道了。

三、团队管理

1、Daily check

前提组长对于整体进度有宏观把控，每日两次的Check，早晨做计划，晚上验收进度、交流问题，So将计划的粒度做细，更能激发大家的干劲，每日都有收获，每日都有鼓励，而且当天晚上说了自己有这个问题，如果第二天、第三天晚上还没有解决，组长就该重视这个问题了，要么是人的态度问题，要么是问题实在是个坎，可以“攻关”一下。

2、任务计划

关于这一点，建议组员的计划要让组员自己来定，一个有趣的例子“昨天说完成了80%，今天说实实在在完成了80%”后天还是80%……，永远都是80%”，让组员自己做计划，能够更好的避免这个问题，而且组长可以通过参考组员制定的计划以及完成情况估计组员的能力，更好的为他分配新的任务。

4、尽早集成

尽早联调、尽早集成是为了避免灾难性问题的发生，一些早期自己的问题可能没有暴露出来，等到集成之后，假数据、之前认为正确的逻辑都会受到考验，So，及早联调，发现问题及时解决，拒绝“堆栈现象”的发生，到时候代码敲完了再让组员去改大量的错误，搁谁心里都不好不好的。

So,这段时间的一些收获做了宏观的总结发了出来，这是我不断进步的一个重要步骤，慢慢来，一切都来得及，you will be the person you were mean to be.