前端工程师的自我修养 live --记录总结

 1.如何成为高效率的工程师？

     关于提高效率，可以通过时间管理使自己有压迫感，例如安排日程表，不要安排一些很模糊的事项，因为这些任务没有一个很明确的目标，你无法明确的知道自己是否完成了今天的目标，把自己待完成的事项大而化小。

     有时，你的拖延者犯了，很多任务都堆在了最后一天，这个时候就完全乱了，比较科学的时间管理的方式是对于自己的日程表采用倒三角的安排方式，例如一周里，第一天任务安排满，第二天留两个小时空余，第三天留四个小时空余，第四天留六个小时空余，到了第五天，甚至可以不安排任务，这样你会有充足的时间来应付一些突发情况。

2.在工作中正确的沟通方式是怎的，如何正确地提问以及如何看待技术争论？

    （1）沟通：

      在工作中，当你有需求需要与他人建立有效沟通的时候，你可能认为面对面沟通是最正确最高效，其实有些时候并不是，或许他在写代码，你过去一打断，他紧张的思路就断掉了，这个人由于你的打断会浪费掉很多额外的时间，而这个时候你与他沟通需要讨论一个方案，而这个被打断的人往往会由于没有准备无法在短时间内的沟通得到一个良好的结果。

     假如对应到计算机领域里说，一个cpu在处理某些操作的时候又来了一个事件，这个时候我们可能说创建一个异步队列，把这些事件放入队列中，等cpu空闲的时候再来处理队列中的事件。

     参考这种思路，我们换一种方式和别人沟通，比如发个邮件或者微信等别人空闲的时候再来处理这个事项会不会更好一点呢?同时记得一点，尽量一条信息把你所要表达的都归纳起来，使得文字让更加精炼有效，特别是你要问别人问题的时候。

     对于这种异步沟通，通常都是书面的形式，当出现了问题的时候，就可以去寻找事情根源，而不是互相的推锅，不管是产品还是技术的错，都有根可寻，从而使得双方在决策的时候更加谨慎，避免问题的出现。

    （2）提问：

     关于提问，有时候发消息给公司的大牛得不到回复，你会想是不是大牛不愿意搭理小白呀，其实是要做到正确的提问，首先要做到的就是上面所说的一句话表达清楚，不要直接复制一大套代码上去，问bug在哪里呀?要精炼自己的问题，使得为你解决问题的人能够使用更低成本来理解你所要表达的意思，这样别人才更有可能去帮助你。

     （3）技术争论：

     有时候，经常会看见一些前端界的撕逼，比如react和vue哪个跟好呀?导致一些小白使其很迷茫，甚至于会跟风去批判另一种自己根本没有用过的技术，这样也是不可取的。实际上，撕逼的双方，他们之所以会有不同的观点，他们所在的技术团队，背景，兴趣等方面会导致自己对某一种技术特别的好感,或者厌恶，而我们应该结合自身，站在客观的角度上去对待技术这个问题。

     就事论事的撕逼，也算是一种良性的争论和非常好的沟通方式，无论是撕逼双方还是旁观者都能够从对方身上学到一些东西。

     

 3.计算机基础（算法、操作系统、计算机网络等）和计算机的一些方法论（编程范式、设计模式等）对于前端工程师来说重要性如何，它们是如何影响我的工作的？

     这个问题可能因自身原因总结的不是很好，关于计算机基础还是有一定必要掌握的，这样才能成长为一名好的工程师，而非单是某一领域的技术开发人；而编程范式设计模式，更是能提高你对于编程的思想，写出高质量的代码利于维护。

4.如何看待前端界日新月异的技术？当我们在学习新技术的时候，我们在学什么?

     前端技术更新很快，比如angular刚学完，就出来react，还没了解又出来vue，如何对待?

     比如说这个时候学完angular，我们可能很久不用，API都快忘光了，但双向绑定的思想你肯定不会忘记，我们学完react，你有可能会忘记一些语法，但你肯定不会把组件化的思想忘掉，所以说，当我们在学一个框架或者一个技术的时候，往往它的API或一些具体的方法都是表面上的东西，我们真正要学的是它所要传达出的思想，是它提出来的对某些问题的思路。

