《Web全棧工程師的自我修養》濃縮筆記（下）

《Web全棧工程師的自我修養》濃縮筆記（下）

2017.03.30 17:23 7912瀏覽

 

6、大前端

1. 易於上手、難於精通

不一樣於某些「難於上手、難於精通」的職業，前端這一崗位就像暴雪公司的遊戲設計同樣：「易於上手、難於精通 」。

前端技術的「易於上手」致使它在某些技術人員那裏不受待見。他們認爲HTML與CSS根本都不是程序語言，甚至認爲JavaScript是一種功能不全的玩具型語言。因此直到我幾年前畢業的時候，大學都沒有前端相關的課程和專業。而市場對前端工程師的需求又很大，學校的輸出跟市場的要求沒有對接上，因此每每出現學生找不到工做，公司又招不到人的現狀。

2. 框架 VS 庫

一個庫是一系列對象、方法等代碼，您的應用程序能夠把這個庫 「連接 」進來。這個庫起到了重用代碼的做用，爲您省下了重寫這部分代碼的工做量。

而一個框架是一個軟件系統中可重用的一部分。它可能包含子程序、庫、膠水語言、圖片等一些「資源」，這些資源一塊兒組成了軟件項目。框架不像庫，可能包含多種語言，某些功能可能經過API的方式讓主程序調用。因此框架是一個更加靈活和寬鬆的名詞，在具體的情景中，它可能指一個庫、多個庫、腳本代碼，或者多個可單獨運行的子程序的集合。

在出現一些熱門框架時，建議開發者先去了解框架的建立初衷，合理使用，而不是盲目收集。

7、向移動端轉型

1. 爲何向移動端轉型

技術是服務於市場的，在市場發生變化的時候，若是開發者不能順應變化，就有被淘汰的風險，畢竟不少開發者所服務的這個崗位誕生都不到十年，消亡可能也會在十年以內發生。對於目標是全棧工程師的人來講，技術能力更是多多益善。

2. 必定要是本身的產品的用戶

風投在評估一個創業項目是否會成功的時候，有一個指標就是創始人是不是本身產品的目標用戶。若是不是，那產品頗有可能會失敗。

在大公司，一些工程師士氣低迷每每就是這個緣由，成功來得很慢，失敗也是。由於你們懼怕失敗，因此想把產品調整得天衣無縫才發佈。可是世界上成功的軟件都不是完美的軟件，而是在合適的時間發佈的、剛剛夠用的產品。若是它能活下來，在後面的版本中，它纔有機會愈來愈好。

《精益創業 》中有一句話：「客戶需求只有在實際使用中才能辨明，再多的前期調研也只能發現客戶認爲他們想要什麼，而不是客戶實際上想要什麼。所以在不瞭解客戶真實需求的狀況下，只會多作多錯。」

3. 有哪些方向

iOS原生App
iOS原生App開發的技能樹相對比較新，須要學習Objective C這門語言，以及Xcode的一些操做方法——主要是sto ryboard，以及各類官方類庫的使用方法。它帶來的收益也很高，對於獨立開發。AppStore仍然是地球上最好的軟件市場，對於團隊，在將來5年都不會缺乏對iOS開發者的需求。

Android原生App
使用Java編程，若是有Java編程經驗，Android原生App是最好的選擇，由於用戶量和用戶比例都在穩定增加。

WindowPhone原生App
如今用戶量還不多，除此以外也不知道如何評論… …

WebApp
技術是最簡單的，傳統前端開發的技能樹能夠無縫移植，包括 HTML5/CSS3/JavaScript等。應用場景包括瀏覽器中打開的WebApp、微信中的頁面，或者混合模式App。WebApp的好處是自然無縫移植到全部支持Web標準的平臺——甚至Kindle。

此外，對於中國開發者來講，微信公衆號也是一個巨大的平臺。之因此提到微信，是由於微信這個平臺在中國的覆蓋率幾乎跟Android和iOS加在一塊兒同樣多，並且微信也有比較成熟的支付方式。

