閱讀和實踐是最好的老師

這是這幾個月來最深的感觸了。

講幾個故事吧:

第一段故事————學習WEB開發。

今年的4月份，我剛從新浪Qing離職，回學校潛心讀書。
有一天碰巧看到有個比賽，HTML5的，一直感覺這是個不錯的方向，就去參加學習一下吧。
於是找了幾個同學組了個小隊，專案就開始了。
關於做什麼，我們選了近一個月，最後決定做一個畫素主題網站。
一來覺得會簡單一點，二來畫素，8bit，這可是數字和藝術的完美融合呀。

簡單介紹下隊伍情況：

我：產品還行，技術麼簡單的WEB技術略懂一點點。
小越越：前端出身。
璇爺：WEB開發經驗 === 0,其餘都還行。
野哥：做過OPENGL和一堆其他東西。

於是決定我去做產品和後端，小越越和野哥去做畫素作品製作功能的實現。璇爺去做UI和部分前端。

這裡插一段吧，

我們準備做個2D和3D兩個版的,但是商議的結果是用Three.js來實現3D版，然後通過改變視角和互動來轉化成2D版。
當時以為這麼做可以降低開發成本，而實際上我們通過調整3D版來展示成2D版導致了2D版效率過低，然後各種BUG頻現。
最後我們還是用canvas重寫了一遍2D版。這是我們整個過程中犯的比較嚴重的錯誤。
其實在open party上吳軍老師說過：

Tip:正確的模型可以很輕鬆地解決問題。  
如果選擇了錯誤的模型，就會一直選擇各種方式來補漏洞，最後直到補不下去。  

現在看來實在是太對了。所以各種噁心的解決方案基本都是不可取的。可能現在它Work了，但是會給你以後的工作帶來各種各樣的麻煩，最終把你弄得Work不下去了。

回來，繼續講。

因為我之前只用過PHP，而且是無框架純手寫。
這一次的專案有點大，所以還是仔細地考慮了這個問題。

於是我去問了luin神，當時推薦了Yii,Bootstrap。

Tip:當你對一個領域知之甚少的時候，詢問領域專家可能是最好的一種方式。

之後我就去了解了下Yii和Bootstrap，瞭解的方式就是去知乎、百度、google、然後對應的社群什麼的。

Tip:想快速知道一個東西怎麼樣，谷歌，論壇，github，問答網站是最好的選擇。

發現Yii的入門成本有點高，感覺短時間內上手較困難，然後又去多方打探。 最後後端我選擇了CI框架，原因是文件全、上手快。Bootstrap的確很好用。

Tip:專家推薦的東西的東西一般都是好東西，但是適不適合你就不一定了。

之後開始學習框架使用，就是跑跑DEMO隨便寫寫。一個星期左右，大致明白怎麼回事了，開始用來實現專案。 不過情況變得很糟糕，進展很慢，有一個巨大的阻礙擋在我面前，就是追求完美、總想要一步到位，於是各種對於現在階段沒有絲毫意義的設計充斥著整個大腦。後來發現與其費勁腦子做設計，不如去實踐遇到的問題，然後解決問題。

Tip:不要過早設計、優化。使用者量1W的時候想1000W的事是沒有意義的。

我是先學習前端，隨便練練手，剛開始做出來的東西就當做了個原型，對於產品設計的輔助效果的確很好。
然後學後端，先寫一些簡單的功能，驗證下自己對框架功能使用的是否正確。基本都是小步快跑。

Tip:跑的太快容易扯到蛋，絕對的真理。

之後又寫了很多小專案來練手，就這樣慢慢寫到了6月份。
基本我已經成為是一個比較成熟的Codeigniter和Bootstrap使用者了。然後》》》

第二段故事————一次“敏捷”實踐

6月份本來計劃進行一下重構，開始思考設計模式，開始接觸RESTFUL。
想要搞RESTFUL，主要由於MVC三層C層和M層放什麼我總掌握不好，最後乾脆C層就是把資料傳給V層，不過這樣M層又有點亂。如果再加一層API層，問題就好多了。而且當時心想以後還可能跨平臺多客戶端呢。 用RESTFUL，這樣以後寫其他平臺的客戶端也會好乾很多。 萬幸CI對REST支援很好。。。接下來就是重複實踐跑DEMO學習了。

突然噩耗呀，學校軟體工程過程課要搞敏捷開發實踐。。。打亂了整個專案計劃。

Tip:專案風險無處不在，做好預案降低風險。

實踐這個事說起來很無語，10多天？敏捷開發？語言不一樣？平臺不一樣？XXX不一樣？怎麼能夠在一起。

考慮到這種惡劣的情況，我們自己組了個隊，清一色的MAC，技術水平也都很好，自己熬幾天寫完整個專案都不是問題。然而不幸被不知情的老師拆散了。

不過還好最後分到的隊裡的技術水平都還不錯，就是大家習慣的語言平臺不大一樣。還好沒有windows。 隊裡一個前端大牛、一個伺服器大牛、一個後端前端都微懂的小菜鳥就是我。其餘的都各自會點不相關的。

講下我們實踐時專案使用的技術吧：

