《web全栈工程师的自我修养》阅读笔记

        在买之前以为这本书是教你怎么去做一个web全栈工程师，以及介绍需要掌握的哪些技术的书，然而看的过程中才发现，是一本方法论的书。读起来的感觉有点像红衣教主的《我的互联网方法论》，以一些自己的经历和感悟来阐述web全栈工程师需要具备哪些素质，而不仅仅是需要哪些技术。这算是我买的书中看的最快的一本书。

        

        在阅读这本书之前，我对全栈工程师的理解还停留在node阶段，随着node在服务端的风生水起，有一段时间会认为使用nodejs作为服务端开发，前后端统一使用js开发，便是所谓的全栈开发，比较流行的技术栈当属 MEAN 和 Meteor 了。然而，很多创业公司，没有专职的前端，大部分由RD同时完成前端和后端代码的编写，那是不是也可以称之为全栈工程师了呢？

        

        本书对全栈工程师的理解是 ： 除了在一个专精知识领域有深入的研究之外，需要知识广博和解决问题能力强。抽象出来就是 1、一专多长 ； 2、解决问题能力强(而非炫技) 。 全栈工程师的成长路线，一定是先精后广，触类旁通。如果一开始就想直接追求全栈，只会导致杂而不精，没有核心竞争力。全栈工程师还有一个特点是对产品业务，用户体验都保持较高的敏感度。而不仅仅关心自己那部分技术实现。

 

        全栈眼中的http这一章分别从前端视角和后端视角来分析前后端所关注的侧重点。前端可以通过抓包工具或者chrome devtools 查看每个请求，同域下的资源请求数量等来找出优化点，更关注的是一个页面的请求数，资源大小等直接影响页面展现速度的因素。而后端则更关注如何更快速的响应请求，以及减小服务器压力。并给出了需要前后端协同工作的一种http优化方案，bigpipe。

        

        web发展到今天，岗位越来越细分。开始数据库设计是由相关的RD完成，现在有专门的DBA来操作和管理数据库，而前端也有些公司也分为UI工程师(也叫css重构工程师)，JS工程师。细分之后的有点的职业门槛更低，长期在某一个方向上可能会有更深的造诣，然而缺点也很明显，每个人都被圈定在某个title限定的圈子里，接触的知识面变窄，接近的上下游之间，存在一部分灰色地带，职责不是很好划分，项目沟通成本增加。

 

        向移动转型。不管是大公司，还是创业公司，向移动端转型是一个必然的趋势。而在转型的过程中，对前端是有巨大的机会和挑战。我们都知道，H5页面一直在体验上被吐槽，webview加载和渲染性能远远赶不上原生应用，然而，H5的作为web 应用，天然具备的灵活性又是原生应用无法做到的，为了兼具两种应用的优势，Hybrid 便诞生了，对于混合应用，必须要求对原生应用有一定的了解，Scheme协议，H5资源离线化，native 和 h5 之间的通信，才能帮助前端工程师更好和原生应用开发者合作。

 

        设计原则：不管是什么方向的开发，有些设计原则是共通的。比如 DRY 原则：don't repeat yourself。 意思是在一个系统中，对于任何数据或者变量，都应该有且只有一个地方配置，其余的地方只是引用这里的数据。然而事实上，很多时候，变量定义的时候可能只有一个地方使用，随着业务的发展和功能的迭代，在其他地方出现了一次引用，是不是每次遇到一个都需要抽离一次呢？其实也不然，代码重构通用的法则是三次法则： 允许复制代码一次，当相同的代码片段同时出现三次以上，就需要将其提取出来作为公共模块。

 

        前面提到的很多是具体的某种场景下的具体方法论，当然还有很多没有列出来。实际上本书还提到了很多非技术的软素质。比如说如何进行汇报。如何像上级汇报，如何跟你的上下游合作人员进行沟通。要做自己的产品的用户。想要成为全栈工程师最重要并不是会所有的技术栈，而是需要具备全栈思维，也意味着需要承担更多的责任，包括了解上下游的工作内容和知识，再考虑设计方案的时候也能考虑到上下游之间的影响，具有跨团队的推动力和影响力。

 

 

        

        

转载于:https://www.cnblogs.com/albin-gecker/p/5840512.html