-
Notifications
You must be signed in to change notification settings - Fork 2
注：这部分建议是葛加文（文哥）提的
每次的分享内容的表现形式是一些ppt，有可能限于演讲者的水平等因素，其实ppt的质量是有差异的。而且，我觉得仅仅靠ppt来沉淀所演讲的内容有点过于单薄了。可能会造成这样一种情况就是，分享一个主题的东西之后，就完了，没有下文了。这样的话，我个人觉得这种分享的意义不是很大。没有很高的实际产出。
我觉得可以确定一些长时期内想要精研的主题，然后附带一些兴趣项目、创意、点子。这样可能会将针对的主题有一些实际的产出。
还有一点建议就是，我们的分享能不能不要局限在技术层面？社区发展、业界生态圈、职业畅谈，甚至可以有一些类似哲学、人文的东西我觉得也是很nice的。
每次2次分享，每次的题目都是不同的，分享完了之后也没有什么具体的东西，就跟看了教程blog似得，这样没什么实际意义。最好有一些大家都参与的实际产出，这样很好消化分享的主题，又能有所沉淀。说不定在这期间，我们就找到了一个很好的方向，让自己跳出现在的圈圈。
https://github.com/lifesinger/lifesinger.github.com/issues/126
懂原生代码没有错，懂jq等类库使用也没有错，但如果以为懂了这些或半些就万事大吉了就大错特错。一门技术的原理要了解，背后的知识也要了解，怎样使用，用到哪里才合适更需要掌握，是不是有更好的技术要怀疑。我觉得玉伯不是要大家不去看源码，而是要知道光看源码也解决不了成为高手这件事，也不是看了源码就===高手，毕竟一门理论和技术不是去看了书本上的文字就能完全掌握的，可能实践与理论相结合才是提高自己的最好方法。
好的技术都是为了解决现有问题而被再创造出来的，比如nodejs，国内程序员大多是为了读源码而读了源码，写了分析报告，过后就忘记了，因为学是学了，但在工作中用不上，理论是有了，但缺乏实践，根本原因还是缺乏与业务结合的思考，缺乏在问题本身上的思考，也正是因为缺少了在这些理论上再创造和提升的机会于是难成高手。
还有，类库和框架与原生js以及js的底层语言是不同的，需要搞懂的地方也不尽相同，工具与我们日常工作息息相关，需要搞懂，而底层的东西如js是怎样设计来的，需要的时候去查阅一下吧。同样用剪刀来类比，原生的js好比是剪刀的定义：两片刀片绞合到一起用于切割东西。市面上有很多种剪刀，有大有小有粗有细有长有短，各有各的适用范围，我妈妈用来剪衣服布料的剪刀就不好拿来剪骨头。jq,yui等类库就是建立在js定义基础上针对不同需求衍化出来的工具，解决了不同的问题。剪刀长短形状不一有各自的原因和原理，同样的jq和yui有各自不同的原理，对于使用者来说了解这些原理对自己的工作百益无害。而且程序员一般都是集使用剪刀和造剪刀于一身的，更需要去了解原理。但了解原理不应该仅仅是去读源码，读源码也不一定能了解这些工具的设计原理。
不排除去学习原生脚本和类库源码，但需要更多关注代码以外的精彩，球技很好很牛逼，论技术国足绝对不错，到场上进不了球赢不了比赛就瞎了，踢好球不光光需要好技术，还需要其他好多好多，搞技术工作也一样。
锋哥之前提到：希望能找个技术点，系统地学习和讨论。而“找”是最难的，系统地学习和讨论反而简单些。我的想法是锋哥可以提一些东西，大家围绕着先看起来。大家各自的工作业务和背景不同，泛泛的分享会让大家难以找到自己能够感兴趣的部分或者用得上的部分。
所以建议先有一个具体一点的方向，可以就锋哥自己拍板，先不征求大家的意见，毕竟不可能都对某个方向有兴趣。有兴趣的就参与，没兴趣的就围观，总比目前除了分享人其他都是围观群众的情况要好。
像一起搞也有些形式可以探讨，比如不完全是分工，而是有些比较有意思的话题每个人都独立实现，最后大家来各自讲讲自己的。只有自己动手了，才能听得懂别人讲的。也希望大家能够放低姿态，看一下和自己不同的实现，优劣不必有定论，选择性的吸收经验教训。也可以给出认为自己实现更优的原因和建议，找到自己最想分享给大家的闪光点来分享，可以是架构、流程也可以是某个很细微的代码优化。