随着ITOO高校云平台3.1项目的结束，我们各种各样的总结也被提上了日程。
Java版本号的全部开发者和Donet版本号的全部开发者坐在一起进行了关于项目开发管理的头脑风暴，尽管我仅仅是Donet开发组的一个子系统——考评系统的模块开发者。可是对于项目开发管理也有自己的一些思考和看法。
众所周知。作为一个Teamleader，是要考虑非常多非常多事情的，怎样调动团队成员的积极性，怎样统筹安排团队成员分工合作，使工作效率达到最佳，怎样依据开发者的技术水平、经验以及个人性格等诸多因素为他们分配任务。以使整体的项目开发效率达到最优等等。都是我们要去认真思考。从而给出可行的解决方式。
可是，我今天要谈的不是这些，而是我作为一个开发者在做项目的过程中所遇到的种种问题和切身体会去考虑怎样做一个更好的Team leader。
首先第一个问题是：怎样让新人高速的上手项目，顺利的进行开发工作？
这是一个我个人体会比較深的问题。由于我就是所谓的新人。
在项目的初期。须要我们去了解项目开发所使用的系统框架，还有更为重要的是待开发系统的业务需求，这个是我觉得比較难搞的。你可能会觉得奇怪。不懂需求，看2.0的需求文档啊。
这又牵扯出还有一个管理上的问题。那就是项目文档管理问题。说实话比較乱，因此非常多人都选择不看文档，直接看原型图然后咨询2.0版本号的开发者业务逻辑。再加上自己的琢磨，一点一点的去理解和实现。
假设我们的需求文档和各种开发文档写的比較规范。整理的条理清晰，那么我们的开发者就能够按部就班的去做自己的那块的开发。
其次，在开发过程中，我遇到了非常多的问题，这些问题让我对开发管理进行了思考。怎样才干让水平參差不齐的一线开发者高效率的进行代码开发？首先我们要明白一个观点：真正的项目开发目的不是学习，而是产品。我们没有那么多的时间去研究我们的项目中使用了哪些技术，为什么用反射？WCF的优点是什么等等。
假设你心存疑惑。去找资料进行了解和学习。那么我们的项目工期肯定要被耽误。
因此我的想法是，将项目开发所用的各种工具，比方VS，DBMS以及各种工具类软件和插件等都放在一起，并附上一份开发环境搭建手冊。然后将项目所使用的框架纯净版做好，并将在开发中所要用到的各种类库版本号统一，也随框架放在一起，并附上一份系统框架使用说明，把这些东西放在一起，共享给全部开发者，这样一来。我们可以非常顺利的開始做开发，并且可以规避在项目中引用不同版本号类库造成的错误，比方我在项目开发中不小心把EF版本号更新到了6.0，导致我的服务端代码彻底混乱，最后不得不将SVN上的解决方式删除又一次上传备份。
还有一个比較让人头痛的问题是——代码调试，这个我个人觉得是我们开发过程中最耗时的事情。因为每一个人的水平不一样，遇到bug到解决bug的时间也不同，这样会造成一种现象，那就是调试高手会不停的在各个位置上轮转。给这个调完了又被那个叫去了。如此一来。光忙着到处调试了。自己的开发也会被耽搁。对于开发过程中遇到的各种Bug。我的想法是建立Bug和解决的方法映射管理机制，就是我们把错误管理起来，当我们的开发者遇到自己无法搞定的bug时，先去bug库中寻找是否有相应的解决的方法。若没有则请人帮忙调试，解决之后将错误原因和相应的解决的方法写入Bug库。这样我们的错误管理库会越来越完好，到开发的后期，差点儿就没有什么问题可以让我们耗上半天甚至一两天的时间去攻克了。
同一时候，我们也能够组建所谓的“平台组”，由各种技术人员组成，比方框架的设计者，UI设计和调试高手，以及各种技术的研究者。比方熟悉WCF、EF、WF等各种技术的人员还有Jenkins集成的高手等等，由他们组成机动组。负责全部开发者在开发过程中遇到的各种问题。这样集思广益式的解决方式比較适合我们如今的情况。由于我们不是分层开发的，是依照业务逻辑线进行开发的。
当然我们也能够尝试一下分层开发模式。
可能我写的有些太细节化了，并没有在网上看到的非常多文章那样，说一些高大上的什么原则啦，规范啦等等，这是我作为一个一线开发者，从我自身看到的问题和现象去思考怎样做一个牛逼的Team leader。当然要真正的做一个牛逼的Team leader，还须要非常多非常多的东西去总结去学习。先讲到这里。未完待续……
