阿里巴巴Java開發手冊———我的追加的看法和補充（四）

前言

手冊在（一）中有原版下載，在（三）中有在線版本，建議對照手冊食用。

在本文發佈的時候前幾天好像阿里作出了修改，在（一）中的地址下載的版本爲1.0.2可能對一些以前的改動和修改。

本文依舊仍是針對1.0.0的版本寫的，不過出入應該不大。

有關編程規範（一）http://www.cnblogs.com/linkstar/p/6413402.html

有關異常日誌（二）http://www.cnblogs.com/linkstar/p/6415788.html

有關數據庫的（三）http://www.cnblogs.com/linkstar/p/6429770.html

該說的我以爲（一）裏面我都說完了，那麼就直接進入正題吧。

 

工程規約

對於工程來講，其實規範不少，細節要注意的地方不少，並且這些規範其實不少都不是我的本身學習的，而是看見別人這麼作，你也這麼跟着模仿，最終造成的，保持工程的統一不只是對於在編程的時候對可讀性有幫助，並且對於重構的時候，特別是對於非項目組成員來幫忙的時候有很大的幫助。

 

一、下面是手冊中給出的圖

這邊其實給的已經算很全了，不過根據項目的不一樣，裏面的層也會根據實際狀況進行刪減的，可是大體確定是這樣沒錯。分層的思想應該在一開始作項目的時候就很好的創建起來的習慣，而且須要一直保持。

下面就幾個層中比較難理解的進行說明。

1、開放接口層，PRC：不少人看見這個縮寫就懵逼了，由於沒見過，由於確實在簡單小的項目中不常見，RPC是遠程調用的簡稱，它是一種協議，若是很差理解，你能夠理解爲HTTP，這個用的多是最多的協議了，或者webService均可以，這些都是一些接口的定義，而PRC的好處在於，在一些分佈式的應用程序還有在一些不一樣語言所編寫的組件須要互相通訊的時候，PRC就頗有優點了。

2、終端顯示層，velocity：這個是一個工具，是用於輔助先後端分離：後端接口開發人員能夠專心於提供數據、前端人員可使用佔位符（模板文件）暫時代替數據。我在手冊前面就看見過，由於生成的文件後綴爲.vm，因此習慣稱爲vm，可能阿里的工程師用這個比較多。由於公司前端能力和人手不足，因此沒有用過，由於暫時先後端尚未作到徹底分離，因此如今仍是使用的jsp，若是有機會完成先後端分離的話會考慮使用。

3、manager層：說實在話，這層在咱們的項目中是沒有的，可是有和他功能類似的層，主要是用於處理緩存和第三方的。這裏手冊中說的特別好的一點就是對DAO的業務通用能力進行封裝，這對於程序員在寫代碼的時候思想的注意就有關了，我見過有不少厲害的人，封裝和共用的思想很厲害，不少時候他寫的代碼可能少，可是已經足夠用了。

4、DAO層：這裏主要注意的點是，緩存的數據訪問也是放在這裏的，我習慣把redis這種緩存的數據訪問也放在DAO，由於它也是屬於數據的存放和訪問。

 

二、這點和我如今可能有些出入，其1、我DAO是不拋異常給上層，咱們的原則是層的異常當層解決，出現異常後返回給上層應該是對應的錯誤碼和沒有查詢到數據的結果。其2、個人DAO是打印日誌的，由於在前期Debug的時候，DAO的日誌最能準確的定位到那一句sql出現了問題，而上層的日誌的話只是在業務邏輯上面出現問題的時候纔打印日誌。不過也只是做爲參考。

 

三、我在（一）裏面已經對模型都進行了說明，須要請在最上面的連接查看。

 

二方庫規約

首先解釋一些什麼是二方庫，不少人會奇怪這個名字。一方庫：本工程的模塊互相的依賴。二方庫：公司內部的依賴庫。三方庫：公司以外的開源依賴庫。

一方庫就很少說了，二方庫主要是我見過不少公司開發項目的時候，採用的是jar包的方式，不少模塊開發完成以後會打成jar包而後進行使用，因此須要規約。三方庫的話如今流行使用的是maven進行管理，後面會提到的。

而後裝了B以後趕忙回來，嘻嘻，本人尚未使用過二方庫，主要是考慮到幾個點，懼怕jar包衝突，這個真的很坑，在沒有maven的時候，每次導入jar的時候到會仔仔細細的，報錯以後也是不停的查，究竟是哪裏衝突了，因此歷來沒有使用過，給不出很好的建議和補充，可是這也提醒了我，以後會學習使用的，由於畢竟當項目大了以後封裝原來使用過的模塊能增長開發的效率。

 

服務器規約

我總以爲不知道是否是寫手冊的人有點偷懶了，仍是真的太多了來不及寫了，總之一句話，服務器規約比這個多的去了。。。我還很是但願有高級的服務器運維工程師來說講經驗，由於服務器這東西，哇塞，出的問題你沒有經驗真的很難解決。這裏我也只能就這幾點講講我所遇到的一些重要的，不能列舉出所有，本人畢竟經驗有限。

首先服務器的選擇：除非是。NET開發，不要用windows服務器，坑死你不償命。

服務器存放文件規則：前期必定要定義好文件的存放規則，由於不少人玩linux，真的是玩會的，裝不少軟件的時候都是爲所欲爲的放，這樣會讓後來維護服務器的人形成維護上面很大的困難，特別是當一些軟件的安裝路徑不一樣時，環境變量和配置文件也會變化。

防火牆：看到不少偷懶的，一上來就把防火牆關掉的數不勝數，別告訴我你也是，防火牆是能夠配置規則的，只要開放你須要的端口就能夠了，否則被黑是早晚的事情。

注意各類軟件的配置：不少軟件在服務器上面的版本是和windows默認配置差別很大，即便你自己的開發平臺並不是windows，仍是有差別，因此，對於任何軟件都請先查詢而且修改你須要的配置。這邊舉幾個例子，如tomcat，你須要配置項目路徑，端口，日誌。還有很容易忘記的JVM配置，手冊中也提到了，OOM這個錯誤有時是不會在項目的日誌中出現，而會在tomcat這樣的容器的日誌中出現，當項目的小的時候，默認的內存固然夠用，可是當項目大了以後，內存確定是不夠用的，當出現問題再去修改配置的話可能就晚了。

除非是測試服務器，正式服不容許出現任何測試性質的軟件或工程。因測試工程而致使主服務器宕機，那真是要不得的。

服務器權限：有能力最好作一下權限的管理，服務器權限分的細，這樣真正出現問題的時候纔好去追究責任，不是說必定要有人背鍋，只是不但願別人只是由於有了服務器的密碼而當替罪羊。另外，服務器的操做最好每次都有記錄。

文件的權限：linux文件的權限可厲害了，不要只知道777，有時候權限不夠會致使一些問題，注意就好。

注意備份：注意備份文件，數據庫等，在服務器上的數據都是很重要的，不備份，出問題，你找誰？

常常監控服務器：包括服務器的性能，日誌等各個方面，預防問題的發生。

都是比較大的點，細的我這裏就不一一列舉了，由於我也不是專業的服務器運維工程師，上面也只是經驗之談罷了。