这是学习笔记的第 2356篇文章

近些年来也多多少少参与了一些技术方案的评委，包括产品方案评测，晋升汇报评审等等，每次参加完之后都有一些感慨，如果有些细节能够重头再来，可能对于候选人是一种更好的结果。

一般的汇报或者评审和我们通常所说的技术大会分享是截然不同的，技术大会相对来说主题更加聚焦，听众显然是会带着一定的期望和兴趣或者问题来听，在内容形式上对于讲师相对来说要更主动一些，或者更生动一些，主要目标是让听众理解自己做的事情，尤其是一些实现的细节和亮点，而汇报或者评审就相对会多一些的形式和规范的约束，总体来说要在短时间内明确你做事的意义和成果，要同时体现技术价值和业务价值，在深度上和广度上都要有侧重，显然是比较有挑战的。

我大体总结了下，一般我们总结的ppt的内容有明显的一些问题，希望给大家一些参考。

首先就是对待ppt的态度，就是你准备的内容，如果标题有错别字，或者有一些拼写的低级错误，其实从态度上来说就是有问题的，尤其对于评委来说，如果把这些细节说出来，显得有些太琐碎，但是在很多细节之处都可以看出候选人对待一件事情的态度和认真。在我看来，不要求ppt很精美，但是希望布局简单清晰，看起来要整洁，尤其是一些专心做技术的同学，做ppt不是很擅长，但是如果这是你职业生涯中的一个重要节点，哪怕你再排斥一些形式化的流程，这些事情建议也是需要投入一些时间的，这种事情还是建议和你的主管或者领导做一些沟通，帮忙过过目，给点建议。

在技术细节方面，我觉得有一个通用的问题，那就是对于技术细节的描述过多，或者比例失真，这是比较吃亏的。一般大家都会拿出几个自己觉得还不错的案例来作为说明，大篇幅的文字和描述是比较难以量化的，但是如果通过一些辅助的形式或者技巧就可以达到很明显的效果。

比如有的同学说自己做了架构改造，如果拿出原来的架构和改进后的架构，两者进行对比说明，其实是比较清晰的，比纯文字的方式要好很多，另外是对于改进的部分，最好能够量化，比如有一个同学提出对于数据包的改进提高了20倍，他列出了数据包的计算公式，并且把优化前后每一个改进项的指标值都列出来，整个优化的效果一目了然，比直接说改进了X倍效果要很多。

对于研发侧的一些同学来说，列出系统架构图是比较简单干练的，但是我看到有一些同学的架构图画的有逻辑问题，比如架构图和流程图等是混合的，而且箭头的指向要么缺失，要么是经不起推敲的，这是大打折扣的。

在架构设计方面我看到比较大的一个短板是很多同学对于服务降级的考虑是缺失的，比如架构体系中依赖Redis服务，但是在设计中没有任何考虑过Redis不可用的时候，如何和缓存层有效的结合起来，在数据一致性方面的考虑是不周到的，同时对于数据库层的水平扩展是很多研发同学忽略的，对于无状态的水平扩展相对是比较容易的，但是数据库层往往就成为了短板，从这些角度来看，也可以看到数据库和研发侧还是存在着一些观念的隔板和壁垒。

此外，对于个人规划来说，很容易成为一个潜在的雷区，那就是对于规划缺乏思考和规划，比如你列举了很多的事情，但是这些事情孰轻孰重，应该如何开展，怎么合理的协调资源达成目标，这些通过一些简单的问题就能看出来你的规划是想想而已还是深入的思考。

总体来说，一次汇报是在短时间内更清晰的展现自我，在企业中我们体现的价值是解决了有价值的问题，而价值需要从业务价值和技术价值两个角度来综合衡量，在其中融入了你的深入思考，简单的问题也可以有更加通用的解决方案，人毕竟是喜欢偷懒的，而这恰恰是经验和价值所在。

当然回过头来，我还是喜欢把一些开放性的问题列出来，毕竟挑毛病是一件相对简单的事情，如果我是候选人，我该如何更好的回答问题，哪些角度是我没有考虑到的，对彼此都是一个学习的过程。

各大平台都可以找到我

• 微信公众号：杨建荣的学习笔记

• Github：@jeanron100

• CSDN：@jeanron100

• 知乎：@jeanron100

• 头条号：@杨建荣的学习笔记

• 网易号：@杨建荣的数据库笔记

• 大鱼号：@杨建荣的数据库笔记

• 腾讯云+社区：@杨建荣的学习笔记

原创热文：

维护之夜，说点故事和经验

我们为什么在MySQL中几乎不使用分区表

新年大吉 总结了如下的感想

《大江大河2》最触动我的一段经典对话

MySQL 8.0给开发方向带来的一些困扰

迁移到MySQL的业务架构演进实战

如何优化MySQL千万级大表，我写了6000字的解读

一道经典的MySQL面试题，答案出现三次反转

小白学MySQL要多久?我整理了10多个问题的答案

QQ群号：763628645

QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过

点在看，让更多人看到