從前端領域到敏捷開發

【慕客訪談】阿當技術漫談之（一）：從前端領域到敏捷開發

 

 

      慕客訪談▪第九期

 

      本期人物：阿當 前端工程師

 

      ◎人物背景

 

      阿當，資深web技術專家，06年入行，曾在雅虎、淘寶、新浪、盛大等知名IT公司任職，主要關注web client端、http server端、socket server端、敏捷開發和遊戲開發等領域的知識。關於技術，他我的更傾向於T型化的知識結構，在技術路線的發展方向上，比起深度，他更喜歡廣度。

 

      最終成爲IT圈兒裏的「公衆人物」則是由於在2010年時出版了《編寫高質量代碼——web前端開發修煉之道》一書，以致於在後來面試新人時，不少人表示是看着他的書入行的，這讓阿當很有成就感。

 

      ◎人物印象

 

      專業、深刻，是阿當留給咱們最深入的印象，從前端領域的發展到遊戲開發再到技術驅動產品創新，他絕對是個專業的多面手，每一個問題都可以侃侃而談，細緻入微的深刻分析，通俗易懂的專業解讀。若是你對前端開發、html5遊戲開發、敏捷開發……任意一個領域感興趣，這篇文章都值得仔細品讀，看看「大師」的精彩觀點。

 

      ◎技術分享

 

      前端發展的三個時代

 

      1） web1.0時代

 

      2） 黃金時代

 

      3） 移動互聯網時代

 

      平衡知識的深度與廣度

 

      1） 2/8原則

 

      2） 編程技巧

 

      3）平衡法則

 

      敏捷開發解決速度問題

 

      1） 項管知識——尊重與誠實

 

      2） 編程技巧——迭代與高質量代碼

 

 

      如下爲訪談實錄：

 

      前段領域發展的三個階段

 

      慕課網：做爲資深的前端開發者，能談談前端領域的變化以及對前端開發工做的感觸嗎？

 

      阿當：這個真的是變化很大。大學的時候老師說了一句評價IT行業的話，我印象很深入——學咱們這行就是上了賊船，半年不學習就落後了，兩年不學習就找不到工做了。如今的確有了深入體會。從06年入行以來，用我本身的親身體會能夠將前端領域的發展分爲三個階段：

 

      第一階段：web1.0時代——混沌時期，分工不科學

 

      第一階段在07年之前，是web1.0時代，前端技術基本只用照顧ie6,js框架類庫之類的尚未特別造成氣候，以手寫原生代碼爲主。佈局方面更是直接拉table，還流行一系列的hack技巧，好比1x1像素透明的gif圖。前端須要掌握的技術比較雜，那時前端技術的代名詞是「網頁製做三劍客」，flash是前端工程師們必須掌握的技能。事實上，當時尚未「前端開發工程師」這樣的職位，當時的稱呼是「網頁設計師」，須要掌握的技能包括了「設計」和「製做」兩個大相徑庭的大方向。在很多公司裏，「網頁設計師」甚至須要掌握server端技術。如今想來，當時處於一個比較混沌的時期，不少分工是很不科學的。

 

      第二階段：黃金時代——前端開發工程師的起跑線

 

      第二階段大概在07年至10年，這幾年間開始流行一些新概念，好比web2.0、js框架、css重構、用戶體驗、ued扥等。前端開發工程師這個職位也是在這個時期造成並清晰起來的。

 

      這是很是黃金的幾年，發生了不少很美好的事情，好比大量優質的國外前端書籍被引入國內；前端技術的模塊化、工程化；開發和調試工具起來越成熟；優秀的實踐技巧被創造和總結起來。我想國內如今很活躍很厲害的前端工程師們，大部分都是在這個時期成長起來的。

 

      之因此說這個時期很美好，主要是由於在這個時期，絕大多數人差很少都在相同的起跑線，一個蠻荒的起跑線，不管國內仍是國外。新概念、新技巧、新工具差很少是逐個慢慢出來的，工程師們不會一會兒就面對大量的信息，學不過來，或者乾脆不知道從哪兒開始學，這是一個很是適合學習的時期。另外這個時期flash的發展也很是快，推出了as三、flex、流媒體服務器、頁遊扥等，技術愈來愈複雜，因而自成一派和前端開發漸行漸遠。

 

      第三階段：移動互聯網時代——移動web前端開發成新課題

 

      第三階段開始於10年，這一年移動互聯網開始熱門起來，html5和移動web前端開發也成了新的課題。老實說，這是個好的時代，也是個糟糕的時代。

 

      好的方面主要有兩點：一是html5比html4強大了不少，b/s結構的產品在技術底層上多了不少支持，好比websocket、transfrom、web worker、webgl、canvas2d、離線緩存等，在產品形態的創新上，有了強有力的支持；二是SPA開始流行，對前端代碼的質量和編程技巧的要求相較web site高了不少。若是某個技術的門檻比較低，其實並非件好事，web site這種產品形態對前端的代碼質量要求其實並不高，因此並不能很好地驅使工程師去成長。

 

      壞的方面主要有三點：一是移動互聯網時代，c/s結構比b/s結構主流。在pc互聯網時代，b/s結構的產品比c/s結構的產品主流，好比微博、qq空間、人人網、豆瓣、淘寶、知乎、京東……b/s結構的產品風聲水起，瀏覽器是入口，搜索引擎是入口，域名是入口，而web前端技術是b/s結構產品的必要技術。

 

      但到了移動互聯網時代，瀏覽器不流行了，c/s結構的產品纔是主流，想一想在手機上你是怎麼訪問微博的？是去應用市場下載個微博客戶端仍是打開瀏覽器輸入微博的域名？你是怎麼看視頻的？是下載客戶端仍是打開瀏覽器輸入視頻網站的域名？雖然站在web前端的技術角度看，咱們有跨終端優點，有強大的html5，還有響應式設計，但從市場和用戶習慣上看，移動互聯網時代，web前端技術實際上是在被邊緣化的，若是用戶沒有需求沒有使用習慣，技術上再強大又有何用？flex和silverlight技術都遠比html4強大，但同樣被html4幹掉了。web前端技術必須爲本身找到存在的價值和最佳的產品形態。有些同窗認爲hybrid是答案，我不認同。我更傾向於輕應用和微信公衆帳號這兩種方式。將來，且行且看吧。

 

      二是碎片化嚴重，pc時代web的兼容問題和移動互聯網時代相比，真的是小巫見大巫。pc時代的兼容問題基本只用區分IE和非IE，通常狀況下，打開一個IE6和一個firefox，讓網頁兼容這兩個瀏覽器，基本就能兼容全部瀏覽器了，常見的兼容問題不超過20個，特別是有了js框架之後，兼容問題全集中在了css方面。而在移動互聯網時代，碎片化異常嚴重，不一樣的操做系統(pc、ios、android)、不一樣的系統版本號、不一樣的分辨率、不一樣的瀏覽器、不一樣的webview宿主環境……最近這三年多，我一直專一在移動互聯網下的web開發，趟過無數的坑，提及來都是淚啊。

 

      三是新東西層出不窮，亂花漸入迷人眼。好比commonJS、ES六、hybrid、前端mvc、響應式設計、css框架、sass、typeScript、nodejs、webgl等等，不管哪一個撿起來都夠工程師們好好消化一陣子的，這個更新的速度有點快，內容不少，想把它們所有學好不太可能，因此工程師們須要作取捨，根據本身的須要列個學習的優先級，不然極可能直接被嚇到，不知從哪兒開始下手。

 

      web2.0時期那個美好的不緊不慢的學習時代已通過去了，如今進入這個圈子的新同行們尤爲要注意這點——新概念不少，不要盲目跟風，抓緊個主線開始學，什麼東西是核心，什麼東西是輔助性的。

 

      2/8原則——知識的深度和廣度同時發展

 

      慕課網：架構師是比較高的技術職位，可能須要多年經驗積累，能分享一下如何邁向架構師嗎？

 

      阿當：知識的深度和廣度要同時發展，不少同行朋友喜歡研究深度，不太願意把注意力轉到前端以外的領域，其實把本身限制住了。我以爲2/8原則很正確，花20%的精力就能夠解決80%的經常使用需求。有些同行朋友會把剩下的80%精力用於提升那剩下的20%不經常使用需求，從某個方面來講，這些同窗在追求精益求精，是值得尊敬的。只是從投入回報比來看，我我的以爲這麼作是不太明智的。

 

      IT領域有不少方向，並且很多方向是交叉的，從工程角度看，一個項目從上游到下游會涉及到多個不一樣方向的知識，以web site爲例，上游有ps的切圖、css的佈局和js的交互，中游有php、java、 python、ruby等的http服務端，sql或nosql的數據持久化、緩存，下游有linux操做系統、和linux下的各類經常使用服務器 。不一樣環節有不一樣的技術要點，只有清楚了全部環節的職責和要點，才能不存在黑盒，成竹在胸地進行設計。

 

      舉個簡單的例子吧，之前流行在server端進行mvc，url路由 + controllver + ORM + 模板引擎，隨着移動端c/s結構的崛起，以及open api的流行，服務端已經再也不流行模板引擎了，轉而提供json接口的數據，讓客戶端自行解決數據的GUI渲染，因而模板引擎就轉到了客戶端。這是個有意思的變化，思路不復雜，但只有理解了先後端的職責和要點，才能很好地處理這種變化。

 

      編程技巧——主動「設計」

 

      另外還有一點很是重要——編程技巧。常見的知識有這麼幾類：語言、框架、工具。絕大多數人關注的都是這些方面，但除了這些方面以外，還有一些知識很重要，也就是我要說的編程技巧，包括抽象的能力、接口設計的能力、可擴展性、可讀性、魯棒性等等，這些能力也至關重要，這是架構師所必須具有的能力，倒是不少人忽視的地方。

 

      其實不少時候，大多數人接觸到的項目都偏小，加上有框架的幫助，真正須要本身組織的代碼規模都不大，不管是客戶端仍是server端，因此不少同窗不太有機會進行「設計」。這個只能靠本身主動了，一個小的功能，你能夠用最簡單的方法去實現，也能夠換個思路，試試用面向對象的方式去設計一下。平時就以這樣的方式鍛鍊一下，遇到大一些的項目時，就比較有基礎了。

 

      廣度與深度的平衡法

 

      雖然我說我更傾向廣度的發展方向，並不意味着我不在意深度，事實上，廣度和深度是並行向前的，沒有廣度難有深度，沒有深度空有廣度也不值錢。只是如何平衡廣度和深度，就見仁見智了。

 

      我本身有一個平衡的方法：在挖掘深度時，問問本身，這些知識「實用」嗎？若是不實用，我就停下來，去擴展新的廣度去了。有些同窗說，哪有沒有用的知識啊，實際上是他們將「有用」和「實用」混淆了，「有用」卻不「實用」，性價比就不高了。IT領域的知識浩瀚如海，隨便找個領域一頭扎進去都會發現深不見底，哪一個領域都去深挖，不耽誤本身時間嗎？一專多長是最好的方式。

 

      敏捷開發——項管知識與編程技巧

 

      慕課網：在您所擅長的敏捷開發方面，能談談您我的的一些觀點嗎？

 

      阿當：我以爲敏捷就像九陰真經，是武林至尊，並且分爲上下兩卷。IT人中，除了不多一部分人是在作「研究」，絕大多數人是在作「項目」，而作項目最重要的是速度，天下武功惟快不破，這個速度不只指項目的開發時間，也包括維護時消耗的時間。說敏捷是武林至尊，正是由於它其實就是在解決「速度」的問題。

 

      爲何說敏捷分爲上下兩卷呢？敏捷是個大話題，不少人直接把敏捷簡單歸類爲項管知識，我不太認同。項管只是上卷，而下卷是編程技巧。其中項目經理擅長的是上卷項管知識，而架構師擅長的是下卷編程技巧。只有上下兩卷都通讀了，敏捷才能發揮威力。

 

      敏捷價值觀——尊重與誠實

 

      先聊聊上卷項管知識吧，敏捷有不少方法論，這其中最知名的有xp極限編程、scrum和精益看板，特別是scrum，幾乎直接成了敏捷的代名詞。這三種敏捷方法論都遵循敏捷宣言中傳達的價值觀——尊重和誠實。聽起來好像和編程關係不大，其實對編程的影響很是大，沒理解這個價值觀，就沒辦法用好敏捷。

 

      工程師通常都不太關注和人打交道的經驗，注意力全放到了編程自己，而軟件項目管理則跳出了編程自己，管理的就是項目進度、需求溝通和風險控制，處理的就是人和人怎樣合做的問題。

 

      軟件工程之因此能造成一個學科，有多套方法論，正是由於它有它的複雜性，須要合理的方法來進行管理，而不是簡單的「有個監工」就能解決。很是多的公司裏，項目經理是根據「技而優則仕」提拔起來的。什麼「技」？編程技能。而編程技能和項管技能其實毫無關係。若是項目經理們不知道項目管理的方法論，也沒意識到它的重要性，想固然地覺得管理不過是「監工」，分配任務、開會跟進任務、壓時間點、加班。這樣的結果，每每是開發團隊內耗很嚴重，需求控制出問題，代碼反覆改，質量愈來愈差，加班嚴重，搞很差最後項目還延期，而團隊成員怨念很大。千萬別忘了「尊重」和「誠實」這兩個最重要的價值觀，不要去壓你的團隊，逼他們承諾他們本身也沒底的時間節點。只有重視人性，把人當人，而不是代碼機器，才能玩好敏捷。去「幫」團隊，而不是去「管」團隊。

 

      不要小看項管知識，沒有系統學習方法論的同窗，真的須要好好學習一下。就從scrum入手，以scrum爲框架，而後再補充些xp極限編程提倡的實踐，好比結隊編程、持續集成、每日構建。TDD的話，要看狀況，若是項目規模很大，推薦使用，不然不建議使用。TDD的成本有點高，對於中小項目來講，性價比不高甚至得不償失。通常的web項目，規模其實都還好，代碼可能都在萬行之內。我以爲十萬行之內的代碼規模，作TDD可能都不划算。

 

      敏捷項目管理最大的問題，可能出在「說服領導」上。據個人經驗，絕大多數老闆不懂敏捷，也不認同「人性」管理，認爲管理就應該「加班」「壓時間點」，習慣「我給你定時間交貨，過程我無論」，看到團隊不加班就慌了，看到團隊熱火朝天加班就感到踏實。面對這種老闆，說服他接受敏捷的價值觀和方法論，比較困難，而若是說服不了老闆，敏捷就很難推行了。

 

      敏捷理念——迭代與代碼質量

 

      再說下卷編程技巧。敏捷有一個很是重要的理念就是「迭代」，不一樣於瀑布式開發，一次性設計、開發、測試完成，敏捷講究把項目分爲多期，先把最核心功能開發完成，而後通過多輪迭代，漸漸完善產品，產品永遠沒有「完美」的時候，而是經過迭代逐漸趨於完美。

 

      迭代在代碼層面意味着什麼？極可能意味着「重構」和「擴展」。因此代碼的架構設計好很差，可讀性、擴展性和重用性好很差，每輪迭代後，代碼有沒有變腐壞，決定了項目可否很好地進行「迭代」工做。若是代碼質量不高，極可能「重構」就變成了「重寫」，「擴展」變成了「複製代碼，repeat yourself」。這樣，隨着迭代的次數愈來愈多，每輪迭代的時間會愈來愈長，需求會愈來愈難以響應。若是不能控制代碼質量，保證代碼的可維護性，使用敏捷還不如使用瀑布。也就是說，保證代碼質量，是實行敏捷項管的基本條件。

 

      如何保證代碼質量？這裏面其實有不少學問，好比如何命名、如何組織函數、如何進行面向對象設計、如何分層、如何寫註釋、如何重構代碼、如何下降耦合、如何提升可讀性等等，這其中都有技巧，而很不幸地，我發現大多數工程師不太關心這些技巧，只關心底層又新增了什麼api，是否又出現了什麼新框架新工具之類的。他們其實錯過了很是重要且實用的知識。若是不具有這些知識，能寫出代碼，實現功能，但很難寫出高質量的代碼。

 

      其中緣由不能徹底歸咎於工程師。據我所知，大多數作web開發的工程師，不管前端仍是服務端，接觸到的需求都比較簡單，對「設計」的要求並不高，基礎上能達到「重用」和「團隊合做不產生衝突」這兩個要求就夠了。這和web site這種產品形態比較簡單有關，或許等到SPA這種產品形態普及的時候，如今這種狀況會迎來較大的變化。如今html5遊戲就是SPA的一種流行的應用方向，將來還會有更多其它web app的形式出現，到時前端工程師們的差距會拉開，就像如今不少前端作不了html5遊戲同樣，不提升本身的編程技術，將來會跟不上的。

 

      總而言之，敏捷是個集項管方法論和編程技巧於一身的領域，在我眼裏，它是九陰真經同樣的終極追求，每一個工程師都應該去學習一下。