《web全棧工程師的自我修養》閱讀筆記

        在買以前覺得這本書是教你怎麼去作一個web全棧工程師，以及介紹須要掌握的哪些技術的書，然而看的過程當中才發現，是一本方法論的書。讀起來的感受有點像紅衣教主的《個人互聯網方法論》，以一些本身的經歷和感悟來闡述web全棧工程師須要具有哪些素質，而不只僅是須要哪些技術。這算是我買的書中看的最快的一本書。

        

        在閱讀這本書以前，我對全棧工程師的理解還停留在node階段，隨着node在服務端的風生水起，有一段時間會認爲使用nodejs做爲服務端開發，先後端統一使用js開發，即是所謂的全棧開發，比較流行的技術棧當屬 MEAN 和 Meteor 了。然而，不少創業公司，沒有專職的前端，大部分由RD同時完成前端和後端代碼的編寫，那是否是也能夠稱之爲全棧工程師了呢？

        

        本書對全棧工程師的理解是 ： 除了在一個專精知識領域有深刻的研究以外，須要知識廣博和解決問題能力強。抽象出來就是 一、一專多長 ； 二、解決問題能力強(而非炫技) 。 全棧工程師的成長路線，必定是先精後廣，舉一反三。若是一開始就想直接追求全棧，只會致使雜而不精，沒有核心競爭力。全棧工程師還有一個特色是對產品業務，用戶體驗都保持較高的敏感度。而不只僅關心本身那部分技術實現。

 

        全棧眼中的http這一章分別從前端視角和後端視角來分析先後端所關注的側重點。前端能夠經過抓包工具或者chrome devtools 查看每一個請求，同域下的資源請求數量等來找出優化點，更關注的是一個頁面的請求數，資源大小等直接影響頁面展示速度的因素。然後端則更關注如何更快速的響應請求，以及減少服務器壓力。並給出了須要先後端協同工做的一種http優化方案，bigpipe。

        

        web發展到今天，崗位愈來愈細分。開始數據庫設計是由相關的RD完成，如今有專門的DBA來操做和管理數據庫，而前端也有些公司也分爲UI工程師(也叫css重構工程師)，JS工程師。細分以後的有點的職業門檻更低，長期在某一個方向上可能會有更深的造詣，然而缺點也很明顯，每一個人都被圈定在某個title限定的圈子裏，接觸的知識面變窄，接近的上下游之間，存在一部分灰色地帶，職責不是很好劃分，項目溝通成本增長。

 

        向移動轉型。不論是大公司，仍是創業公司，向移動端轉型是一個必然的趨勢。而在轉型的過程當中，對前端是有巨大的機會和挑戰。咱們都知道，H5頁面一直在體驗上被吐槽，webview加載和渲染性能遠遠趕不上原生應用，然而，H5的做爲web 應用，自然具有的靈活性又是原生應用沒法作到的，爲了兼具兩種應用的優點，Hybrid 便誕生了，對於混合應用，必需要求對原生應用有必定的瞭解，Scheme協議，H5資源離線化，native 和 h5 之間的通訊，才能幫助前端工程師更好和原生應用開發者合做。

 

        設計原則：不論是什麼方向的開發，有些設計原則是共通的。好比 DRY 原則：don't repeat yourself。 意思是在一個系統中，對於任何數據或者變量，都應該有且只有一個地方配置，其他的地方只是引用這裏的數據。然而事實上，不少時候，變量定義的時候可能只有一個地方使用，隨着業務的發展和功能的迭代，在其餘地方出現了一次引用，是否是每次遇到一個都須要抽離一次呢？其實也否則，代碼重構通用的法則是三次法則： 容許複製代碼一次，當相同的代碼片斷同時出現三次以上，就須要將其提取出來做爲公共模塊。

 

        前面提到的不少是具體的某種場景下的具體方法論，固然還有不少沒有列出來。實際上本書還提到了不少非技術的軟素質。好比說如何進行彙報。如何像上級彙報，如何跟你的上下游合做人員進行溝通。要作本身的產品的用戶。想要成爲全棧工程師最重要並非會全部的技術棧，而是須要具有全棧思惟，也意味着須要承擔更多的責任，包括瞭解上下游的工做內容和知識，再考慮設計方案的時候也能考慮到上下游之間的影響，具備跨團隊的推進力和影響力。