淘宝前端工程师：国内前端行业十日谈

 

匠人多福

如果你能耐心读到这里，心里一定有一个疑问，上面说的都是技术上能力上怎样怎样，那我所做项目不给力又当如何？如果项目不挣钱、黄了、裁了，我的努力不就白费了吗？我又有什么绩效和价值呢？

没错，有这种想法的人不在少数。特别是刚出道的校招同学往往更加心高气傲，以为自己有改变世界的本事，一定要参与一个牛逼的团队做一款光鲜靓丽受人追捧能给自己脸上贴金的项目。如果你有这种想法，趁早打消掉这个念头，当然，我们这里先不讨论创业的情形。

第一，如果你刚毕业就加入一个牛逼团队，说难听点，你就是团队中其他人眼中的"猪一样的队友"，不创造价值且拖项目后腿（显然大家都要照顾你的成长啊），按照271理论，你没有理由不是这个1。至少相当长一段时间内是这样。

第二，你在所谓牛逼团队中的创造性受限，因为创新多来自于团队中的"资深"和大牛们，你参与讨论但观点通常不会被采纳，他们只会给你这个菜鸟分活干，想想看，你如何能花两到三年就超越身边的大牛们？甚至连拉近与他们的距离都难。

第三，如果身在牛逼团队，自然心理对周围的牛人们有所期待，希望他们能灌输给你一些牛逼的知识和牛逼的理念。这种思想上的惰性在职场生涯之初是非常危险的。要知道技术和知识本身是很简单和淳朴的，只不过披上了一个光鲜项目的外衣而让人感觉与众不同。

第四，由简入奢易，由奢入简难，做过一个看似光彩的项目，心理再难放平稳，去踏实的做一个看上去不那么酷的产品。这种浮躁心态会严重影响今后的职业发展和成长。

第五，光鲜靓丽的项目被各种老大关注，是难容忍犯错误的，傻瓜都知道犯错误在成长之初的重要性。

就我所看到的情形看，一开始加入看似很牛的项目组，三年后得到的成长，比那些开始加入一个不被重视的项目的同学要小很多，而后者在能力上的弹性却更大。所以，道理很简单，你是要把一个很酷的项目作的和之前差不多酷，还是把一个不酷的项目做的很酷？项目是不是因为你的加入而变得与众不同了？

从这个角度讲，不管是转行的新人还是刚出道的秀才，最好将自己当作"匠人"来对待，你的工作是"打磨"你的项目，并在这个过程中收获经验和成长。付出的是勤奋，锻炼的是手艺，磨练的是心智。因此，你的价值来自于你"活儿"的质量，"活儿"的质量来自于你接手的项目之前和之后的差别。做好活儿是匠人应有的职业心态。想通这一点，内心自然少一些纠结，才会对自己对项目的贡献度有客观的认识，不会感觉被项目所绑架。

做一名多福的匠人，拥有了金刚钻、就不怕拦不到瓷器活儿。但对于人的成长来说，如果说"项目"重要但不关键，那么什么才是关键呢？这个话题还会在接下来的"伯乐与千里马"这篇中给出答案。

若干年后

现在，让我们回过头回答一下"青春饭"的问题。在"青春饭"小节中提到，"程序员到三十岁之后需要转行或者转管理吗？"

上文提到，工业化生产的四个领域，1，创意，2，生产线，3，高级技工，4，技术管理。Web前端技术也是如此，可以在这四个领域找到各自的归宿。

第一，"创意"

即和产品需求越走越近，拥有良好的产品感，对产品需求、设计交互把握准确，能够用适当的技术方案推动产品用户体验，属于"架构师"的范畴，因为职能更加靠前，偏"出主意"型的。这种人更贴近用户，需要活跃的思维、广阔眼界、厚实的项目经验。更多的影响产品体验方面的决策。

第二，"生产线"

即前端基础设施建设，优化前端开发流程，开发工具，包括开发环境、打包上线自动化、和各种监控平台和数据收集等，属于"技术支持"的范畴，相比于很多企业粗犷难用的平台工具，前端技术方面的基础设施建设基础还需更加夯实，因为这是高效生产的基本保证。

第三，"高级技工"

即高级前端开发工程师，专职做项目，将产品做精做透，用代码将产品用户体验推向极致，偏"实战"型的，是项目的中坚力量，直接产出成果，影响产品效益。属于项目里的"资深"。

第四，"技术管理"

即做技术经理，这才是多数人所理解的"管理"，其实就是带团队、靠团队拿成果。这类人具有敏感的技术情结，在技术风潮中把握方向，能够指导培训新人，为各个业务输出前端人才，偏"教练"型的，促进新技术对业务的影响。并有意识的开辟新的技术领域。

可见，转管理可不是想当然，也不是所谓做项目变资深了就能转管理，转了也不一定能做好。根据"彼得原理"，即人总是倾向于晋升到他所不能胜任的岗位，这时就又陷入"帕金森"定律所隐喻的恶性循环之中，直到你带的团队整个垮掉。