4. 混合模式App

混合模式App（Hybrid App）同時使用Web技術與原生程序語言開發，經過應用商店區分移動操做系統分發，須要用戶安裝使用。就像混合動力汽車使用汽油和電力兩種動力同樣，混合模式App使用兩種技術製造。

混合模式App對於用戶來講跟其餘App同樣，須要去蘋果AppStore或者Android應用商店下載。因此App須要對應的操做系統平臺的技術，好比Objective C或者Java製做總體框架。App啓動後，它的所有界面或者部分界面中，使用網絡視圖（WebView）技術來實現。WebView能加載顯示網頁，能夠將其視爲一個瀏覽器，它通常使用WebKit渲染引擎加載顯示網頁。

混合模式App一些經常使用的優化方法以下：

• 把WebView的部分或者全部資源打包在App中
  缺點：發佈包體積會變大
• 把須要加載的資源設置好預先加載
  缺點：第一次訪問的時候可能由於沒有預加載資源而致使等待的時間比較長
• 使用HTML5 Manifest技術實現資源緩存
• 不要把整個App的主要邏輯都是用WebView開實現
  要結合原生技術和WebView各自的優缺點，根據不一樣的場景選擇合適的技術。原生技術的優勢在於能很好地操做 App存儲數據；實現頁面間切換、高性能動畫、大量數據的界面（好比能夠無限滾動的圖片流）。WebView的優勢在於開發快、技術簡單；前端開發者可以利用已有的CSS3和JavaScript知識；頁面可以從服務器端更新；可以分享到社交平臺；在多個平臺上共用等。
• 設計的更像一個App，而不是一個網頁

5. 混合模式App開發框架

PhoneGap經過對各個平臺底層功能進行封裝和抽象，而後經過JavaScript暴露出一致的API，讓開發者能夠經過JavaScript編寫跨平臺的原生APP。

雖然看上去「一次編寫、處處運行」的願景很美，可是PhoneGap有這樣幾個缺點。

• PhoneGap的編程語言實際上是JavaScript，這對於非前端工做者來講，學習起來和學習原生的Objective C或Java編程語言難度差很少，想精通JavaScript，至關不易。
• PhoneGap編譯的App包大小比通常的會大不少。
• PhoneGap的目標是方便地建立跨平臺應用，可是蘋果和Google都發布了本身的人機交互指南。有些狀況下，iOS程序和Android程序有着不一樣的交互原則。使用PhoneGap就意味着您的程序在UI和交互上，既不像原生iOS程序，又不像原生Android程序。
• 動畫性能不佳。JavaScript終究沒法和原生程序比運行效率，當製做一些動畫效果，或者有大量數據的長頁面的時候，就表現得很明顯。

固然，PhoneGap的優點也很明顯 。

8、持續集成

1.版本控制

SVN
集中式代碼管理的核心是服務器，全部開發者在開始新一天的工做以前必須從服務器獲取代碼，而後開發，最後解決衝突，提交。全部的版本信息都放在服務器上。若是脫離了服務器，開發者基本上能夠說是沒法工做的。

在企業內部，使用SVN沒有什麼問題，服務器壓力和內部帶寬都可以承受全部員工一塊兒操做SVN。可是在開源世界，這種架構方法就不行了，著名的開源軟件的開發人數太多了，所以誕生了Git。

Git
Git是一個分佈式版本控制軟件，是天才工程師、Linux內核開發者Linus開發，目的是更好地管理Linux內核源碼。其初版於2005年發佈，它與SVN最大的不一樣之處就是基於分佈式的理念。

2. 版本控制最佳實踐

鼓勵頻繁的提交
SVN踐是頻繁地提交，而不要等到代碼沒問題了再一次性提交。對於可能損壞主幹原則的代碼，不要直接提交到主幹，而是建立一個分支，在分支中頻繁提交。

