「Web全栈工程师的自我修养」读后感

无意中搜到的书，本身就在做前端的我，看到了Web 栈工程师和作者是腾讯大佬的关键字眼，啪的一下就点进去了。看完之后也确实学到了一些东西，尤其是未来——中短期——的职业规划方面的。

作者相关

作者，余果，的博客地址：https://yuguo.us/，不过最后更新的时间已经是一年前（2020-02-06）了，并且在下面特别标注之后都会转移到公众号上继续发表:

我写字的地方迁移到公众号啦~欢迎关注我的公众号：余果专栏

可能博客已经被放置了。

目前了解的是，作者 2010 年毕业于，2010-2019 在腾讯 ISUX，负责过 QQ 音乐、QQ 空间、腾讯微云的产品设计。2019 年后加入「房极客」，担任产品设计总监，再后面就没有了。

本书写于 2015 年，即作者升职为 UI 开发组 leader 后一年，个人感觉对处于 1-5 年期间的初中级开发都有不小的启发。

内容简介

这是一本比较偏向杂谈类的工具书，前半部分更偏向杂谈类，如全栈工程师简述，个人发展方向，自身定位目标等。后半段更偏向工具书，浅谈了如 HTTP、缓存、版本控制、管理包之类的技术上的点。具体内容难以一笔代之，不妨去看一下这本书的目录，以此获得更加明确的定义，又或是可以搜索一下 ”Web 全栈工程师的自我修养“ 加上 “笔记” 作为关键字，也有很多的内容提要和浓缩。我想更多地将内容放在自己的感悟方面，故此书的细节在此就不一一赘述。

感悟

在谈及感悟之前，我先简单的提一下自己现在的背景：

  1. 本科计算机科学
  2. 最初的一年在一家小公司搬了一年砖，做了 CRUD，也写了 H5，感觉都写了一些，也么都没学好。
  3. 跳到了现在的公司，到目前为止可以说是专写 React 了，第一个项目已经上线交给了维护，目前在做第二个项目。

在看最近招前端的要求上，除了基础的 HTML, CSS, JavaScript, 三大框架之一外，或多或少的都会带上会一门后端语言，比较多的有列 Python, Java，其他的 Ruby 和 Node 也经常会看到。所以觉得自己未来的职业发展，如果还在技术上走，应该还是会往全栈方面发展。

如何成为全栈工程师

书中提到的坑，我正好踩过了，就比如 初学者贪图大而全，反而样样都不精。最初的的一年工作经验就是如此，因为规模较小，前端后端都有在做，但是为了完成业务需求，后端大多都是 CV 前辈写好的模块，对于控制器、注解都没有深入的了解，遇到问题或是百度或是 Stack Overflow，最后解决不了，再去找前辈。很多时候连知其然都没有做到，就更别说知其所以然了。

前端方面也基本以写 HTML 为主，嵌套一些 JSP 函数。做了一段不算短的时间后，发现每天重复劳动太多，自己没有获得足够的成长，再加上公司运营不是非常好，最终选择了跳槽。

目前也是处在书中说道的一专多长 的阶段。以前端 React 为主，最基础的功能方面，如 React-Router, Redux 是一个必须要用的，目前还处在知其然的状态；对于模块组件化，因为踩过坑摔得非常惨，目前也是有了比较强的意识，处在一个知其所以然的过程阶段上。目前的计划就是快速的过一遍基础：H5C3JS，再将 Node 上手，从而完成向全栈工程师开发的转变。

在这个大前提之下，也要进行思维的转变。

这也是书中提到的解决问题的方面。

目前与我最为相关的三个点是：

  • 关注商业目标

    这一点应当说非常简单明了了，之前都是以完成项目为目的，至于为什么做这个项目，这个项目的意义是什么，大多都不甚了解。如果想要完成从搬砖到画蓝图的转变，更多地了解”Why”是不可避免的。

  • 关注用户体验

    反思自己，之前也因为觉得某些功能看起来非常的酷炫，所以就加到了 UI 库中。至于用户具体需要不需要，新加入的功能和项目其他的组件嵌入的是不是和谐，甚至是跨端的效果都没有进行细致的了解。

    我自己都不是我开发的产品的用户，我怎么会知道用户体验感如何呢？

  • 项目工程化

    这个还是要从节能提效上思考，也节省自己的时间，也节省项目开发的时间。

    这一点也是还要继续了解的方面，最基础的eslint是已经被大佬设置好了，至于更加抽象方面的，例如说流程，如：

    • Agile

      目前项目走的是Agile，但是总觉得哪里不对，或许是我还没有更加彻底的了解它。

    • 代码规范

      并没有这种东西，我自己刚开始的时候使用了prettier插件，但是后面发现别人的代码没有什么风格规范，每一次ctrl+alt+f都会改动几乎整个文件导致对方直接 revoke 了 pull request，搞得我现在也不太敢用了。

      举个例子，以下的组件看起来我就很想ctrl+alt+f:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      render() {
      	return(
      		<div className="test">
      			<SomeComponent abc="abc",
      		efg="efg"
      	>
      		{variable ? <div className="test2">
      		{someList.map((var, index) => {
      			// logics here
      		})}
      			</div>
      		}
      		</div>
      	)
      }

      这种缩进本身就造成了非常大的困扰，光看efg下面的>，很难第一时间就判断出来这属于哪个标签。其次，return函数里面充满了各种各样的三元表达，也没有备注，也没有正确的缩进，这对理解整个return的逻辑也造成非常大的干扰。

      设立统一的代码规范，并且所有组员都去遵守这个代码规范，对长期的开发、维护都是大有助力的一件事情。

    • 版本控制，虽然用了git，我觉得我们没有用对git。

    • Code Review，聊胜于无，项目里面几乎没有，这也导致我在看别人代码的时候非常吃力，毕竟没有遵从什么规范。

    • UAT 环境，有的，但是我对部署更新完全插不上手，这个我 TL 都捏在手里，也是我一定要补足的地方。

技术方面的提升

更多的关注更高层面的目标，并不代表着技术方面就能丢了。毕竟这个行业更新换代太快了，我前年刚开始使用React的时候，当时还是以class based component为主，去年就已经开始替换成hooks，仿佛不会hooks就不会React。去年十月份v17也终于推了出来，万幸的是v17并没有什么主要更新，这也让我喘了一口气。

只是，技术方面的追求不能盲目，换言之，还是需要先做到一专多长 ，再触类旁通。

不过有两个比较急于提上日程的方面还是要记一下的：

  • webpack
  • babel

一个是打包器，一个是转译器，这两个不会的话，永远只能CRA，而没有办法对打包后的东西进行优化。