我们技术团队有两个习惯：一是程序员写好一个新的比较重要的系统，或是引入了一个第三方框架或库后，主程会要求程序员做一个ppt，在会议室里给所有程序与QC做一次团队分享；二是程序员写好一个新系统，或做了比较大的或比较重要的修改后，要知会相关QC，并把QC叫到电脑前，一对一把相关代码给QC讲一遍。
我认为做ppt团队分享可以起到两个重要作用：一是让团队成员之间时常互通有无，避免各人只了解自己手头负责的一小块内容；长期保持这种习惯，可以很好地增进技术团队的凝聚力，也可以帮助技术团队保持敏捷。二是分享用的ppt同时也可作为开发文档，留在版本库中供日后查阅。
不过在会议上给大家讲代码时，经常会遇到一个问题：代码讲太细太深入了，大家就容易听不懂，因为大部分人毕竟没有具体关注过我做的这块业务。听众一旦不懂，就容易走神，精力不是很好的还会犯困，甚至睡着都有可能。所以我觉得，至少对我们团队现阶段来讲，直接在会议上让众人集体做代码审查是不合适的，会比较浪费时间。
那么如何让这种分享真正发挥出它的价值呢？我想关键还是把握住“互通有无”这个目的，把握好度。ppt分享的目的是让大家知道我的业务流程与数据结构长什么样，代码框架如何，其中每个模块的主要职责是什么，有什么重要接口；日后如果某位同事的工作涉及到我这个系统，他在开工前能想起我的系统是相关的，我的分享目的就基本达到了。如果他需要再深入了解我的系统，当他找回我的ppt，能迅速找到这个系统的代码，并且阅读ppt和代码的过程中能想起一点我讲的东西，加快他理解代码的速度，那我的分享目的就完美达成了。ppt分享的目的不是让大家对着我的代码查bug，更不是让大家当小黄鸭（见小黄鸭调试法），因为大家的时间都很宝贵。
因此我打算采用以下思路做ppt分享：
1、首先预估好分享用的时间，一开始就要告诉自己时间有限，要讲重点，不要事无巨细。人的平均连续专注时间据说只有40多分钟，大约是一节课时间。在我们平常紧张的开发节奏之下，大家可能会更容易疲倦，因此时间应该更短点。最好控制在20分钟以内，再不够就半小时，别超了。
只要一开始定好量定好时间，整个ppt分享的调调就基本定下来了，后面做ppt就容易把握重点，讲ppt时也不会一开始就很悠闲，后来就越来越悠闲（让听众想睡），或者反过来发现时间不够用。如果觉得系统太大内容太多，那就将内容再压缩，讲的粒度再粗点。任何系统任何内容都可以有针对性地以任何粒度表述给别人听，这是我读研究生那几年做学术报告的一个重要体会。
2、ppt开头，先告诉大家我做的这块东西是为了解决什么问题，实现什么功能。比如我最近做的随机名字搬到服务端的工作，是为了保证玩家申请到一个随机名字后，一定可以用这个名字创建新角色，而不会出现“名字被占用”的情况。另外，一个新的游戏系统的目的可能最好还从策划的角度做一点阐述（顺便帮助拉近程序与策划之间的距离）。
3、如果系统涉及服务器间、进程间的交互与架构，接下来就给出涉及的服务器架构图，这样就让大家知道我负责的系统在架构中处于哪个位置。比如我做登录的ppt分享，会通过架构图告诉大家，玩家看到的每个游戏服在技术上包含了哪些进程哪些数据库，游戏服和游戏服之间怎么划分，大区和大区之间又如何划分，游戏服和游戏服之间的交互是通过哪个进程。之所以会有这一步是因为我负责的工作经常会涉及框架搭建和进程间交互的事情，比如在老东家负责的集群后台管理与监控、补丁机制；还有现在负责的登录、跨服和gm工具的搭建。大部分系统应该不涉及这一步。
4、接着阐述主要业务流程。这时可以用流程图，也可以用时序图。我倾向用时序图，因为这更便于展现进程与进程之间、类与类之间、模块与模块之间的交互。注意只要阐述主要流程、关键步骤就可以了，不要每个细节每个点都讲出来。流程中的异常处理和保护逻辑统统忽略。如果有比较了解的同事问到异常处理的问题，可以一两句简单介绍一下处理方案，并告诉他ppt最后会专门讲。如果流程时序比较复杂，可以先出一个简化的时序图，然后再出一个更详细的版本。详细版本的时序图不一定要当场讲（视乎同事的掌握程度和兴趣），留在ppt中可供以后查阅。另外，在阐述流程的过程中，顺带介绍每个相关类、模块的职责。重要的协议、接口也在这一步给出。
5、介绍主要数据结构。我现在越来越有一种感觉，就是实际产品开发中，甚少有精妙复杂的算法需要我们操心，但相对而言数据结构却重要得多关键得多。采用什么样的数据结构在很大程度上可以决定你的代码长什么样子、性能如何。对其他同事而言，他们知道了我的系统的数据结构，心里对这个系统也会更有底。尤其我们做游戏的，基本上都是在操纵玩家身上的数据，了解清楚玩家身上带了什么样的数据非常重要。数据结构的描述，能画图就尽量画图；然后用开发语言写出数据结构的示例，比如我们用lua，我可能会这样描述玩家已经学会的职业技能：
job_skills_ =
{
[技能1的ID] = 技能1的等级,
[技能2的ID] = 技能2的等级,
...
}
一目了然。
6、如果系统涉及数据库存储，则阐述数据库表结构，并从数据库中查询几条实际记录，贴在ppt中，如果记录太长就现场演示。不要将建表用的sql语句直接贴在ppt里。我尝试过，即便表里只有一个字段，当我看见ppt上密密麻麻的一连串字母时，心里都会有点抗拒厌烦。用表格来描述数据库表结构会清晰得多，大学里的数据库课程应该都这么干。
7、ppt最后，阐述开发过程中遇到的一些容易出bug的点，以及异常处理与保护逻辑。这时可以适当贴一些代码。但也不要全贴上来。每页ppt讲一个点，把相关函数贴上来；函数名和文件名保留，方便日后查找；函数中和这一页要讲的异常点无关的代码都删掉，用省略号代替；关键的那一两句用高亮颜色标出。大家在前面对流程和数据结构都有了解了，对这里的细节问题就更容易理解，更能听进去。到这一步，了解比较多的同事会问些更深的问题，这时就可以打开原始代码给大家看。
于是ppt到这里就讲完了。整个过程中，除非同事要求，否则只有到最后一步才展示原始代码。记得有一次主程用ppt讲单机版战斗的做法，整个过程中也是没展示什么代码，但后来当我的工作涉及到这部分时，我能回想起他讲的内容，并通过他的ppt快速理解相关代码，应该说那次分享的目的是完美达到了。
给QC一对一讲代码的思路也大致如此。不同的地方在于：给QC讲代码不会事先准备ppt，所以涉及架构、流程的东西最好在纸上画。不要一开始就直接对着代码讲流程，从这个函数跳到另一个函数，跳来跳去，那样虽然自己讲得很投入，但QC看着屏幕上翻来翻去的代码也会晕——这是我亲身体会，我就这样听过别人讲代码。虽然这时QC可以充当一部分小黄鸭的作用，但毕竟人家的时间也宝贵，所以还是让人家听懂掌握为好。另外，因为这时是一对一讲，而且QC对我做的东西一般也比较了解，所以有的地方可以讲得比较细。但最好也是放到最后讲，先在口头上或纸上把大致流程过一遍，然后再对着代码把流程更具体地过一遍。