肯定分支流程
基本上全部的特性和較大的bug修復都應該使用分支來修改。

定義主幹原則，而且堅守它
咱們團隊的主幹原則是「主幹對應的代碼必須是能夠發佈而且不會產生bug的」，若是不能保證新增的或者修改的代碼符合這一原則，就在分支提交代碼。任何人破壞這一原則引發bug，就請你們吃飯。

不要把邏輯的修改和代碼格式化操做混在一塊兒
若是您作了一些代碼格式化的操做，就單獨提交此次修改。好比您去掉了代碼中全部的空行，那就單獨提交一個 commit，而後再作一些邏輯的修改，再提交。這樣能夠避免「天哪，全部的東西都不同了」，出現問題以後更容易追溯。

不相干的代碼分開提交
也就是說不要在一次提交裏修復兩個bug。

保持工做代碼庫的「乾淨」
若是您有文件不想也不須要提交，就加入到忽略列表（ignorelist） 。不須要提交的文件包括編譯後文件、配置文件和第三方依賴等。這樣的好處是，您每次打開SVN提交界面，若是沒有修改過任何代碼，就會看見一個空的列表 ，若是修改過代碼，就顯示修改過的代碼。這能提醒您不要漏掉任何須要提交的文件。

3. 包管理

爲何須要包管理？

在咱們平常工做編寫的軟件中，可能有絕大部分代碼都不是咱們本身輸入的。咱們「依賴」一些第三方的框架或者庫。在Web前端開發中，咱們依賴各類框架、庫、靜態資源等；在PHP開發中，咱們依賴各類框架、庫；在iOS App開發中，咱們依賴各類庫、模塊、資源等。在複雜一點的依賴環境中，您所引入的第三方庫也依賴其餘的「第四方庫」 「第五方庫」… …如何保證互相之間都不會出現衝突很重要。

如何讓咱們依賴的資源有條不紊地在一個地方進行管理和更新，而不用重複「搜索、下載、移動」這一系列繁瑣的手工操做？這就要引入「包管理」。

Node.js
Node.js的包管理器npm應該是世界上最有名的包管理器。若是沒有npm，Node不會有今天的普及度。npm收集了大量優秀的Node.js代碼包，而後這些庫吸引更多開發者進入Node.js開發的行列，反過來又促成了npm的繁榮，就像雞生蛋，蛋生雞同樣。

npm如何引入依賴組件？

第一種是在本身項目的根目錄裏寫一個package.json。這是一個json對象，在其中的dependencies或者devDependencies值列出所須要的模塊和版本，而後用命令行切換到項目根目錄，運行npminstall。經過這種方法，其餘人在獲得您的代碼以後，僅須要一個package.json文件，就能夠簡單地使用npminstall命令來安裝所須要的全部依賴。模塊會所有下載到node_modules文件夾。

"dependencies": { "gulp-util": "2.2.14", "through2": "~0.4.1" },

由於node_modules文件夾裏全都是第三方代碼，其實是脫離於本身項目的代碼庫的。因此應該在.gitignore或者 SVN的忽略文件列表裏忽略掉node_modules整個文件夾，並且全部項目成員也不該該修改node_modules裏的任何東西，不然在未來npm安裝的時候可能會丟失您的修改。若是發現某個模塊有修改的必要，要向原做者提出issue。或者推送請求。

4. 構建工具

首先須要良好的架構

• 有合適的分離粒度
• 最小知識原則
  一個組件或者對象不該該知道其餘組件或者對象的內部實現細節。在QQ空間中，咱們的配色組件跟其餘組件是徹底分開的，兩者沒有依賴關係。一個組件或者對象不該該知道其餘組件或者對象的內部實現細節。在QQ空間中，咱們的配色組件跟其餘組件是徹底分開的，兩者沒有依賴關係。
• DRY（不要重複您本身）
  特殊的功能只能在一個組件中實現，在其餘的組件中不該該有副本。這是咱們的一個嚴格要求。
