那些年导师说过的金句

师父领进门，修行在个人。

很多时候，能力的提升会受到思维方向上的限制。

这个时候，经验丰富的过来人一两句指导或许就能帮助我们短时间内破局，杀出重围。

今天就来分享一波我的两任导师给我的指导，颇有一种初闻不知曲中意，再听已是曲中人的感觉。

学会推动事情的发展

在我实习期间，接手第一个需求后，导师和我说要学会推动事情的发展。如果团队划分比较合理，那么开发人员需要对接的是需求人员，设计，测试，运维。涉及数据接口联调的话，还需要和后端同事配合。

任何一个环节卡住，都会影响项目上线。当发现某个环节进展不符合自己预期时，要找到对应的负责人去沟通对齐。方式有很多：微信、开会、私聊都可，但重在这个意识。

如果每个人都只关注自身，等着别人催，没有主动性，那事情进展必然会很慢。与之相反，如果很多次你都能起到推动性作用，久而久之提升的不只是个人能力，还有团队影响力。

学会问题分类

开发中遇到问题可太常见了，但总不能事无大小，全都去问导师，导师也很忙的。

可根据自身能力和项目上线时间对遇到的问题进行一个划分，标明优先级。 对于自己能解决，但是比较耗时的问题，需要结合上线时间做权衡。如果时间充足，可以挣扎一下。时间很紧的话，可以去找导师或者其他同事求助。解决完后一定要追问根本原因，不要解决完后就不管了。这里可能会陷入一种你觉得你会但是你高估了自己的困境，半天过去了，毫无进展。所以要给自己设定一个deadline，到时间了还没解决就去求助。

对于自己不能解决的问题，需要细分是卡在业务上还是技术上。如果是业务问题，你就去问熟悉这块业务的人，如果你不知道谁熟悉，问导师。技术问题的话，向导师描述出你具体的技术痛点在哪，不要直接说你react不会，vue不会。

要学会对遇到的问题做一个优先级排序，主次分明。先解决用户有感知的功能问题，其他的小问题可以优先级低一些。避免因为一个小样式调了一天，功能还差很多的尴尬局面，得不偿失。

要有知识沉淀的意识

随着业务经验的积累，你会遇到很多业务问题，技术痛点，奇奇怪怪的bug。这些东西最终是如何解决的，要做一个记录。有个人技术博客就放博客，记得敏感信息要脱敏。没博客可以放那种在线云笔记平台，比如语雀，有道云笔记，甚至GitHub也行。

分割区间问题排查

遇到某个问题后，要先对问题定性，把握其主流程，然后通过不断切割来缩小可能发生问题的区间，最终逐步尝试并解决。举个例子，react组件未能如期渲染。需要分析组件从你编写到展示经历了哪些环节，jsx到render。可以从入口的App组件是否预期渲染，目标组件父组件是否预期渲染，目标组件是否有条件渲染的逻辑限制等等方面去考虑。

知识是检索的

不必盲目学一堆你感觉能用到但实际上现在的公司没有这样业务场景的东西。对于你用不到的，长时间就会忘了。那样的话，你之前学习这些东西所花费的时间等于浪费。知识是检索的，这意味着你去学习那些在实际业务场景中涉及的技术会更有价值。有实战经验，才能更好地加深记忆。

你和别人可能只是一本书的差距

每次和导师沟通完我就觉得我好菜，然后导师和我说了这一点：你和别人可能只是一本书的差距。我信了，安慰也好，鼓励也罢。信心是有了，然后撸完了红宝书，发现能力确实有提升。闻道有先后，从这点考虑，一本书的差距，也是有道理的。

第一手资料

在学习某项技术的时候，导师告诉我说要尽量看第一手资料。特指那些没有经过其他人二次加工的东西，比如个人博客什么的就不算第一手资料。每个人都有自己的想法，能力不同，理解不同，产出自然也不同。看《你不知道的js》上中下的翻译就知道差异所在了，只有上卷封神。相比之下，英文官网好于中文官网，英文版书好于翻译版书。默默说一句，其实最好的第一手资料是源码。

文档先行而非代码先行

正所谓磨刀不误砍柴工，实现某个功能前先写一个技术方案文档。最开始写越详细越好，后期可以简略写。这样的好处是可以在最开始就先把可能想到的问题捋清楚，避免直接撸代码带来的不必要返工。

未知不代表一定难，不要有畏难心理

这个大概也算是对我的鼓励吧，勇敢迈出第一步。其实某些新东西，只是你尚未接触，不见得多难。看看文档，用一用，或许也就那么回事，不过如此。

分享意识

分享其实是一个正向反馈。自己在准备分享的过程会查阅很多资料，尽可能全地准备，这样一次分享下来收获良多。而其他参与分享的人有可能会提出一些完善或者反对的意见，这都能帮助你加深理解。

学会排期

不管任务紧不紧，都要有排期意识，这其实是提效用的。没有排期，自己就是随便做，漫无目的地做，前松后紧或者前紧后松，不能平缓过渡。毕竟，有压力才有动力。

再会

情如风雪无常,

却是一动既殇。

感谢你这么好看还来阅读我的文章,

我是冷月心,下期再见。 ​