無味雜談

    距離上一次寫博客過去了很久，今年伊始帶人作項目（我也菜。。），發生了不少不少事，可貴偷偷請假放鬆一天。

    感悟分三點：對REST的理解，對項目的理解以及對管理的理解。

    （1）對REST的理解。

        第一次據說REST是在去年秋天。準確的說，當時項目要求是用Web Service實現一個文件自動傳輸功能。這個功能很好說，簡單的描述就是一個‘數據庫+存儲文件的文件夾+一個相似於windows服務的服務’。講真，我找相關資料找了好多，仍是沒有理解Web Service。此時大佬說準備採用Apache Axis2，那就研究一下咯，一段時間後對它的初步印象就是一個RPC，然而因爲功課緣由我也沒有深刻研究Axis2（不是藉口。。。）。

        上一學期過得很快，奔波着考試吧唧吧唧的，就完了。在考完試後，仔細研究了一下RPC，大概知道了它的運做方式。

        RPC與XML可謂是天做之合。XML能夠完整的描述一個信息，RPC經過XML，把須要調用的服務器的方法和請求的數據所有封裝到XML裏面，舉個例子。

<xml>

<method>getSinglePerson</method>

<argument>personStaffId</argument>

<require>personUserName</require>

</xml>

        固然這個例子是隨便寫的，只是想解釋如下XML能夠清晰的說明想要進行什麼操做。這也體現了XML比JSON可讀性好太多。據悉不少企業應用仍是使用RPC傳輸方式了，不過前景嘛，固然是下來會出場的REST。

        REST，這裏我就不粘貼那麼多概念了。菲爾丁博士的論文，看的似懂非懂。簡單的來說，REST中文譯名爲表述性狀態轉移（腦中出現了狀態機。。），其實我感受，只要理解了HTTP，就能理解博士所說的HTTP，畢竟博士參與了HTTP規範。

廢話好多，如下正經起來。

        HTTP中，最精華的規範爲「把一切看成資源」。咱們用瀏覽器瀏覽頁面，頁面是一個資源，而相似於天氣預報的數據也是資源，只不過由於頁面被瀏覽器解釋了，呈現給咱們的是視圖，而單調的數據沒有視圖。

這就讓咱們加深了對HTTP的認識，之前我認爲HTTP是爲瀏覽器服務的，即HTTP是瀏覽器與遠端服務器進行通訊的協議，而HTTP，其實也是一個動詞，即傳輸資源的動做。就如上面段首所言，一切都是資源，HTTP把資源傳送到本地。還有，HTTP使用很普遍，並且這麼多年沒出現什麼大問題，也證實當初的設計是很是正確的。

        理解了‘把一切當成資源’以及‘HTTP是動詞’，而後就來說述爲何REST很符合將來的趨勢。今天中午看了一篇文章叫作「谷歌發佈雲端API規範」，打算用REST來替換RPC，雖然還須要假以時日，可是趨勢已經顯現出來了。爲何REST好呢，舉個例子，就好比最近在搞的一個重構項目，把本來用傳統Struts2+Hibernate實現的項目重構爲RESTful的，爲何要重構？好比，咱們計劃在其中開發一個Android APP，但是按照之前的方式，須要專門開發一套與Android通訊的系統。這樣浪費時間和精力，而且之後維護的時候須要同時維護Web通訊系統和Android通訊系統，想一想就麻煩。。。企業是在合法的狀況下追求利潤最大化的，在之後升級之時確定須要完全重構減小成本。

        尚未講到REST的好處，REST的縮影就是HTTP。把一切看成資源，把一切做成服務。我理解服務爲24小時不間斷的函數，給你一個輸入，返回一個輸出。並且這個服務，是無狀態的。爲何要作成無狀態的，衆所周知，HTTP也是無狀態的，只是傳輸，不在意你的狀態，而且底層是TCP/IP協議。無狀態很好的把前端後端解耦。舉個例子，最近在設計RESTful API，但是我一直想不通前端怎麼接受呢，，，若是要按照MVC的思想，，，終於有一天，幡然醒悟，原本考慮的就有問題，我是要把它設計成無狀態的，那我爲何考慮前端的問題呢，這樣設計的API就不是REST風格了！而後又想，若是按照MVC方式，至關於客戶端把會話狀態（我理解之爲前端和控制器耦合，，不知道對不對啊，，，大神請指教）傳輸過來，這樣我就考慮幾個問題了，這樣也不屬於REST了，因此都錯了！！！

        又扯了一段，咱們假如把全部數據設計成資源，就像HTTP同樣，那麼咱們不就用一套通訊方案就能夠了？例如須要獲得庫存信息，API爲getStocks（），APP能夠調用此方法，PC能夠調用此方法，這不就縮減好多成本了嘛？咱們只須要告訴其餘開發人員我這個格式就能夠了阿。

        理解了統一接口，而後就是理解URI。就像HTTP同樣，資源都有一個地址，例如localhost/index，在這個地址背後就是一個資源。咱們把REST設計成一個個的API，是否是也能夠經過資源定位符來定位資源呢？固然能夠啦，咱們也能夠用URI來標示資源阿？（URL是URI的子集）其實這點不嚴謹，動做+資源才能惟必定位資源，爲何？對資源的操做無非幾種而已，GET，POST，DELETE，PUT，還有OPTIONS詢問操做方式。

 