• 最小化預先設計，只設計必須的內容
• 經過良好的層級，讓文件易於找到
• 在代碼層面，有一致且可執行的命名規則
  從路徑名到文件名都有一致的前綴、後綴、版本規則。整個團隊有一致的命名風格和註釋風格。

Make和依賴關係
Make是一個經典的構建工具，現代不少構建工具（好比Grunt、Gulp等）都參考了它的一些基本原則來設計。 Make的基本模型是：定義一個任務時首先聲明依賴關係，而後說明根據這些依賴調用哪些應用程序來生成目標文件。由於每一步都須要使用不一樣的應用程序調用不一樣的數據，因此這裏面須要設置依賴關係。

另外一方面，使用包管理工具能夠把項目須要用的第三方包，以及每個包的特定版本，都集中在一個配置文件中。此後，咱們經過一句命令，就能夠下載這些包到本地的開發環境。每一個軟件包都會涉及其餘的軟件包，軟件包里程序的運行須要有一個可執行的環境（要求有其餘的程序、庫等），軟件包依賴關係正是用來描述這種關係的。

因此， 「依賴關係」既屬於「包管理」，同時又屬於「構建工具」。

Grunt和Gulp
Make很強大，並且在全世界範圍內幾乎全部的計算機領域用了幾十年，它的穩定可靠通過了普遍驗證。不過從學習成本角度來講，它須要學習者具有一些Linux編程的基礎，難度較高。因此，Grunt和 Gulp誕生了，它們都是用 JavaScript來實現的構建工具。

Grunt引爆了前端架構工具的概念，獲得了普遍的應用。如今，Grunt的生態環境已經很是龐大，愈來愈多的開發者着手Grunt開發，爲它添磚加瓦。可是Grunt有幾個問題 。

• 配置項過多。每個插件的使用都須要配置輸入項和輸出項，使用比較繁瑣。
• 子任務間的協做基於文件。基於文件的壞處是，後一個子任務必須等前一個子任務的過程徹底結束，才能開始它的流程，這樣比較慢。並且磁盤讀寫速度遠遠慢於內存讀寫。

因此雖然Grunt有先發優點，可是因爲它有幾個痛點沒有很好地解決，因此又誕生了Gulp。

Gulp的意思是 「大口吸」 ，它最初的logo是一杯飲料，上面有一根吸管，很形象地跟它的宣傳語相呼應：「基於流的構建工具」 。與Grunt最大的不一樣就在於，Gulp基於 「流 」的理念。

Gulp基於Node.js的流的概念，因此前一個任務的輸出就是後一個任務的輸入。

從語法風格上來說，編寫任務的過程更像是 「編程 」，而不是 「編寫配置」 。Gulp經過對接前一個任務的輸入和後一個任務，就像一個管道，兩者能夠同時進行，不輸出在磁盤中，沒有多餘的中間產物，性能更加高效。

當前，Gulp的社區還遠不如Grunt成熟，有些功能的插件，Gulp可能就沒有。不過從我的偏好來看，我更傾向於Gulp，它的技術理念更好。

9、理解編程語言

1. 全棧工程師最佳實踐

通用用途語言 VS 特定領域語言
不少編程語言傾向於通用解決方案，而不是隻解決具體問題。這些語言都被設計爲能夠在任何領域使用，好比C、Java、Python和XML，它們被稱爲 「通用語言 」（General Purpose Language， GPL）。咱們能夠看到用 C編寫的全部類型的軟件，從遊戲到客戶端軟件，從服務器端軟件到手機端軟件。

與之相對應的，有些編程語言被設計爲特定領域專用，叫作 「特定領域語言 」 （DSL）。DSL的目的是解決特定領域的問題，而不是像GPL同樣能夠解決任意的軟件問題。DSL在計算機軟件開發中十分常見，好比前端開發中常見的HTML和CSS就是一種DSL，專用於Web開發。MySQL是一種DSL，專用於操做數據庫。Make是一種DSL，專門用來處理Shell腳本操做系統文件輸入和輸出。

