之前看曹政的书《你凭什么做好互联网》，里面关于技术人员有一个描述
大部分技术人员分享时候的盲区，自说自话，完全不考虑受众
这里摘取的不全面，不过大体意思是有的，就是很多技术人员会有的糟糕的口才，而我，正巧，也是其中一员。
不同于写作，演讲、分享、辩论，这些口语形式的思想表述，需要你在很短的时间同时掌控好思维和舌头，流畅的展现你的思想，没有编辑的概念。
而我总是想的太快，舌头跟不上，说出来的话和自己真实想表达的意思要打个折。大信息量的涌入使得舌头的性能降低，说出来的话还会有点口齿不清。
很早就意识到这个问题，可是却难有改观。
比如这次的一个活动页开发
因为业务逻辑和交互复杂的不输于一般的单页面应用，所以一改以往收集DOM操作为一个动作的抽象方式，这次用了MVVM架构的一些数据驱动视图的思路，同时还基于Redux的思想做了数据的管理。一番调整之后，自己还是有点小得意的，DOM操作和VM的完美结合。
再说点尴尬的背景，这个活动分移动和PC两个页面，功能一样，UI大体也是类似，但是却由我和同事小磊分别开发……
我知道这是一件很没脸说的事情，两个有经验的前端做了这样没动脑子的决定。虽说我是后加入这个活动开发的，可是在参与进来的时候，花一两小时好好熟悉一下项目，然后再一起讨论分工合作是一个完全合理而且必要的流程。
继续说前面的调整，因为那点小创意，所以我在开发进度上有点领先(UI和很多前期代码是直接从小磊那边拷贝过来的)。小磊那边在管理UI上的数据变动这块遇到了一些问题，业务逻辑有点复杂，各种弹窗，还有多个模块之间的数据通信，纯DOM操作对于掌控全局变化就有点吃力。
这时候为了进度，我尝试跟小磊介绍一下我的处理问题的思路。我想跟他说数据驱动，订阅者，MVVM，React，Redux……
是的，面对一个分享将会带来的荣耀，我一瞬间就想了这么多。打开我的代码，开始了介绍：“这个活动很复杂，所以咱们得用数据驱动的方式开发，你看我这个dataCenter，我把数据都放这里面用getter和action维护，然后action里面发布事件，再看这块，main这块，对数据更新做了响应。再看这块，抽奖回调里面调用action来更新数据。还不错吧，其实这个是借鉴redux里面的思想，store”。话没说完，小磊同志不耐烦了：“越说越懵，所以我这个问题该怎么解决？”
尬了一下，小磊向来耿直。
“那就先不看我这个实现，你这现在是哪有问题了”。是的，我还没弄清楚具体哪出问题了。
后面仔细看了看小磊的代码，指出了一些模版里面基于数据的逻辑判断问题，再给了一个全量更新列表模版(数据量少，就几条)的思路，总算是博得一句“哦，原来这样啊”
一点总结
伤痛中总是伴随着成长，不好好想想说出去的话，早晚是会遭殃。
在这件事上总算对自己糟糕的口才又有一次认识，也知道区分在什么场景下做技术分享，什么场景下是bugFix。做技术分享要精要细，bugFix就不要废话太多，讲究快准狠，以解决问题为只要目的。
PS：值得安慰的事第二天一上班，小磊就过来说：“我昨天晚上仔细想了想，你的那个dataCenter真是太有必要了”