所以，转管理应当是一件非常慎重的事情，不是所谓程序员混不下去就转管理这么简单。但不管怎样，有一件事情是需要尤其要想清楚，即，转了管理，技术就丢了吗？我们在第七日"伯乐与千里马"中再深入聊聊这个事儿。

第七日，伯乐与千里马

师兄们的抉择 1

千里马常有，而伯乐不常有。——韩愈，"马说"。

一个人这辈子能遇到一个好师兄是一种缘分，可遇不可求。很多人工作中的幸福感似乎也源自这种被认同，被师兄的了解和认同，有人能直言不讳的指出你的不足，帮你发现机会，并将最适合你做的事情分配给你，这是莫大的幸运，但如此幸运的人十之一二，大多数人因为缺少伯乐的提点，渐渐辱于"奴隶人之手"，潜力渐失，毁于中庸。

在前端技术领域，这种情况很普遍也很特殊，当然有很多客观原因。即前端技术进入公众视野时间不长，有实力的伯乐更加是凤毛麟角。更何况，Web前端技术还有着一些江湖气，知识点过于琐碎，技术价值观的博弈也难分伯仲，即全局的系统的知识结构并未成体系，这些因素也客观上影响了"正统"前端技术的沉淀，奇技淫巧被滥用，前端技术知识的传承也过于泛泛，新人难看清时局把握主次，加之业务上的压力，未免过早导致技术动作变形。而这些问题也无法全赖自己全盘消化，若有人指点迷津，情况要好上万倍。因此，前端技术领域，为自己觅得一个靠谱的师兄，重要性要盖过项目、团队、公司、甚至薪水。

这也是上文所说的"项目不重要，师兄才重要"的原因。说到这里就有一个问题，每个人都问下自己，你是想当师弟呢还是想当师兄呢？当师兄有什么好处呢？

没错，很多师兄都是被师兄，甚至没有做好当师兄的准备，更进一步说，不少经理人也都是"被经理人"，没有做好准备就被推到了管理岗位。带人是耗精力的，师兄要做很多思想斗争才舍得把这些宝贵的精力放在那些菜鸟身上，这不是一个技术问题，而是一个道德问题。要记住，没有谁应该无缘无故把自己所掌握技能给你倾囊相授，如此皆命也。读到这里，作为菜鸟，作为学徒，作为新人，作为师弟，你做到对这份命运的足够尊重了吗？

尊师重教的传统美德并没有在技术领域得以很好的延续。也正因为此，人才梯队难建立起来，但对于师兄来说，却是有更多机遇的。

师兄们的抉择 2

作为师兄，不管是主动还是被动，肯定会想当师兄对我有什么提升？对于初次做师兄的人来说，最大的提升在于两方面，1，任务分解，2，问题分析。

第一，任务分解，作为师兄要给师弟派分任务，就涉及到任务分解，分解这事儿往低了说，就是派活，往高了说，其实就是做"架构"，比如一个页面，按照什么思路进行模块划分，模块划分是否适合单人开发，如何控制共用样式和共用脚本，我需要为他提供什么接口，如何控制他的代码并入整个页面时不会影响整体页面代码的熵值，这些都是实打实的"架构"应该包含的问题，而从小页面开始就做这种锻炼，做的多了，"架构感"自然就形成了。

第二，问题分析，在之前自己写代码都是单打独斗，什么都是用代码解决问题，但一旦涉及协作，就要强迫自己分析问题，或者说给徒弟分析问题，告诉他应当用什么方法来解决问题，当说到"方法"时，脑子里定形成了一个方案，按照这个方案路子走一定能解决问题。分析问题比写代码要更抽象、更高效，因为在脑子里构建方案要比写代码要快，思考也会更加缜密，当锻炼的多了，思考越来越快，代码的草稿也很快就在脑海中形成了，这也是我们说为什么很多人不写代码但编码思路和水平都很高的原因。

这些工作方法对了，积累多了，就是提高。对于技术经理人来说，也是同样的道理。所以，就像在第五日的"得与失"部分提到的那样，转身师兄、变身管理并不意味着"失"掉技术饭碗，而是一种进步。

做自己的伯乐

那么，在前端技术领域里什么样的人才算千里马，其实人人都是千里马，人人都可以发掘自己的潜力，如果上面的文字你能读懂，能认可，这种自我发掘已经开始了，没有一个好伯乐又何妨呢？做一个勤快的小码农，少一些势利的纷争，很快会发现，自己才是最好的伯乐。

但这并不是说，他人对自己的观点不重要，有时甚至要综合各种声音，所以，多找身边的大牛们聊聊天，多找你的师兄和主管，不管他们给你的建议是多么形而上，总有一些声音对你是有益的，多收集，有好处。