若是您是一個以解決問題爲目標的全棧工程師 ，我建議您在考慮發明一個DSL以前先考慮如下方案 。

• 儘可能用您熟悉的通用語言來解決問題 ，好比Python、Java或C++。
• 優化您的解決方案，提煉出一種真正精簡、優雅的擴展庫。
• 開源您的擴展庫，根據其餘人的貢獻來繼續優化解決方案。
• 若是想簡化配置文件的語法，能夠建立一個腳本包裝器來專門爲庫工做，這就是您本身的DSL。
• 若是最後您仍是想進一步優化下去，那就發明您的DSL吧。

框架和庫拓展了語言
在快速開發中，真正重要的是庫，全棧工程師的目標每每是快速解決商業問題，不必定須要長期完美的方案。使用方便好用的框架能大大節省學習成本和開發時間，因此有些時候咱們的技術選型步驟是：先選擇框架，而後選擇語言。

2. 腳本語言的優點

一個誤解，Swift是一種語法很像腳本語言的編譯語言。腳本語言跟編譯語言的差別不在於語法，而在於編譯機制。

腳本語言，是指支持用腳本的方式編寫程序的語言，它無需編譯便可直接在運行時環境中解析。在操做上，它縮短了傳統的 「編寫編譯連接運行 」過程。腳本語言一般具備簡單、易用的特性，並且經常很短小。

相比編譯語言腳本語言有更高的開發效率，可是在執行效率上會有所犧牲。因爲如今的趨勢是硬件成本愈來愈低，而工程師的人工成本愈來愈高，因此腳本語言的使用空間愈來愈大，有一些腳本語言（ Python、Ruby ）已經在成熟的商業網站中使用。

不一樣的腳本語言有不一樣的設計原則，可是它們每每有一個共同的目標，就是以簡單的方式，快速完成某些複雜的任務。

腳本語言不須要編譯
腳本語言的特色是無需編譯便可運行，它在對應的運行環境中直接運行，運行時經過解釋器來逐句解析。

由於語言跟對應的解釋器（或者編譯語言跟對應的編譯器）是分開的兩個概念，因此從科學上講，只要給定合適的運行時環境和庫支持，任何語言均可以做爲腳本語言來使用（也就是編寫腳本） 。也就是說， 「編寫腳本」是對語言的一種使用方法 ，而稱某種語言爲腳本語言是一種工程上的約定俗成的用法，而不是科學上的定義。

並且另外一個問題是，不管是腳本語言仍是編譯語言，最終都須要編譯成機器碼讓機器來執行。好比JS語言 ，在v8引擎中被編譯爲機器碼而後執行，若是是使用Node.js。那麼這個機器碼可能會被緩存起來，這樣的話，跟編譯語言就沒什麼區別了。

腳本語言經常不須要關心清理內存
由於腳本語言的設計目標是快速寫出能運行的程序，它更傾向於取悅工程師，而不是優化性能。因此在語法上就忽視內存管理，而該語言的解釋器則各顯神通，把清理內存垃圾的重擔攬在本身的黑盒裏面，無需工程師關注。

腳本語言經常會對特定領域優化

腳本語言經常是動態類型語言

腳本語言的抽象層經常更高

腳本語言經常有包管理器

10、全棧遊樂場

1. VPS

虛擬專用服務器（VPS）是把一臺服務器分割成多個虛擬專享服務器的優質服務。每一個VPS均可分配獨立公網IP地址、獨立操做系統、磁盤空間、內存、 CPU資源、進程和系統配置，模擬出 「獨佔 」使用計算資源的體驗。

比較廉價的選擇是虛擬主機（Virtual Host），又稱虛擬服務器或虛擬空間。虛擬主機將一臺服務器的某項或者所有服務內容邏輯劃分爲多個服務單位，對外表現爲多個服務器，從而充分利用服務器硬件資源。

