六、大前端1. 易於上手、難於精通
不同於某些“難於上手、難於精通”的職業，前端這一崗位就像暴雪公司的遊戲設計一樣：“易於上手、難於精通 ”。
前端技術的“易於上手”導致它在某些技術人員那裡不受待見。他們認為HTML與CSS根本都不是程式語言，甚至認為JavaScript是一種功能不全的玩具型語言。所以直到我幾年前畢業的時候，大學都沒有前端相關的課程和專業。而市場對前端工程師的需求又很大，學校的輸出跟市場的要求沒有對接上，所以往往出現學生找不到工作，公司又招不到人的現狀。
2. 框架 VS 庫一個庫是一系列物件、方法等程式碼，你的應用程式顆以把這個庫 “連結 ”進來。這個庫起到了重用程式碼的作用，為您省下了重寫這部分程式碼的工作量。
而一個框架是一個軟體系統中可重用的一部分。它可能包含子程式、庫、膠水語言、圖片等一些“資源”，這些資源一起組成了軟體專案。框架不像庫，可能包含多種語言，某些功能可能通過API的方式讓主程式呼叫。所以框架是一個更加靈活和寬鬆的名詞，在具體的情景中，它可能指一個庫、多個庫、指令碼程式碼，或者多個可單獨執行的子程式的集合。
在出現一些熱門框架時，建議開發者先去了解框架的建立初衷，合理使用，而不是盲目收集。
七、向移動端轉型1. 為什麼向移動端轉型技術是服務於市場的，在市場發生變化的時候，如果開發者不能順應變化，就有被淘汰的風險，畢竟很多開發者所服務的這個崗位誕生都不到十年，消亡可能也會在十年之內發生。對於目標是全棧工程師的人來說，技術能力更是多多益善。
2. 一定要是自己的產品的使用者風投在評估一個創業專案是否會成功的時候，有一個指標就是創始人是否是自己產品的目標使用者。如果不是，那產品很有可能會失敗。
在大公司，一些工程師士氣低迷往往就是這個原因，成功來得很慢，失敗也是。因為大家害怕失敗，所以想把產品調整得完美無缺才釋出。但是世界上成功的軟體都不是完美的軟體，而是在合適的時間釋出的、剛剛夠用的產品。如果它能活下來，在後面的版本中，它才有機會越來越好。
《精益創業 》中有一句話：“客戶需求只有在實際使用中才能辨明，再多的前期調研也只能發現客戶認為他們想要什麼，而不是客戶實際上想要什麼。因此在不了解客戶真實需求的情況下，只會多做多錯。”
3. 有哪些方向iOS原生AppiOS原生App開發的技能樹相對比較新，需要學習Objective C這門語言，以及Xcode的一些操作方法——主要是sto ryboard，以及各種官方類庫的使用方法。它帶來的收益也很高，對於獨立開發。AppStore仍然是地球上最好的軟體市場，對於團隊，在未來5年都不會缺少對iOS開發者的需求。
Android原生App使用Java程式設計，如果有Java程式設計經驗，Android原生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的優勢也很明顯 。
八、持續整合1.版本控制SVN集中式程式碼管理的核心是伺服器，所有開發者在開始新一天的工作之前必須從伺服器獲取程式碼，然後開發，最後解決衝突，提交。所有的版本資訊都放在伺服器上。如果脫離了伺服器，開發者基本上可以說是無法工作的。
在企業內部，使用SVN沒有什麼問題，伺服器壓力和內部頻寬都能夠承受所有員工一起操作SVN。但是在開源世界，這種架構方法就不行了，著名的開源軟體的開發人數太多了，因此誕生了Git。
GitGit是一個分散式版本控制軟體，是天才工程師、Linux核心開發者Linus開發，目的是更好地管理Linux核心原始碼。其第一版於2005年釋出，它與SVN最大的不同之處就是基於分散式的理念。
2. 版本控制最佳實踐鼓勵頻繁的提交SVN踐是頻繁地提交，而不要等到程式碼沒問題了再一次性提交。對於可能損壞主幹原則的程式碼，不要直接提交到主幹，而是建立一個分支，在分支中頻繁提交。
確定分支流程基本上所有的特性和較大的bug修復都應該使用分支來修改。
定義主幹原則，並且堅守它我們團隊的主幹原則是“主幹對應的程式碼必須是可以釋出並且不會產生bug的”，如果不能保證新增的或者修改的程式碼符合這一原則，就在分支提交程式碼。任何人破壞這一原則引起bug，就請大家吃飯。
不要把邏輯的修改和程式碼格式化操作混在一起如果您做了一些程式碼格式化的操作，就單獨提交這次修改。比如您去掉了程式碼中所有的空行，那就單獨提交一個 commit，然後再做一些邏輯的修改，再提交。這樣可以避免“天哪，所有的東西都不一樣了”，出現問題之後更容易追溯。
不相干的程式碼分開提交也就是說不要在一次提交裡修復兩個bug。
保持工作程式碼庫的“乾淨”如果您有檔案不想也不需要提交，就加入到忽略列表（ignorelist） 。不需要提交的檔案包括編譯後文件、配置檔案和第三方依賴等。這樣的好處是，您每次開啟SVN提交介面，如果沒有修改過任何程式碼，就會看見一個空的列表 ，如果修改過程式碼，就顯示修改過的程式碼。這能提醒您不要漏掉任何需要提交的檔案。
3. 包管理為什麼需要包管理？
在我們日常工作編寫的軟體中，可能有絕大部分程式碼都不是我們自己輸入的。我們“依賴”一些第三方的框架或者庫。在Web前端開發中，我們依賴各種框架、庫、靜態資源等；在PHP開發中，我們依賴各種框架、庫；在iOS App開發中，我們依賴各種庫、模組、資源等。在複雜一點的依賴環境中，您所引入的第三方庫也依賴其他的“第四方庫” “第五方庫”… …如何保證互相之間都不會出現衝突很重要。
如何讓我們依賴的資源有條不紊地在一個地方進行管理和更新，而不用重複“搜尋、下載、移動”這一系列繁瑣的手工操作？這就要引入“包管理”。
Node.jsNode.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和GulpMake很強大，而且在全世界範圍內幾乎所有的計算機領域用了幾十年，它的穩定可靠經過了廣泛驗證。不過從學習成本角度來說，它需要學習者具備一些Linux程式設計的基礎，難度較高。所以，Grunt和 Gulp誕生了，它們都是用 JavaScript來實現的構建工具。
Grunt引爆了前端架構工具的概念，得到了廣泛的應用。現在，Grunt的生態環境已經非常龐大，越來越多的開發者著手Grunt開發，為它添磚加瓦。但是Grunt有幾個問題 。
配置項過多。每一個外掛的使用都需要配置輸入項和輸出項，使用比較繁瑣。子任務間的協作基於檔案。基於檔案的壞處是，後一個子任務必須等前一個子任務的過程完全結束，才能開始它的流程，這樣比較慢。而且磁碟讀寫速度遠遠慢於記憶體讀寫。所以雖然Grunt有先發優勢，但是由於它有幾個痛點沒有很好地解決，所以又誕生了Gulp。
Gulp的意思是 “大口吸” ，它最初的logo是一杯飲料，上面有一根吸管，很形象地跟它的宣傳語相呼應：“基於流的構建工具” 。與Grunt最大的不同就在於，Gulp基於 “流 ”的理念。
Gulp基於Node.js的流的概念，所以前一個任務的輸出就是後一個任務的輸入。
從語法風格上來講，編寫任務的過程更像是 “程式設計 ”，而不是 “編寫配置” 。Gulp通過對接前一個任務的輸入和後一個任務，就像一個管道，二者可以同時進行，不輸出在磁碟中，沒有多餘的中間產物，效能更加高效。
當前，Gulp的社群還遠不如Grunt成熟，有些功能的外掛，Gulp可能就沒有。不過從個人偏好來看，我更傾向於Gulp，它的技術理念更好。
九、理解程式語言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。那麼這個機器碼可能會被快取起來，這樣的話，跟編譯語言就沒什麼區別了。
指令碼語言常常不需要關心清理記憶體因為指令碼語言的設計目標是快速寫出能執行的程式，它更傾向於取悅工程師，而不是優化效能。所以在語法上就忽視記憶體管理，而該語言的直譯器則各顯神通，把清理記憶體垃圾的重擔攬在自己的黑盒裡面，無需工程師關注。
指令碼語言常常會對特定領域優化
指令碼語言常常是動態型別語言
指令碼語言的抽象層常常更高
指令碼語言常常有包管理器
十、全棧遊樂場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以外，還提供額外的功能，比如網站監控等增值服務。
雲伺服器
十一、高效工程師1. 提速100倍閱讀英文資料
英文的技術資料更多。stackoverflow有完善的鼓勵機制。谷歌的搜尋能力非常強。英語世界的語言風格比較嚴謹。時間管理四象限
消除重複工作
給自己留出不被打擾的時間
番茄工作法
2. 跨界思考過去跨界學習的成本很高，大部分人都不敢輕易嘗試，但現在網際網路時代給我們帶來了機遇，每天上網都可以看到其他領域名人寫的文章和微博，通過檢視這些內容，我們就能對於原本完全陌生的領域有一個感性的認識，時間一久我們就能夠在潛移默化中理解另一個領域的從業者的思維方式，當你開始跨界學習之後，就會增加更多的機會。
或許每個工程師會在不同的環境中，跨不同的界，但是在未來，我認為跨界出來的那部分能力才真正定義了“您”。
3. 紙上頭腦風暴4. 使用版本控制和構建系統十二、學習設計在前面的章節裡“如何成為全棧工程師”裡，我給有志成為全棧工程師的同學的的第一個建議是“關注商業目標”，第二個建議是“關注使用者體驗”。而好的設計師優秀使用者體驗的必要非充分條件。
1. 科學家和工程師首先，一個事實是：過去的工程師普遍不在意設計。有意無意，他們忽視設計的重要性。
知乎網站上有一個帖子，問題是“為什麼部分開發工程師不喜歡調節介面UI細節？”。我比較贊同下面這個回答：
2. 細分不是最佳的解決方案我發現程式設計師大致可以分為科學家和工程師兩類，科學家關注技術是否優越，而工程師關注產品是否完美。和科學家型別的程式設計師合作專案往往是件痛苦的事情，他們太過關注自己手中的的錘子是否先進，卻不在意自己敲進去的釘子是否平整光滑不扎屁股，更不要說這可釘子是不是跟其他釘子對齊裡。那些“資深”程式設計師更是如此，那個年代很多使用者體驗技術不成熟，能做出一個能用的東西已經不易，更不要說做出一個性能還算不錯的產品。抱著這個想法走到今天，大多數應該被淘汰的程式設計師反而做到更高的位置，開始拿這種過時的想法薰陶小弟。（來自陳鑫的回答）
在傳統Web設計流程中，我們也參考裡工業化的流水線：按互動設計、視覺設計、前端開發、後臺開發的流程來生產一個產品。按照這種細緻的分工，設計師就要輸出3個以上的頁面：手機、平板、超大螢幕的電腦等。設計師在交付設計稿的時候如果有需要調整的地方，3個頁面就要重新調整，只要設計發生裡調整，就要更改每個對應的樣式，大量的人力和時間就浪費在不必要的“流程”中。
我們的解決方案：視覺設計師關注設計模組和整體氛圍，只需要給出一份為PC設計的視覺設計稿。讓有一定設計理論基礎的前端工程師根據拿到的PC設計稿直接建立可以適配多個平臺的頁面，也就是一個“響應式”的頁面。
另一個例子，我們想在頁面或者App中建立一些動畫效果。在老式Web設計中不會有很多動畫，但是現在，頁面和App更強調每一個操作都給使用者動畫反饋，有些是為了更炫，有些是為了給使用者操作反饋。但是浙西動畫很難在設計稿中體現，這會給設計師和工程師帶來很大的溝通成本。
我們的解決方案：讓有一定設計功底的前端工程師主動提出自己對動畫而見解，做出效果之後再反饋給設計師去確認，優化後的流程十分高效。
3. 設計基礎推薦一本書，Robin Wiliams的《寫給大家看的設計書》，本書條理清晰簡單易讀，一個週末的下午或者每天半小時，持續一週就可以讀完。但它的理論會如此深刻地停留在您的腦海裡，每次看到不符合這些理論的設計，對應的理論就會迸發出來。
設計的四大基本理論是：親密性、對齊、重複、對比。
親密：關係親密的元素要放在一起，關係疏遠的元素則要分開。位置的親密性直接表現出意義的相關性。對齊：左對齊、右對齊、上對齊、下對齊。斜線對齊比較簡單，居中對齊很難處理，新手不要嘗試。重複：視覺上使用重複的圖形和元素、線條和顏色等。比如QQ空間重複使用的換色跟黑色、微信的綠色、京東的紅色等。
對比：如果兩個元素（的大小或者顏色）不一樣，就讓它完全不一樣，產生視覺衝擊力。所以“設計感”其實是“科學”而不是“藝術”。這些只是理論或者“規則”，規則總是可以被打破的，但是前提是要熟練掌握這些規則。在沒有掌握這些規則之前，請遵循規則。
十三、全棧思維1. 有興趣就夠了嗎作者講了一個把一本英文書籍交給兩個很有興趣做翻譯的年輕人的故事，結果由於各種各樣的理由延期交稿，延期裡也不主動告知，而他們完成的部分也只能算勉強及格，錯譯、漏譯的情況常常出現，可能存在一些能力問題，但他們給我們的感覺卻是根本就不上心。
如果想拖延一件事，或者不想做一件事，總是能找到理由。懶惰的終極原因就是您想逃避這件事。對於所有剛開始工作的年輕人，我告訴你們：老闆給您的任務，根本不關心您有sm理由，只關心您完成沒有。
有人認為興趣是成功的老師，無法完成某些事情是因為沒有興趣。其實我認為耐心是一種能力，有些人天生缺乏這種能力。在能力不足、困難重重的時候，唯有投入大量的時間才能保住著珍貴的信任。
新人沒有經驗、知識不豐富，這都可以理解，但是以此為理由輸出不合格的產品，那就是自己的問題。
2. 學一點管理不是每個人都有足夠的自律和積極性。雖然作為全棧工程師，我們的學習目標一直是提升個人的技術能力。但是在組織中工作，並不需要特別強的個人能力或者天賦、更需要的是穩紮穩打、虛心學習，不要害怕批評，而應該真誠溝通、珍惜每一次機會，完成每一個承諾。
好的管理者能讓平凡的員工做不平凡的事高效能的管理者並不奢求完美的人才，他能讓平凡的人成就不平凡的事業
《卓有成效的管理者》中的核心是5個思維習慣，這5個思維習慣環環相扣，非常經典。
有效的管理者知道她們的時間用在什麼地方有效的管理者重視對外界的貢獻有效的管理者善於利用長處，包括自己的長處、上司的長處、同事的長處和下屬的長處。有效的管理者集中精力於少數重要的領域，在這個少數重要的領域中，如果能有優秀的績效就可以產生卓越的成果。最後，有效的管理者必須善於做有效的決策每一條都會花一章的篇幅來展開說明，每一章都有些讓我醍醐灌頂的部分。比如“有效的管理者重視對外界的貢獻”。
重視貢獻，才能使管理者的注意力不為本身的專長所限，不為其本身的技術所限，不為其本身所屬的部門所限，才能看到整體的績效，同時也才能使他更重視外部世界。
3. 溝通：被忽視的競爭力一個事實是，程式設計師的溝通能力所帶來的價值被大大低估來。在我們的招聘流程中，技術能力過關，但是因為溝通能力這一項不過關，而直接被拒絕的面試者比例還是很高的。但是為了避免不必要的爭議，大企業的HR往往不會把拒絕的原因傳達給應聘者，所以對方也不知道自己為什麼會被拒絕。
溝通能力的評判往往是非常微妙和主觀的，並沒有一份考題能證明您的溝通能力好或者差，只是面試官能根據自己的判斷來決定。為了避免無休止的爭論，所以乾脆不告訴拒絕原因是最好的。
溝通是軟技能針對目標聽眾佛家有一個詞叫“度己度人”，就是在幫助別人的過程中，其實也在幫助自己。所以反過來想，作為需求的請求方，最開始就得找到那個很關鍵的人，對於他來說，幫助你對他是很有好處的。也就是說他能把這件事當作i自己的冠軍任務。如果您的要求對於他人純屬累贅，那麼他人自然不願意幫助您了，任您多麼會溝通，最終都不管用。
所以，授權給平級的同事的時候，最好的方法就是訴諸對方的利益。如果一件事情可以對雙方的KPI都有好處，那麼對方也願意幫助你一起分擔這個任務。如果您把不擅長的事情授權給對方，而作為交換，能給對方一些資源，那也是訴諸利益的一個好方法。
其次的方法就是把問題上升到上級領導，讓上級領導安排資源，但是這種方法不能經常用，否則上司會認為您不會主動解決問題，只會提出問題。被授權的那一方也覺得您在拿領導壓制他，可能會存在負面的情緒。
有方法麥肯錫的金字塔原理就是，任何事情都可以歸納出一箇中心論點，而此中心論點可由3至7個論據支援，這些一級論據本身也可以是論點，被二級的3至7個論據支援，如此延伸，狀如金字塔。使用金字塔方法的前提是，您的有一箇中心目標。不能是兩個，更多更不行，只能是一個。
表達自己的想法
看到這裡，這本書就讀完了！
全文完。