最近一段时间，通过和不同的人对话，脑海中涌现出了一些想法。另一方面也意识到自己正处在职业生涯的某个节点上，回顾从业的这几年，有得有失，所以想借这篇文章聊一下工程师成长这个话题，旨在能给大家带来一点点思考。受自身经验所限，这些观点不一定对，希望朋友们可以辩证的去思考。因为自己的职业属性，这里讨论的仅限于软件工程师这个群体。当然如果下面这些经验之谈能帮助到更多其他领域的同学，那我也荣幸之至。下面是正文，会分享几个个人认为工程师成长之路上很重要的点。
我之前作为一个求职者在面试的时候，喜欢问面试官一个问题：“你觉得优秀的工程师有哪些特质？”不同的面试官给出的答案不尽相同，但是他们几乎全都肯定了基础的重要性。
究竟什么是基础？我理解的基础大体上可以分为两类，一种是硬性的、可以被量化的，另一种是软性的、不可被量化的。这两者在你踏入职场前，身上就已经具备了其中部分才能或者潜质。
前者就是技术基础，对于这一点，不同岗位的要求是不一样的。比如以前招前端工程师时会要求你会 JavaScript、CSS、HTML 三剑客，随着现在行业越来越卷，要求的东西也越来越多，React、Vue、TypeScript、数据结构、网络等等等等。这里面有很多都是计科或者软工专业的同学在大学里学过的课程。这些也是比较容易被后天习得的，只要你肯踏踏实实静下心来学习几个月，肯定会收获很大。
而后者，不可被量化的那一类，则相对来说要难一些，不是所有人都可以短时间速成的。有些人生下来就具备这些特质，而有些人就算时隔多年也是在原地踏步。这些特质，包括但不限于学习能力、解决问题的能力、沟通能力、领导力。工作时你会发现跟有的同事讲话，非常顺畅，一点就通；而跟有的人沟通起来却很辛苦，恨不得把一句话扳开揉碎了喂到他的嘴边，这其实就是一种软素质较差的体现。
说了这么多，那么怎么样培养建立基础呢？我的答案是：刻意练习。明确自己的弱项，然后不停地反复地去刻意练习它。我刚上大学那会儿，每次上台讲话都会超级紧张，紧张到发抖冒汗。后来我做了个尝试，去学校的电信营业厅卖手机。这样每天都要被迫和许多人讲话，慢慢地学会了比较从容地面对人群讲话。有一个著名的一万小时定律，它说的是要成为某个领域的专家，需要 10000 小时。其实如果能在某一项上，坚持练习 1000 小时，就已经非常非常厉害了。
品味这个东西很难讲清楚。对设计师来说，审美品味是必备的，对于软件工程师来说，同样也要有对于技术的审美，需要知道什么是好的，是优雅的。而且我发现技术品味跟工作年限并没有太大的关系，更多跟个人的眼界有关系。当你看到的优秀的东西足够多，慢慢地也会具备识别能力。
所以提升技术品味的方法无它，唯有开拓眼界，多去阅读优秀的项目，从中汲取养分。当然这里并不是推荐大家去阅读各种晦涩难懂的源码，前端社区经常见各种源码分析的文章，很多文章在我看来都只是在翻译代码，用中文描述这些代码干了什么，而甚少去研究别人为什么这么写，背后的设计思想是什么。代码会过时，而先进的思想永不过时。
另外想推荐一本书《重构，改善既有代码的设计》。很庆幸我在学校图书馆某个角落翻到了这本书，让我知道了什么是好的代码。
人非圣贤，是人都会犯错，尤其是对软件开发者来说，犯错更是一件再正常不过的事。之前听公司里一位前辈分享，他说现在的年轻人越来越谨慎，不敢犯错，怕承担责任，但其实犯错有它的积极意义。
刚参加工作那会儿，记得是一个周五的下午。我匆忙提完代码，准备上完线早早下班。结果一个操作失误，把测试环境的代码发布到了线上。没过多久，办公室开始炸了，所有人都发现我们的首页白屏了，因为线上请求全打到了测试环境的一台机器上，整个事故持续了半小时。事后做了参加工作以来第一次 case study，总结出了几点，让我到现在也受用：
1. 不要在周五下午上线。因为一旦出事，可能也会连累你的同事跟你一起加班。减少上线频率肯定是可以减少事故发生概率的。
2. 对上线保持敬畏之心，做好各个环节的线上验证。这样就算不能拦截问题，也可以早一点发现问题。
3. 机器比人可靠。对于上线这种高危操作，应该将过程尽量自动化，交给机器来完成，而不是人手动的操作。机器要比人可靠得多。这其实就涉及到一个公司的基础技术设施的建设，大公司在这方面做的要比小公司好很多。
这种可以让人铭记终身的case，对个人的成长是很有帮助的。所以我想说，不要害怕犯错，犯错后积极总结经验，避免同样的错误发生第二次，才是最重要的。顺便还想说一下，找工作时，团队对于新人的宽容度或者说容错率，我觉得也是求职者需要考虑的一个因素，好的团队氛围会给予新人充足的试错空间，这对于新人成长是很重要的。
不要给自己设限，这一点可以决定自己的成长天花板。比如对于前端工程师，如果限定自己只在这一个范畴，那么你可能会错过很多精彩的东西。三年前是切图仔，三年后还是一个切图仔，只是可能切图更快了，这样可以做的事情会非常局限。而如果把自己放到一个更大的领域，做一个软件工程师，或者去接触产品运营，去了解金融知识，会发现世界又变大了一些。
不断去接触新的事物，可以让我们的思路更加开阔，避免成为井底之蛙、坐井观天。一直以来不是很喜欢程序员这个称号，不管是程序，还是开发程序的技术，本质上都只是工具。要去驾驭使用工具，而不是成为工具的信徒。经常见社区争论不同框架哪个更牛，还有 React 粉、Vue 粉，他们之间甚至还互相攻击，这就好像两个工人争论哪个牌子的大锤更好用。管它是黑猫还是白猫，能抓到老鼠就是好猫。
多了解不同领域，跳出固有思维模式，换一个角度来思考，有些问题或许会有不一样的答案。促使我们去了解学习这些的动力，可以是对未知的好奇心，可以是兴趣，可以就是单纯为了赚更多的钱。
“以终为始”（Begin With The End In Mind），是《高效能人士的七个习惯》里提到的一个习惯。这个习惯讲的是先在脑海里酝酿，然后进行实质创造，换句话说，就是想清楚了目标，然后努力实现之。一位美团工程师在一篇叫《写给工程师的十条精进原则》的文章里也将这一条作为原则之一。
做一件事情前，先想清楚做这件事的目标，然后围绕这个目标去制定实施方案。虽然道理很简单，但遗憾的是，很多时候我们都忽略了这一点。这样导致的后果是，我们可能花费了很大的工夫，但最后收效甚微，甚至事情做一半就黄了。这一点在技术项目上体现比较明显，我自己之前就犯过这种错误。某一天发现可以在项目中引入一些性能优化技巧，来提升首屏渲染速度，于是很快就开始写代码，然后迅速上线。后来在准备述职材料时发现，我甚至不知道那次究竟优化了多少性能，保不齐还是个负优化。对于这个例子，当我们提出要优化项目首屏性能，那么首先需要知道性能现状，需要知道性能的瓶颈在哪，基于这些信息来合理制定我们的优化目标，例如把首屏时间从 3s 优化到 2s。然后才是制定优化方案，最后才是写代码。
最近几年，国内互联网公司盛行 OKR 文化，OKR 算是以终为始这个原则的有力实践。这个制度本身是好的，只不过在实践过程中，慢慢流于形式，变成了披着 OKR 外壳的 KPI，这也招致很多人的吐槽。这个话题可以另写一篇文章来聊了。
这一点，也是我认为最重要的一点，所以放在了最后。身体是革命的本钱，没健康的身体，其他任何事情都无从谈起。健康这个东西，只有在失去了它之后才会真正意识到它有多么重要。一些俗套的祝福语，“身体健康”、“幸福快乐”等等，我发现确实是人最需要也最重要的东西。所以，加强体育锻炼，多出去走走吧。人生路还很漫长，有强健的身体，才能正常走完这漫漫长路。
以上是我认为工程师成长路上很重要的几点。有些想法可能会随着年龄的增长、阅历的提升而改变，也希望最好会变化，毕竟如果一成不变，意味着也就没有成长了。