5.为什么要编写优雅的代码？

     有些人会认为在运算符两边多加两个空格是非常麻烦的事情，或者是认为实现同样的效果，为什么要把代码写的那么麻烦抽象，程序能跑不就行了吗?那为什么我们还要写注释写文档呢。

     代码是否优雅很难有个正确的答案，每个人的代码风格都不一样，就像一篇文章，文字写的好不好因每个人的审美都有不同，但段落是否整齐字迹是否工整都能影响阅读人的直观感受和理解能力，也就是我们所说的可读性。如果在一个团队里面，可以指定一个代码规范，这样别人一看就能理解你这个常量是要表达的什么意思，可以大幅度提升团队的效率。

     如何提高代码的优雅程度，可以去模仿一些大厂等的代码规范，只要记得一句话，代码是给人看的，不是给计算机看的，因为实现同一功能有千千万万的功能，应该使用的是让人最容易的理解的一种。

6. 为什么公司里的代码总是不那么完美，如何看待这一切？

     你进入了一家公司，会发现这家公司的代码太不完美了，都用的一些很老的技术，但要知道所有事情都是权衡下之后的结果，公司里有处理不完的业务和修不完的bug，而往往处于一边开车一边换轮胎的过程，也就是说保证业务推动的过程中，还要做系统的重构和技术的更新，那是不是公司技术太落后我就要走呢?其实不一定，可以把这当作一个机会，大家可以想一下，假若你去到一个很完美的公司，里面的技术都是最新的，这个时候你又能为团队做些什么呢?可能只是写业务，只是一个螺丝钉，当处于一家技术落后的公司，不应该想着逃跑，换个角度来想，怎么能让公司进步?这是个问题，如何去引进最新的技术，把组件模块化，或系统的重构等，当你真正去做了这些事情之后，你自己本身的技术水平也会得到极大的提高，同时我想你也不会仅仅是团队的一颗螺丝钉了。

7.影响力对于前端工程师来说是否重要，为什么以及如何提升影响力？

     前段时间，有人做了一个国内排名，排名依据是根据这个人的关注数量，有些人就说不科学，难道说关注数量多就代表他技术特别高吗?这话说对了一半，关注的人多不一定说明他的技术特别高，关注的人少也不能说明这个人的技术水平低，但关注量本身是反映了这个人影响力的大小，有这样一句话，影响力的大小决定了话语权的大小，这可能对一件事情的成败是非常重要的，在公司里，一个人的影响力由职位层级来决定，其次才是长期以来的口碑，如果没有话语权的话，很可能你想做一件你认为正确的事情，结果压根不会有机会给你去做，在社区推广框架，本身框架是很优秀的，但缺少话语权，也根本没有人去用。所以社区的影响力能决定你把一件正确的事情放大多少倍出去，而这种能力能争取一定要争取。

     一个人有影响力的话，是从来不愁工作的，这个时候你往往成为一种稀缺品。

     那么如何提高影响力呢?可以在一些技术问答社区用心回答一些问题，或者在掘金知乎写文章，多参与一些线下的技术沙龙，有机会的成为技术分享的嘉宾等等；而有些人会说，我目前的技术还不行，等我技术做到一定的水平之后再去提高影响力，这种想法其实不但正确，因为影响力的提升是长期日积月累的过程而不是一触即发的，所以现在就可以开始。

8. 前端工程师是否应该了解其它技术？

     有人会问，我学前端要掌握后端技术吗?要学运维吗等等?单看前端工程师这个title，工程师是做工程的，不需要你去把所有的技术都去参透，但至少你要涉及到了解到一些基础的，别人说什么你至少知道是个什么东西，这样在工作中才可以更好的交流合作，如果前端只懂前端，后端只懂后端，那么最终写出来的业务肯定不是最好的，写自己领域的代码的时候应该从全局来考虑，怎么做更加合适，这样才是最好的结果。

     除了前端技术的深度之外，同时要扩大其它领域的广度。