當我們沉浸在旺盛的需求之中時，整個人便會成為一台工作的機器，切著類似的頁面，寫著同樣的邏輯，重複著昨天或者上個月做的事情，時間久了，覺得膩味，沒有什麼創新，也沒有明顯的成長。用一句通俗的話來講：工作五年，後面四年重複著第一年的活兒。
很多人嘗試跳出這個怪圈，不過基於環境壓力和思維受阻，最後又不得不選擇放棄。今天想通過介紹如何高效有保障地開發乙個無線頁面來幫助大家找到突破口。
很多無線頁面的開發有兩種模式，一種是後台輸出 json 資料，前端根據資料來渲染頁面（同步模式）；第二種是前端非同步載入後端資料然後渲染（非同步模式）。當然，兩種模式夾雜在一起也是存在的，這種情況一般會有乙個由前端控制的中間層提供同步資料和非同步資料。為了減少前後端的溝通成本，往往採用第二種模式。
拿到設計稿後，與後端同學約定介面格式，讓後端同學盡快提供 mock 資料，如果提供不了，便自己構造測試資料。接著回到自己的工位上切圖，切圖過程中會解決好響應式問題和相容性問題，待到後端產出真實資料時，更換 js 中的介面位址，聯調 ok 便發布頁面，大功告成！
整個流程很順暢，這對乙個工作了三四年的程式設計師來說，沒有任何壓力便完成甚至提前完成了任務。但是，回過頭來想一想，整個開發過程中我們留下了什麼？沉澱了什麼？
對於上面的開發流程，先提出幾個常見的問題：
上面提出的幾個問題，列的不全面。有一些可能是你經常碰到的，甚至有了成熟的解決方案，而也有一些問題可能是你從未考慮過的。
我們把整個前端開發流程做簡單切割：切圖、獲取資料、渲染、事件繫結、資料統計、頁面優化、監控。這種切割很暴力，也比較粗糙，不過它不妨礙我們在下面討論，作為前端工程師，除了完成日常需求外，還要做什麼？還能做什麼？ 切圖
隱約還記得三年前，我接了乙個無線頁面的外包活兒，頁面的結構很簡單，但我做的很糟糕。為了適配不同尺寸的機型，我寫了無數 media query，加上當時採用的 em 作單位，很多細節位置都沒控制好。
回到現在，已經有了很通用、主流的方案——使用 rem，動態計算 html 標籤的font-size，思路很簡單，但是存在不少的坑，和一些較難理解的概念，google 搜尋下lib-flexible能夠找到這些問題以及解決方案。不過我們切圖時還可以思考一些其他的問題：
以上問題，沒有哪乙個會讓人特別苦惱，但是堆積起來，卻讓我們的開發效率和開發體驗落後了好幾個檔次。這些問題並非無解，我們可以嘗試著幫助同事和團隊找到問題的答案，比如：
有些解決方案只需要幾行指令碼就能搞定，而有一些可能需要投入時間和精力。
獲取資料
可一旦與後端約定的介面有變動，本地 mock 資料也要跟著一起變動。這個問題有什麼好的處理方案？在團隊中，好的方案一定不是幾行文字的提示或指引，而是通過流程和監控來控制！
這裡提到的獲取資料，細想之下可不是什麼輕鬆的事情。有很多問題需要思考：
以上每個問題都有很多處理方案，而這些問題不僅僅是自己會遇到，身邊的同事也會遇到。如果可以站在團隊的角度去思考問題，很多思路會比較容易湧現出來，比如：
資料是最容易出問題的地方，每乙個介面請求都需要一大堆的邏輯處理異常。倘若介面格式、開發流程和前端模式都可以規範化，我們需要做的就剩下套公式，這種高效你能否想象？ 渲染
大膽地揣測下大家在寫乙個模組的時候，跟我一樣也是這麼劃分的函式：
1234567
891011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
44
var module = function() ;// 初始化
module.prototype.init = function() );
};// 繫結事件
module.prototype.bindevent = function() ;
// 獲取資料
module.prototype.fetchdata = function(cb) ).then(function(data) ).catch(function() ).fin(function() );
};// 渲染資料
module.prototype.renderdata = function(data) ;
// 處理資料
module.prototype._resolvedata = function() ;
// 載入失敗
module.prototype._fetchdatafailed = function() ;
不管乙個模組有多麼簡單，它基本都會包含以上步驟，倘若沒有用函式隔離每步操作的意圖，**會顯得十分散亂。我經常看到，有同學把「渲染」這一塊的**被放到「獲取資料」甚至是「初始化」中，這種程式結構顯然是不合理的。同時，也經常會看到渲染時，
以上，沒有哪一種是不正確的，我也沒有對哪一種寫法開噴的意圖。但是至少我們可以在多次程式設計經驗中提煉出一些有價值的內容：
有乙個可執行的編碼規範，加上適當合理的 code review，整個團隊**便會如出一轍。
以上問題，都有相當成熟的解決方案，那你們團隊呢？
當發現工作做起來索然無味的時候，我腦海中蹦出來的第乙個念頭是：最近是不是有點放縱了？
前端雜燴 在工作，在思考，在沉澱
當我們沉浸在旺盛的需求之中時，整個人便會成為一台工作的機器，切著類似的頁面，寫著同樣的邏輯，重複著昨天或者上個月做的事情，時間久了，覺得膩味，沒有什麼創新，也沒有明顯的成長。用一句通俗的話來講 工作五年，後面四年重複著第一年的活兒。很多人嘗試跳出這個怪圈，不過基於環境壓力和思維受阻，最後又不得不選擇...
在時光的沉澱下
友人問 幸福嗎？仔細想想，應該是幸福的，因為幸福從來不是因為你擁有的多少，而是，與已擁有中，是否感知到了快樂，感知到了豐盈而滿足。那些尋常的，擷手可得的溫暖中散發的光豔灼灼之美好。其實，最好的人一直都在身邊，最好的溫暖 顯赫植髮一直都在心裡。有人牽念就是幸福，被人掛懷就是溫暖。愛是相互的，給與的同時...
工作在微軟
前一段時間應邀寫一篇關於 windows 核心研究方面的文章，發表到 msra 在sina 的blog上 正好借這篇文章的名義介紹了 windows 核心原理一書。實際上，我最初的版本中引用到了下面一幅圖，體現了微軟在各個領域中與其他軟體廠商或組織的競爭關係。這幅圖來自 可惜2006 年以後沒有再更...