若是使用虛擬主機，跟其餘人共享CPU和內存等資源，這就像是合租。若是其餘人在使用衛生間，您就無法用了。虛擬主機的好處是很便宜，國內一些服務提供商提供年費僅幾十元的虛擬主機。虛擬並不是指不存在，而是指空間是由實體的服務器延伸而來，其硬件系統能夠是基於服務器羣，或者是單個服務器.

爲何推薦一個全棧工程師買一臺VPS本身玩玩？
對網站全貌有所瞭解
若是採用第三方的託管服務來搭建博客繫系統，新建一個帳號就能夠開始寫了，好處是很方便，缺點是在自定義功能上好比綁定獨立域名，安裝插件和修改路徑格式代沒那麼靈活。

若是有癮vps搭建一個博客網站就麻煩一些。

• 初始化。linode提供一鍵安裝操做系統，等待幾分鐘操做系統就安裝完成了。
• 安裝最新版的Apache。啓用Apache的rewrite等模塊，WordPress的URL重寫會用到。
• 安裝MySQL數據庫，配置WordPress的數據連接。
• 配置域名和路由。包括訪問路由配置，日誌配置，網站域名和別名等，啓動服務器，查看資源利用等等。
• 固然也不要忘了安全防禦和設置自動備份。

看上去很折騰，不過這種折騰是有意義的，由於他那裏在操做的過程當中理解了web工做原理。

時間就是金錢
推薦使用vps的第二個緣由就是穩定。若是您想把精力集中在有用的技術上，而不是服務器無響應或者IP北牆等一些無聊的雜事，那麼vps是最有性價比的選擇。

部署本身的環境

學習Linux

理解HTTP
經過本身去配置和操做服務器，會讓前端工程師也得http有更好的理解。

2. 如何選擇vps？

每一個人都有不一樣的需求，不過選擇vps的原則都差很少，首先須要考慮的固然是性價比，主要參數是內存、CPU、硬盤和流量。

• 內存通常是vps的瓶頸
• CPU是相對沒那麼重要的性能指標
• 硬盤的大小和讀寫速度是關鍵。
• 還有一個重要的考慮就是客戶服務。

關注服務及安全
能力越大責任越大，當你有了安裝vps操做系統的能力，您就必定要學會保護本身的服務器。

操做系統的選擇

域名解析
通常來講，域名購買商和服務器提供商都提供DNS解析的能力，不過域名在哪裏註冊和域名在哪裏解析是兩回事。

由於國內網絡環境比較複雜，用戶可能來自電信、聯通、移動、教育網等網絡，因此建議把域名的域名服務器設置爲國內的智能DNS提供商，好比DNSPod。DNSPod除了能夠根據用戶IP來給出最佳的IP之外，還提供額外的功能，好比網站監控等增值服務。

雲服務器

11、高效工程師

1. 提速100倍

閱讀英文資料

• 英文的技術資料更多。
• stackoverflow有完善的鼓勵機制。
• 谷歌的搜索能力很是強。
• 英語世界的語言風格比較嚴謹。

時間管理四象限

消除重複工做

給本身留出不被打擾的時間

番茄工做法

2. 跨界思考

過去跨界學習的成本很高，大部分人都不敢輕易嘗試，但現在互聯網時代給咱們帶來了機遇，天天上網均可以看到其餘領域名人寫的文章和微博，經過查看這些內容，咱們就能對於本來徹底陌生的領域有一個感性的認識，時間一久咱們就可以在潛移默化中理解另外一個領域的從業者的思惟方式，當您開始跨界學習以後，就會增長更多的機會。

或許每一個工程師會在不一樣的環境中，跨不一樣的界，可是在將來，我認爲跨界出來的那部分能力才真正定義了「您」。

3. 紙上頭腦風暴

4. 使用版本控制和構建系統

12、學習設計