/*********************************************/

今日更新

        說到這裏，能夠引申出REST的真實用途了。把一切當成小小的服務（暫時沒有研究過微服務，因此叫小服務）。REST的真實含義是提供統一的訪問接口，不管客戶端仍是手機端，統一訪問這個接口獲得相關的數據（我目前將數據例如list或者object所有格式化成JSON），客戶端只用解析相關JSON,而後就知道你請求獲得的東西了。爲何不用XML？XML太大了，可讀性好可是傳輸效率過低。

        REST這種風格是爲了什麼呢？是爲了訪問的便利而已，你的業務邏輯仍是那樣的邏輯，只不過對其餘人暴露的接口獲得的都是JSON等等，統一了風格。例如你進行查詢操做，後臺依然是「查詢數據庫+返回結果」，惟一的區別就是可能像我同樣用FastJson將其格式化爲JSONString，而後傳輸給對方。固然，資源的訪問方式也不太同樣，通常使用URI來標記資源的位置。

        我感受這些東西就是REST的思想子集，，，目前開發遇到了一些例如資源設計的問題，例如數據庫表與資源之間有些耦合，資源設計沒有很明確很易懂。項目計劃月底完工，完工以後給你們分享最後怎麼設計的。

 

/////////////////////////////////////////

關於對項目的理解

        軟件工程最大的風險在於沒法真正控制其風險，當咱們認識到風險的時候，基本快晚了。。。---Shual Liu

        本人經歷過軟件的腐爛，深有體會。鄙人也開始感受寫代碼只是很小一方面，如何保持團隊協做，如何保持軟件規範，以及如何設計可複用的軟件，各個都是學問。

        在如今文明中，不多能見到一人獨立完成一個項目了。集體的力量更大，我時時在想，我不能認爲本身以爲他們進度太慢就全盤包辦代替了，這是不對的，更好地方法是讓他們每一個人多產出20%，這樣本身能夠把更多的時間花到設計上，以避免後來會出現架構級缺陷時爲時已晚。

        在現今這個小團對中，產出效率很低，大部分人沒有學習過集合，設計模式等東西。隱隱約約感受很棘手，由於很擔憂代碼質量不達標，但是事已至此，又該怎麼辦呢？還記得頗有印象的一句話，軟件永遠不是完美的，只能一步步讓它完美。其實在有限的時間內作出來一個基本趁心如意的，已經很符合個人指望了。

        其實說到底就是規範的問題。就算他不好，有了規範，也能一步一步寫出差很少的代碼。鄙人前幾天詳細講述瞭如下命名格式，包管理，源碼註釋，源碼頭文件註釋等等，在規範之中進行（目前沒看到效果呢。。。）

 

   //未完待續