《Web全栈工程师的自我修养》-白红宇

《Web全栈工程师的自我修养》

阅读量：5788 次

发布时间：2019-06-18

本文共 4962 字，大约阅读时间需要 16 分钟。

1. 什么是全栈工程师

Full-Stack Engineer

Facaebook只招全栈工程师？

Web开发流程

产品经理-->交互设计-->视觉设计-->开发（前端、后端）-->测试-->发布

流水线的优势

“各司其职”的弊端

工程师职责不清导致效率低

工程师缺乏主人感导致产品质量差

工程师缺乏全局的视野影响个人成长

更多角色导致项目效率低下

全栈工程师登上舞台

技术的发展

MEAN(MongoDB-Express-AngularJs-Node.js)

提供PaaS服务的平台越来越多

全栈工程师的发展背景

一专多长

解决问题，而不是醉心技术

2. 如何成为全栈工程师

先精后广，一专多长

围绕商业目标

关注用户体验

每一个糟糕的体验背后都蕴含着商机

用户是谁

大巧若拙

做自己会用的产品

3. 从学生到工程师

校园招聘

获得面试机会

实习

4. 野生程序员的故事

遭遇“野生程序员”

压缩源码和图片

选择合适的图片格式

合并静态资源

开启服务器端的Gzip压缩

使用CDN

延长静态资源缓存时间

把CSS放在页面头部，把JavaScript放在页面底部

Web性能优化分为服务器端和浏览器端两个方面 - 页面加载速度（Page Speed）的优化 - 页面渲染性能（Page Performance）的优化。

什么是“野生程序员”

所谓“野生程序员”，就是没有计算机基础知识和相关教育经历，靠着对计算机开发的兴趣进入这个行业，虽然知识面比较广，但是各方面都一知半解的开发者。

小公司有很多野生程序员

大公司还是创业公司

大公司能给您的

较小的风险

技术最佳实践

垂直专精的技能

服务海量用户的经验

软技能

人脉

心态

5. 工程师事业指南

技术 *成长* 声望
那个什么都懂的家伙

积累作品集

重视作品集

工程师的作品集

突出重点

6. 全栈工程师眼中的HTTP

HTTP简介

超文本传输协议（ HyperText Transfer Protocol， HTTP） - OSI模型（7层） - 应用层（最上层）：HTTP、HTTPS、FTP、TELNET、SSH、SMTP、POP3

关于HTTP版本

HTTP/1.1 1999年

HTTP/2 2015年
例子

前端视角

尽量减少同一域下的HTTP请求数

尽量减少每一个资源的体积

后台视角

提高服务器的请求处理能力

DDoS攻击

Distributed Denial of Service：分布式拒绝服务

BigPipe

7. 高性能的网站的关键：缓存

什么是缓存

服务器缓存

基本的数据库查询缓存

扩展数据库缓存：memcached

再加一层文件缓存

静态化

浏览器缓存

第一种：Expires

Expires: Thu, 15 Apr 2020 20:00:00 GMT

第二种：Last-Modified

Last-Modified: Tue, 01 Mar 2015 03:42:36 GMT

If-Modified-Since: Tue, 01 Mar 2015 03:42:36 GMT
Restful Web API

表征性状态传输（ Representational State Transfer， REST）

HTTP 1.1加入的Cache-Control

下面是推荐的浏览器缓存设置最佳实践
- 对于动态生成的HTML页面使用HTTPS头： Cache-Control: nocache
- 对于静态HTML页面使用HTTPS头： Last-Modified
- 其他所有的文件类型都设置Expires头，并且在文件内容有所修改的时候修改Query String
浏览器缓存的现实世界

结论

QQ空间静态资源在浏览器端使用的缓存策略

对于动态生成的HTML页面使用HTTPS头： Cache-Control: nocache

对于静态HTML页面使用HTTPS头： Last-Modified

其他所有的文件类型都设置Cache-Control头，并且在文件内容有所修改的时候修改文件名

8. 大前端

前端工程师

知识体系

易于上手，难于精通

框架vs库

岗位细分

UI工程师 vs 前端工程师

App UI工程师

9. 向移动端转型

为什么向移动端转型

一个转型故事

行动重于计划

一定要是自己的产品的用户

世界上成功的软件都不是完美的软件，而是在合适的时间发布的、刚刚够用的产品。如果它能活下来，在后面的版本中，它才有机会越来越好。

客户需求只有在实际使用中才能辨明，再多的前期调研也只能发现客户认为他们想要什么，而不是客户实际上想要什么。因此在不了解客户真实需求的情况下，只会多做多错。 --《精益创业》

有哪些方向

混合模式App5

WebView与原生代码通信

混合模式App开发框架

持续集成

Continuous integration，CI

版本控制

Version Control System，VCS

SVN

Apache Subversion（SVN）

Git

使用Git部署代码

版本控制最佳实践

鼓励频繁地提交

确定分支流程

定义主干原则，并且坚守它

不要把逻辑的修改和代码格式化操作混在一起

不相干的代码分开提交

保持工作代码库的“干净”

GitHub工作流

包管理

一个程序只做一件事，并做好

Node.js

npm：npm is not an acronym
Bower

其他软件包管理器

Node：npm

PHP：Compose

Ruby：gem

Pbjective-C：CocoaPods

关于版本号

根据semver的规范，版本号用小数点分隔为三个数字。比如v3.2.1中3是主要版本号，2是次要版本号，1是补丁。 - 主要版本号：有API变更导致不兼容旧版本的时候使用。 - 次要版本号：新增功能，但是向前兼容的情况下使用。 - 补丁：修复向前兼容的bug时使用。

构建工具

首先需要良好架构

有合适的分离粒度

最小知识原则