在前面的章節裏「如何成爲全棧工程師」裏，我給有志成爲全棧工程師的同窗的的第一個建議是「關注商業目標」，第二個建議是「關注用戶體驗」。而好的設計師優秀用戶體驗的必要非充分條件。

1. 科學家和工程師

首先，一個事實是：過去的工程師普片不在乎設計。有意無心，他們忽視設計的重要性。

知乎網站上有一個帖子，問題是「爲何部分開發工程師不喜歡調節界面UI細節？」。我比較贊同下面這個回答：

我發現程序員大體能夠分爲科學家和工程師兩類，科學家關注技術是否優越，而工程師關注產品是否完美。和科學家類型的程序員合做項目每每是件痛苦的事情，他們太過關注本身手中的的錘子是否先進，卻不在乎本身敲進去的釘子是否平整光滑不扎屁股，更不要說這可釘子是否是跟其餘釘子對齊裏。那些「資深」程序員更是如此，那個年代不少用戶體驗技術不成熟，能作出一個能用的東西已經不易，更不要說作出一個性能還算不錯的產品。抱着這個想法走到今天，大多數應該被淘汰的程序員反而作到更高的位置，開始拿這種過期的想法薰陶小弟。（來自陳鑫的回答）

2. 細分不是最佳的解決方案

在傳統Web設計流程中，咱們也參考裏工業化的流水線：按交互設計、視覺設計、前端開發、後臺開發的流程來生產一個產品。按照這種細緻的分工，設計師就要輸出3個以上的頁面：手機、平板、超大屏幕的電腦等。設計師在交付設計稿的時候若是有須要調整的地方，3個頁面就要從新調整，只要設計發生裏調整，就要更改每一個對應的樣式，大量的人力和時間就浪費在沒必要要的「流程」中。

咱們的解決方案：視覺設計師關注設計模塊和總體氛圍，只須要給出一份爲PC設計的視覺設計稿。讓有必定合計理論基礎的前端工程師根據拿到的PC設計稿直接建立能夠適配多個平臺的頁面，也就是一個「響應式」的頁面。

另外一個例子，咱們想在頁面或者App中建立一些動畫效果。在老式Web設計中不會有不少動畫，可是如今，頁面和App更強調每個操做都給用戶動畫反饋，有些是爲了更炫，有些是爲了給用戶操做反饋。可是浙西動畫很那在設計稿中體現，這會給設計師和工程師帶來很大的溝通成本。

咱們的解決方案：讓有必定設計功底的前端工程師主動提出本身對動畫而看法，作出效果以後再反饋給設計師去確認，優化後的流程十分高效。

3. 設計基礎

推薦一本書，Robin Wiliams的《寫給你們看的設計書》，本書調理清晰簡單易讀，一個週末的下午或者天天半小時，持續一週就能夠讀完。但它的理論會如此深入地停留在您的腦海裏，每次看到不符合這些理論的設計，對應的理論就會迸發出老。

設計的四大基本理論是：親密性、對齊、重複、對比。

• 親密：關係親密的元素要放在一塊兒，關係疏遠的元素則要分開。位置的親密性直接表現出意義的相關性。
• 對齊：左對齊、右對齊、上對齊、下對齊。斜線對齊比較簡單，居中對齊很難處理，新手不要嘗試。
• 重複：視覺上使用重複的圖形和元素、線條和顏色等。好比QQ空間重複使用的換色跟黑色
  、微信的綠色、京東的紅色等。
• 對比：若是兩個元素（的大小或者顏色）不同，就讓它徹底不同，產生視覺衝擊力。

因此「設計感」實際上是「科學」而不是「藝術」。這些只是理論或者「規則」，規則老是能夠被打破的，可是前提是要熟練掌握這些規則。在沒有掌握這些規則以前，請遵循規則。

十3、全棧思惟

1. 有興趣就夠了嗎

做者講了一個把一本英文書籍交給兩個頗有興趣作翻譯的年輕人的故事，結果因爲各類各樣的理由延期交稿，延期裏也不主動告知，而他們完成的部分也只能算勉強及格，錯譯、漏譯的狀況經常出現，可能存在一些能力問題，但他們給咱們的感受倒是根本就不上心。

