《Web全棧工程師的自我修養》

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個核心思惟習慣 - 有效的管理者知道他們的時間用在什麼地方。 - 有效的管理者重視對外界的貢獻。 - 有效的管理者善於利用長處，包括本身的長處、上司的長處、同事的長處和下屬的長處。 - 有效的管理者集中精力於少數重要的領域，在這少數重要的領域中，若是能有優秀的績效就能夠產生卓越的成果。 - 最後，有效的管理者必須善於作有效的決策。

根據員工特質來受權

溝通：被忽視的競爭力

溝通是軟技能

針對目標聽衆

有方法

表達本身的想法

示例：談談PPT

• 不要有太多文字
• 設定進度
• 對待錯誤：放鬆
• 有條件的話，錄像並對比提升

  內向性格的競爭力