DRY（Don't Repeat Yourself），不要重复您自己

最小化预先设计，只设计必需的内容

通过良好的层级，让文件易于找到

在代码层面，有一致且可执行的命名规则
Make

依赖关系

Grunt和Gulp

Grunt - 配置项过多。每一个插件的使用都需要配置输入项和输出项，使用比较繁琐。 - 子任务间的协作基于文件。基于文件的坏处是，后一个子任务必须等前一个子任务的过程完全结束，才能开始它的流程，这样比较慢。而且磁盘读写速度远远慢于内存读写。

虽然Grunt有先发优势，但是由于它有几个痛点没有很好地解决，所以又诞生了Gulp。

11. 理解编程语言

编程语言是什么

故事接龙

语言的进化

首选语言之争

JavaScript并不总是次优语言

语言的性能

语言的设计理念

全栈工程师最佳实践

通用用途语言 vs 特定领域语言

框架和库拓展了语言

脚本语言的优势

脚本语言不需要编译

脚本语言常常不用关心清理内存

脚本语言常常会针对特定领域优化

脚本语言常常是动态类型语言

脚本语言的抽象层常常更高

脚本语言常常有包管理器

12. 全栈游乐场

VPS

虚拟专用服务器（Virtual Private Server，VPS）

实体主机、VPS、虚拟主机

对于网站的全貌有所了解

初始化。Linode提供一键安装操作系统，等待几分钟操作系统就安装完成了。

安装最新的Apache（或者其他服务器）。启用Apache的rewrite等模块，WordPress的URL重写会用到。

安装MySQL数据库，配置WordPress的数据连接。

配置域名和路由（包括访问路由配置、日志配置、网站域名和别名等）、启动服务器、查看资源利用，等等。

当然，也不要忘了安全防护和设置自动备份。
时间就是金钱

部署自己的环境

学习Linux

理解HTTP

实践

VPS选择

关注服务器安全

新建一个普通用户，以后都不要用root登录了。

使用SSH的名值对的登录方法，禁用用户名和密码的登录方法。

禁用root账户通过SSH登录。

安装一个防火墙。

安装Fail2Ban，杜绝字典攻击。
操作系统选择

CentOs、Debian、Ubuntu、Fedora

域名解析

云服务器

13. 软件设计方法

设计模式

关注点 - 高效编写代码 - 高可复用性 - 抽象带来的可读性

创建型模式

创建型模式，就是用来创建对象的模式，它对实例化的过程进行了抽象。创建型模式帮助一个系统独立于如何创建、组合和表示它的那些对象。也可以理解为，创建型模式将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关心创建对象过程中的逻辑。

结构型模式

结构型模式主要解决类、对象、模块之间的耦合关系。

行为型模式

行为型模式为设计模式的最后一种类型，用来识别对象之间的常用交流模式并加以实现。如此，可在进行这些交流活动时增强弹性。

架构模式

关注点 - 多个职位（比如后台开发和前端开发）可以平行工作同时进行。 - 构建一个软件系统的多种技术。

MVC模式

架构模式之王

设计原则

DRY

三次法则（rule of three）是代码重构的一条经验法则。

惯例优于设置

KISS原则

KISS（Keep it simple,stupid）：软件设计当中应该注重简约的原则。

优点

较简单的系统更容易构造、运行和维护。

较简单的解决方法总是更具弹性、柔性。

较简单的系统更便宜。

较简单的系统更容易实现、更快地获得回报。

较简单的方法更讨用户的欢心。

较简单的系统更容易分阶段地执行。

较简单的系统更容易被理解。
最少知道原则

松耦合原则

14. 高效工程师

为什么需要高效

一个人的效能会影响整个团队的效能，所以每个人的高效都很重要。

提速100倍

1.阅读英文资料

英文的技术资料更多

StackOverflow有完善的鼓励机制

Google的搜索能力非常强

英语世界的语言风格比较严谨

2.时间管理四象限

一：既紧急又重要（立即执行）

二：紧急不重要（请他人代劳）

三：重要不紧急（制定计划）

四：不紧急不重要（对他说不）
3.消除重复工作

4.给自己留出不被打扰的时间

5.番茄工作法

6.跨界思考

7.纸上头脑风暴

8.使用版本控制和构建系统

9.加班是一种文化？

15. 学习设计

科学家和工程师

细分不是最好的解决方案

设计基础

亲密：关系亲密的元素要放在一起，关系疏远的元素则要分开。位置的亲密性直接表现出意义的相关性。

对齐：左对齐、右对齐、上对齐、下对齐。斜线对齐比较简单，居中对齐很难处理，新手不要尝试。

重复：视觉上使用重复的图形和元素、线条和颜色等。比如QQ空间重复使用的黄色跟黑色、微信的绿色、京东的红色等。

对比：如果两个元素（的大小或者颜色）不一样，就让它完全不一样，产生视觉冲击力。
设计工具

Axure、Sketch、Quartz Composer、代码

Facebook的品牌设计故事

16. 全栈思维

有兴趣就够了吗

您有没有想着把您的产品和您的名字联系起来

学一点管理

没有在最开始做出合理的时间评估

没有根据人员的强项来安排任务

没有唤起他们对项目成功的渴望

缺乏沟通
好的管理者能让平凡的员工做不平凡的事

《卓有成效的管理者》5个核心思维习惯 - 有效的管理者知道他们的时间用在什么地方。 - 有效的管理者重视对外界的贡献。 - 有效的管理者善于利用长处，包括自己的长处、上司的长处、同事的长处和下属的长处。 - 有效的管理者集中精力于少数重要的领域，在这少数重要的领域中，如果能有优秀的绩效就可以产生卓越的成果。 - 最后，有效的管理者必须善于做有效的决策。

根据员工特质来授权