若是想拖延一件事，或者不想作一件事，老是能找到理由。懶惰的終極緣由就是您想逃避這件事。對於全部剛開始工做的年輕人，我告訴大家：老闆給您的任務，根本不關心您有sm理由，只關心您完成沒有。

有人認爲興趣是成功的老師，沒法完成某些事情是由於沒有興趣。其實我認爲耐心是一種能力，有些人天生缺少這種能力。在能力不足、困難重重的時候，惟有投入大量的時間才能保住着珍貴的信任。

新人沒有經驗、知識不豐富，這均可以理解，可是以此爲理由輸出不合格的產品，那就是本身的問題。

2. 學一點管理

不是每一個人都有足夠的自律和積極性。雖然做爲全棧工程師，咱們的學習目標一直是提高我的的技術能力。可是在組織中工做，並不須要特別強的我的能力或者天賦、更須要的是穩紮穩打、虛心學習，不要懼怕批評，而應該真誠溝通、珍惜每一次機會，完成每個承諾。

好的管理者能讓平凡的員工作不平凡的事

高效能的管理者並不奢求完美的人才，他能讓平凡的人成就不平凡的事業

《卓有成效的管理者》中的核心是5個思惟習慣，這5個思惟習慣環環相扣，很是經典。

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

每一條都會花一章的篇幅來展開說明，每一章都有些讓我醍醐灌頂的部分。好比「有效的管理者重視對外界的貢獻」。

重視貢獻，才能使管理者的注意力不爲自己的專長所限，不爲其自己的技術所限，不爲其自己所屬的部門所限，才能看到總體的績效，同事也才能使他更重視外部世界。

3. 溝通：被忽視的競爭力

一個事實是，程序員的溝通能力所帶來的價值被大大低估來。在咱們的招聘流程中，技術能力過關，可是由於溝通能力這一項不過關，而直接被拒絕的面試者比例仍是很高的。可是爲了不沒必要要的爭議，大企業的HR每每不會把拒絕的緣由傳達給應聘者，因此對方也不知道本身爲何會被拒絕。

溝通能力的評判每每是很是微妙和主觀的，並無一份考題能證實您的溝通能力好或者差，只是面試官能根據本身的判斷來決定。爲了不無休止的爭論，因此剛脆不告訴拒絕緣由是最好的。

溝通是軟技能
針對目標聽衆
佛家有一個詞叫「度己度人」，就是在幫助別人的過程當中，其實也在幫助本身。因此反過來想，做爲需求的請求方，最開始就得找到那個很關鍵的人，對於他來講，幫助您對他是頗有好處的。也就是說他能把這件事看成i本身的冠軍任務。若是您的要求對於他人純屬累贅，那麼他人天然不肯意幫助您了，任您多麼會溝通，最終都無論用。

因此，受權給平級的同事的時候，最好的方法就是訴諸對方的利益。若是一件事情能夠對雙方的KPI都有好處，那麼對方也願意幫助您一塊兒分擔這個任務。若是您把不擅長的事情受權給對方，而做爲交換，能給對方一些資源，那也是訴諸利益的一個好方法。

其次的方法就是把問題上升到上級領導，讓上級領導安排資源，可是這種方法不能常常用，不然上司會認爲您不會主動解決問題，只會提出問題。被受權的那一方也以爲您在拿領導壓制他，可能會存在負面的情緒。

有方法
麥肯錫的金字塔原理就是，任何事情均可以概括出一箇中心論點，而此中心論點可由3至7個論據支持，這些一級論據自己也能夠是論點，被二級的3至7個論據支持，如此延伸，狀如金字塔。使用金字塔方法的前提是，您的有一箇中心目標。不能是兩個，更多更不行，只能是一個。

表達本身的想法

看到這裏，這本書就讀完了！