如何讲解自己开发的程序

在很多人的潜意识里，程序员就是一群口头表达能力欠缺的技术人。作为程序员，我们必须用实际行动去反驳。

首先我们得学会展示自己的工作，自己开发出一个软件，要怎样想其他人进行讲解，偶然看到这么一篇文章，觉得非常不错，转载之，顺便附上自己的一些阅读笔记。

采用PPT展示自己的软件

采用以下思路做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(QUALITY CONTROLLER(品质控制员),),一对一讲代码的思路也大致如此。不同的地方在于：给QC讲代码不会事先准备ppt，所以涉及架构、流程的东西最好在纸上画。不要一开始就直接对着代码讲流程，从这个函数跳到另一个函数，跳来跳去，那样虽然自己讲得很投入，但QC看着屏幕上翻来翻去的代码也会晕——这是我亲身体会，我就这样听过别人讲代码。虽然这时QC可以充当一部分小黄鸭的作用，但毕竟人家的时间也宝贵，所以还是让人家听懂掌握为好。另外，因为这时是一对一讲，而且QC对我做的东西一般也比较了解，所以有的地方可以讲得比较细。但最好也是放到最后讲，先在口头上或纸上把大致流程过一遍，然后再对着代码把流程更具体地过一遍。

参考

如何更好地给同事讲代码？ by zz翔