我希望的前端攻城狮
前言
我个人，并没有工作很长时间，但是确实也见过不少前端攻城狮。
兴趣很深的，纯粹工作谋生的；
刨根问底的，浅尝则止的；
偏重管理的，执着于技术成长的；
极具天赋的，需要前辈指点的；
... ...
自己经历过两家大公司，碰见过不少前端攻城狮。在换工作之时，也面试过不少或大或小的公司，他们面试我的同时，也是我面试他们。从中，也大致能感知，对方面试的着重点是什么。也就对这篇文章有了比较重要的参考依据。
各种分类，你能想到哪些？
或者你还可以分一下，从积累成果来讲——坚持写博客的（但是，你需要问问你自己，你的博客中的文章，够精华吗？），没有过多思考总结的；或者，有成品展示的（如github上的源码），只能口语表达实力的。
我个人还想这么区分，从理论与实践的区分——善于理论分析并思考于实践的，或者通过实践去反推（重新思考）理论研究的。
当然还有，动手能力来讲——碰见问题，及时分析并快速动手解决的，或者稳扎稳打，全局思考，一丝不苟的。
毕竟在大公司呆过，或者你的分类标准来自BAT这种大公司的等级制度，如百度的T几T几的，这些东西或多或少能证明点儿实力，但是，切不可拿它涵盖全部，否则，你会埋没了他的真实才能。
你工作中深入接触的每一个同事，你都可以为他产生一种分类，那是因为你发现了他的可贵（更有可能是他的平庸）之处。
以我的视角，我希望你可以如此（当然，千万别在意我的语气有点儿大了）——
重理论
绝大部分的前端都是实践驱动的，这样并没有错，实践能够让大家更加深入的理解理论。我想强调的是，别忘了实践之中，或者实践之后，多看看相关技术点的理论部分，深入研究之，再反转过来，联系实践，不断的理论与实践去结合，更多的不是为了应用实践去验证理论，而是两者结合不断的思考，引入更深层次的解决问题或者创新。
相信绝大部分的理论来自阅读“枯燥的”书籍。没有错，很多书籍能够帮助我们全局看问题、深入看问题。
这么长时间的工作经历，碰见能够“智慧”看书的，真的不多。很多人，书籍读的是快，但是，只懂了皮毛，只知道好像是那么回事儿。如果你没有深入思考，读之何意。
谈到重理论，不单单读书，毕竟很多书籍也是通过实践总结汇总出来的，也同时多看看网上优秀的理论性质的文章。说白了，重在把你想要弄清楚的理论点（举个例子，如js闭包、函数式编程等等），结合你的实践，深入理解透彻。
善创新
我所谈到的创新，不是指很大的方面，如管理体制、工作流程等等（当然，如果不排斥这类的创新idea），更多的是指诸多小的方面，如小工具的使用、一些实时出现的创新技术、编程模式、架构模式等等，说大也大，说小也小。
在这里，我列举可能创新的来源——
实时跟进一些新技术网站，领略新技术带来的冲击。当然，如果你从这些新技术的学习中，你对它有些更优秀的改良，那再好不过。不过要记住，结合自己的项目来做创新，你的改良能够解决你项目中的问题。
同事讨论。问题讨论的过程中，思维暴风雨式的撞击。希望你可以陶醉于技术的讨论之中。
发觉问题。这里的问题，指的是项目中发现到的种种，如底层框架、项目架构、编码风格、团队协作等等等等，这里需要你敏感的嗅觉，与经验、知识量多少有些关系，如果你是新手，不要在意你的思维过窄，或许你的idea，其他老油条并没有思考过。
但要注意，所谓的创新，不仅需要你敏锐的思考，更重要的是实践之。不管你的创新贡献于个人，还是团队。、
乐分享
这一点，我多说点儿——
在时间上，你可能没有多少时间去筹备PPT文稿，也没有时间，把你要分享的专题去进行深入调研或者扩展。工作忙完一段时间之后，你的分享idea也就渐渐淡了，因为你总有更重要的事儿等着你。
在团队里，你做了很多不错的分享，但得到团队认同的分享却少之又少，很难用于项目之中。
在团队里，你也很难碰见与你同样享乐于分享的同事，你的分享换不来其他人的分享，你似乎总是孤独的一个。
在面子上，你也可能会担心你分享的内容太过肤浅，会带来同事瞧不起的眼光。
更有可能，你觉得你做的东西或者你调研的东西太easy，自认为没什么可分享的，没啥技术含量，不屑于分享。
... ...
我曾致力于团队的学习氛围的建设，但多人的反馈之中，似乎有太多的愿与不愿、成与不成。
我希望你可以多思考分享带来的好处——
其一、自己可以对分享专题的把握达到一定深度，并可以努力将分享的专题成为你立足于团队的优势。
其二、塑造自己在团队乃至整个公司的个人影响力。
其他、语言表达力的提升，个人气场的锻炼等等。
我曾听到一个同学这样描述，当他发现某一个技术创新点的时候，他总想向别人分享出去，一起讨论讨论，一起用用，提高点儿开发效率...
简单的描绘，却印象颇深。希望你也可以如此。
分享，它在技术大家庭来讲，本就很简单，我们只是单纯的讨论技术，讨论它怎么让我们提高开发效率、解决项目问题等等。如果考虑其他乱七八糟的事儿，那么你离技术就远了。
成果导向
这一点，并不是针对那些“光说不练”的同学。更多的是那些思路开阔却不善实践的同学。毕竟实践出来的东西才能给自己的团队或者公司带来收益。
一位前辈的话——先成事，是成有利。
先把事儿做出来，也就是所谓的成果导向，这样团队的同学才能认可你，你也就有了坚实的合作基础。
那么，所谓的成果导向，是指什么——
如果你调研某一项新技术，你先用之，不要求你直接应用于项目之中，哪怕你跑出个不错的DEMO，再把它展现出去，再提出你理解的优缺点，不要拿着官网的介绍说说而已。
如果你的项目中不得不用到某一项新技术，用完之后，希望你把技术的关键点结合你的项目实践一起展现。
如果你思考很多，却无暇分享，也希望你可以将之形成博客之类的文档，将之分享出去。这里的博客，也将成为你思考的小成果。
如果你在阅读某个书籍，你发现某一个点子，非常值得实践，不要犹豫，实践出来（无论你贡献于线上产品还是线下产品），再与大家详细说说。
... ...
成果导向，为的更多的，是自己深入把握形成成果过程中用到的技术，带来团队及公司的收益的同时，驱动自己成长。
完美主义
谈到完美主义，相信每一个程序员都有，只是或多、或少的区分而已。
我要声明，我所说的完美主义，是优点，而非缺点。
如果你坚持自认为还算不错的编程风格，那么，我想你仅仅有轻微的完美主义。
如果你一个空格、一个分号你都不放过，那么，我想你有过重的完美主义。我表示，很赞（哈哈）。
因为一个空格，一个分号，在你看来，他们的不和谐，将导致你整个代码体系质量的下跌。这将导致，你对这款产品的失望（当然，我说的有点儿夸张了）。
你可以有重度完美主义，但我希望，你针对的是个人，这也就代表你对自己有着极高的要求，也就很有可能，你将在你所在的领域达到一定高度，这全然来自你的完美主义精神，你不会放过任何一个阻碍你不完美的地方，这种自驱力会让你把每一个问题都解决的非常透彻深入。
但要注意，几个方面——
其一、要把握住做事儿的时间，不要把重要的事儿，因为你的完美主义而被耽误。
其二、不要局限在封闭的个人主义里，你需要接纳他人的观点，相信他人的思维更能开阔你的完美主义。
其三、毕竟产品是多人协作完成的，你要虚心接纳他人看起来不是很好的代码，要相信他们的上升空间。要宽以待他人的不完美之处。
其四、要善于学习他人的过人之处，不要钻牛角尖。虚心求教进步。
完美主义的工程师，要好好享受你的卓越之路。如果你是，欢迎你与我多加沟通。我个人极其欣赏重度完美主义的工程师。
OK，确实啰嗦了很多。
什么大众选择的标准，如天资聪慧、动手能力强等等，在这里就不说了。但我要强调，你需要自信、更需要努力。
以上偏向于管理方向，但我个人不喜欢走管理方向，只是在工作过程中，略有思考。
以上是几个大的方面，或许你或多或少都有些，也希望我的观点能够给你带来些许指引。
希望可以在日后的工作中，可以碰见拥有以上特征（其中的几点、全都有那就更好）的同学。一起玩儿技术、讨论技术、分享技术。
我不奢求你多么高尚的热爱编程，只是希望也可以或多或少——喜欢思考、善于总结。
今年开始的第一篇博客（这次是纯非技术类），同时鼓励自己日后一个月一篇精华技术类博客，捡起来写博客的习惯。实在是非常清楚写博客的好处，希望看到这篇文章的你，也可以写写博客。
如果你正好有点儿上述我讲到的特征，正好也是前端攻城狮，欢迎与我沟通，当然更希望你加盟。