在買之前以為這本書是教你怎么去做一個(gè)web全棧工程師，以及介紹需要掌握的哪些技術(shù)的書，然而看的過(guò)程中才發(fā)現(xiàn)，是一本方法論的書。讀起來(lái)的感覺(jué)有點(diǎn)像紅衣教主的《我的互聯(lián)網(wǎng)方法論》，以一些自己的經(jīng)歷和感悟來(lái)闡述web全棧工程師需要具備哪些素質(zhì)，而不僅僅是需要哪些技術(shù)。這算是我買的書中看的最快的一本書。

在閱讀這本書之前，我對(duì)全棧工程師的理解還停留在node階段，隨著node在服務(wù)端的風(fēng)生水起，有一段時(shí)間會(huì)認(rèn)為使用nodejs作為服務(wù)端開(kāi)發(fā)，前后端統(tǒng)一使用js開(kāi)發(fā)，便是所謂的全棧開(kāi)發(fā)，比較流行的技術(shù)棧當(dāng)屬 MEAN 和 Meteor 了。然而，很多創(chuàng)業(yè)公司，沒(méi)有專職的前端，大部分由RD同時(shí)完成前端和后端代碼的編寫，那是不是也可以稱之為全棧工程師了呢？

本書對(duì)全棧工程師的理解是 ： 除了在一個(gè)專精知識(shí)領(lǐng)域有深入的研究之外，需要知識(shí)廣博和解決問(wèn)題能力強(qiáng)。抽象出來(lái)就是 1、一專多長(zhǎng) ； 2、解決問(wèn)題能力強(qiáng)(而非炫技) 。 全棧工程師的成長(zhǎng)路線，一定是先精后廣，觸類旁通。如果一開(kāi)始就想直接追求全棧，只會(huì)導(dǎo)致雜而不精，沒(méi)有核心競(jìng)爭(zhēng)力。全棧工程師還有一個(gè)特點(diǎn)是對(duì)產(chǎn)品業(yè)務(wù)，用戶體驗(yàn)都保持較高的敏感度。而不僅僅關(guān)心自己那部分技術(shù)實(shí)現(xiàn)。

全棧眼中的http這一章分別從前端視角和后端視角來(lái)分析前后端所關(guān)注的側(cè)重點(diǎn)。前端可以通過(guò)抓包工具或者chrome devtools 查看每個(gè)請(qǐng)求，同域下的資源請(qǐng)求數(shù)量等來(lái)找出優(yōu)化點(diǎn)，更關(guān)注的是一個(gè)頁(yè)面的請(qǐng)求數(shù)，資源大小等直接影響頁(yè)面展現(xiàn)速度的因素。而后端則更關(guān)注如何更快速的響應(yīng)請(qǐng)求，以及減小服務(wù)器壓力。并給出了需要前后端協(xié)同工作的一種http優(yōu)化方案，bigpipe。

web發(fā)展到今天，崗位越來(lái)越細(xì)分。開(kāi)始數(shù)據(jù)庫(kù)設(shè)計(jì)是由相關(guān)的RD完成，現(xiàn)在有專門的DBA來(lái)操作和管理數(shù)據(jù)庫(kù)，而前端也有些公司也分為UI工程師(也叫css重構(gòu)工程師)，JS工程師。細(xì)分之后的有點(diǎn)的職業(yè)門檻更低，長(zhǎng)期在某一個(gè)方向上可能會(huì)有更深的造詣，然而缺點(diǎn)也很明顯，每個(gè)人都被圈定在某個(gè)title限定的圈子里，接觸的知識(shí)面變窄，接近的上下游之間，存在一部分灰色地帶，職責(zé)不是很好劃分，項(xiàng)目溝通成本增加。

向移動(dòng)轉(zhuǎn)型。不管是大公司，還是創(chuàng)業(yè)公司，向移動(dòng)端轉(zhuǎn)型是一個(gè)必然的趨勢(shì)。而在轉(zhuǎn)型的過(guò)程中，對(duì)前端是有巨大的機(jī)會(huì)和挑戰(zhàn)。我們都知道，H5頁(yè)面一直在體驗(yàn)上被吐槽，webview加載和渲染性能遠(yuǎn)遠(yuǎn)趕不上原生應(yīng)用，然而，H5的作為web 應(yīng)用，天然具備的靈活性又是原生應(yīng)用無(wú)法做到的，為了兼具兩種應(yīng)用的優(yōu)勢(shì)，Hybrid 便誕生了，對(duì)于混合應(yīng)用，必須要求對(duì)原生應(yīng)用有一定的了解，Scheme協(xié)議，H5資源離線化，native 和 h5 之間的通信，才能幫助前端工程師更好和原生應(yīng)用開(kāi)發(fā)者合作。

設(shè)計(jì)原則：不管是什么方向的開(kāi)發(fā)，有些設(shè)計(jì)原則是共通的。比如 DRY 原則：don't repeat yourself。 意思是在一個(gè)系統(tǒng)中，對(duì)于任何數(shù)據(jù)或者變量，都應(yīng)該有且只有一個(gè)地方配置，其余的地方只是引用這里的數(shù)據(jù)。然而事實(shí)上，很多時(shí)候，變量定義的時(shí)候可能只有一個(gè)地方使用，隨著業(yè)務(wù)的發(fā)展和功能的迭代，在其他地方出現(xiàn)了一次引用，是不是每次遇到一個(gè)都需要抽離一次呢？其實(shí)也不然，代碼重構(gòu)通用的法則是三次法則： 允許復(fù)制代碼一次，當(dāng)相同的代碼片段同時(shí)出現(xiàn)三次以上，就需要將其提取出來(lái)作為公共模塊。

前面提到的很多是具體的某種場(chǎng)景下的具體方法論，當(dāng)然還有很多沒(méi)有列出來(lái)。實(shí)際上本書還提到了很多非技術(shù)的軟素質(zhì)。比如說(shuō)如何進(jìn)行匯報(bào)。如何像上級(jí)匯報(bào)，如何跟你的上下游合作人員進(jìn)行溝通。要做自己的產(chǎn)品的用戶。想要成為全棧工程師最重要并不是會(huì)所有的技術(shù)棧，而是需要具備全棧思維，也意味著需要承擔(dān)更多的責(zé)任，包括了解上下游的工作內(nèi)容和知識(shí)，再考慮設(shè)計(jì)方案的時(shí)候也能考慮到上下游之間的影響，具有跨團(tuán)隊(duì)的推動(dòng)力和影響力。