後端 CI REST ,我鼎立推薦，主要是因為自己很熟悉，很清楚能告訴其他同夥怎麼用。另外大家都會的也就PHP。其實後來發現會的最多的是python只不過有的人沒說。。
前端 Backbone Coffeescript Less Bootstrap 還有各種自動化測試的東西。

大致的過程

後端
———————
後端是我負責，6人小組，3臺MAC做開發機，自由結隊開發。 情況3個人一天集訓後，可完成開發任務。另三人，一人有事長期不在，另兩人配ubuntu開發環境數天。。

Tip:統一的開發環境是團隊開發必備，即使大家都用MAC也該配虛擬機器跑統一的開發環境。

之後專案開始進行開發，發現開發過程中會遇到很多一樣的問題，所以大家就去維持了一個問題WIKI。

Tip:團隊的問題WIKI可以省去不少重複性勞動。

團隊的版本管理是用git，以前我也沒接觸過git，隊裡好多人對git也不熟悉。因為只有10天時間，所以開始我覺得git不是很必要的。不過後來見識到了git的好處，決定還是要推廣一下。不過其實到專案結束，我們的git工作流也不是很規範，不過這種嘗試還是很值得的。

Tip:git是個好東西。

之後程式碼寫了快5天了，由於大家的程式碼風格不一致，還有好多是第一次用這個框架， 所以程式碼質量很低。於是我開始了重構。熬了一晚上，重寫出了APIv2版。對編碼風格做出了一定的規定。

Tip:統一的編碼風格對於專案是很重要的，要不然看別人程式碼會是一件很痛苦的事。

V2版的API開發後，程式碼結構清晰了很多，大大提高了後來的開發效率。

Tip:要樂於重構，並且重構前要想想為什麼要做這次重構，這樣可以更好的重構。

後端基本情況就這樣。
前端
———————
前端情況就不大好了，除了一個前端大牛、一個會JS的，其他兩人沒有WEB開發基礎。
所以less\coffee\backbone什麼的徒增了很多煩惱。
大牛又因被安排講自動化測試，導致真正寫邏輯的就一個人，還是剛接觸coffee的。
現在想想這個技術方案真是不大合適。這就是大跨步容易扯到蛋。

Tip:選擇適合團隊的技術解決方案，一下推給團隊一堆陌生的技術風險，風險太大了。

其他
———————
在整個開發過程中，其實好多問題並不是技術能力上的問題。

Tip:《佈道之道》、《敏捷無視》這兩本書一定要看，我反思整個過程，受益良多呀。

然後吐槽一下整個專案過程中，使用了好多東西，什麼看板、什麼心情圖的。 這些東西有些覺得有用，有些就有點形式化。 其實東西有沒有用，要看你在什麼樣的團隊，乾的是什麼事。 把寶貴的精力放在最有意義的事情上才是對的，別的都是扯淡。

第三段故事————個人開發階段

放假回家，開始對之前畫素專案進行大規模重構。 不過很快陷入了過度設計的困擾之中。然後就停了一陣，看看書，玩玩伺服器，把開發的腳手架搭好。

整理了下本地的開發環境，將本地專案的訪問方式設為真實域名，通過修改hosts檔案來切換線上和線下。主要是為了解決用到很多外掛跟域名有關的問題。

在linode上配置好git，本地寫好程式碼push至github，然後在linode上pull下來，簡化部署操作。

將資原始檔移植到阿里雲OSS上，這樣前端後端就嚴格分離了。前端用一個.html就可以進行開發，合程式碼的時候改動量大大減少。

還有一個體會很重要。

Tip:單執行緒地做事。

因為伺服器、後端、前端很多事，有時候自己一個人忙著忙著就都亂了，所以一段時間只幹一件事，可以是完成一套功能、可以是修改前端的整體樣式程式碼結構。

8月多的時候，覺得畫素專案要來不及了就開始涉足canvas部分。 我自己一直對JS有點恐懼，莫名的恐懼。等到自己可以做點什麼東西出來的時候，這種恐懼自然而然地就消失了。

Tip:其實克服心中的恐懼，投入一定的時間，不斷地去實踐，一切都會相當地容易。

這個過程還可以總結幾點出來:

動手做學得最快。
獲取知識要有選擇。
解決問題最重要。

這裡還有個問題，我開始不懂JS就盲目地寫，寫出來的東西也亂七八糟各種BUG。其實這是一個好事，出現問題，解決問題，然後你就學到了有用的新知識，這比無謂地看一堆可能一輩子都用不到的東西要好很多。不要怕寫錯、不要怕浪費時間在一些你覺得很SB的問題上，其實這可能是最有收穫的事情。

分割線

以上純按時間順序整理了自己的一些收穫，看法。看上去基本都是在講實踐，彷彿沒怎麼說閱讀。
其實閱讀和實踐是融合在一起很難分離的。 通過閱讀書籍、手冊、文章可以讓你瞭解一些大概，這些大概就是實踐的基礎。
而在實踐之後，再閱讀，來反思實踐，就可以加深對讀到東西的理解。 加深理解後，我們又可以去更好地實踐，反覆迭代就是一種良性迴圈。

保持實踐和閱讀的習慣，這些習慣會成為最好的老師。