Java 專案思考總結

前言

今天是2017年3月25日，筆者已經畢業半年，工作經驗一年。
正好有心思寫這個總結。

持續開發

對於Java專案，我所接觸的一般就是JavaWeb專案和 Java Jar後臺程序專案。
一個專案要想健康持續開發和維護，那麼就要儘早設計好，編碼按照規範，切忌不要偷懶圖便利，先完成功能再後續優化這種思想要儘量避免。

當你做這個專案完成的時候，會切換到別的專案開發，當這個專案有新的開發需求的時候，再回頭看自己的程式碼，可能有兩種感受：
1.

我擦，這個居然是我寫的程式碼，這麼爛，這咋改，不敢動啊。

2.

我擦，這個居然是我寫的程式碼，居然這麼清爽，不忍心寫亂了。

所以，為了以後的持續開發和維護一開始就認真寫好，即便是要交給下一個人，程式碼質量還不會腐壞。

以後等於永不

Later is never.

軟體開發有這麼一句話，留著以後做，等於永遠不會做。所以要做就趁早。要做就給後面做好鋪墊。

編碼

模型Model

對於Java使用的比較多的是Spring框架，配合Mybatis。我見過一些程式碼，為了簡便，直接使用List<HashMap< String, Object>>
作為Mapper介面的返回。
這樣寫是毫無問題的，剛畢業的時候看到專案(十年前的程式碼都有的那種)裡面都是這樣寫。
但是這種寫法儘可能要避免。
MVC中的Model幹嘛用的，就是對資料建模用的，現在有Mybatis生成器，直接生成Model，用getXXX()

上下文Context

對於業務總有一個粒度，或者說某種維度。比如以城市為維度。那麼在業務程式碼裡面，要經常使用要這個維度變數。然後幾乎每個方法裡面都會待著這個變數，(...Integer cityId)。這種變數少還行，但是加上方法本身的變數列表，就超過3，4個了。。有點長，不優雅。

為何不定義一個Context。這個可以是個簡單的POJO，把你常用的變數放在裡面，在業務起始的地方初始化，然後進入各種流程，都可以使用這裡的變數，全域性共享。沒什麼安全性需要考慮的，自己的程式碼自己負責。
我一般定義一個BusinessEnv的類，存放當前的業務環境資料。比如cityId，cityName，No，Number一類的東西。比放在Map裡面優雅。
這樣寫還有一個好處，就是改動比較集中，可以放心設定，不會有某些地方寫死了，不容易傳錯變數。

編碼風格Style

筆者回顧之前寫的程式碼，就像寫流水賬一樣，像瀑布流，一個方法幾百行，想到哪裡處理到哪裡。看了一本書，之後驚歎編碼風格的重要性。

寫程式碼就像寫文章那樣，一個一個的自然段那樣，行文流暢，結構清晰，那才是好程式碼。自己改也方便，也方便交給別人，很靈活，可插拔。

編碼的過程中，不是一次就能寫出這樣完美的程式碼，那麼在推進的過程中，你可以慢慢優化，慢慢就成型了。界限，梗概，脈絡都會清晰起來。

這時候，可以做一步小重構了，把程式碼重排一下，就像寫文章的排版一樣。
如下圖所示：這是一個主程式，優化之後的程式碼，不敢說這個多好，但是結構還是比較清晰的。先拿到維度的配置，然後構建Context，然後初始化一些東西，然後prepare some data，接下來sendGoods，最後更新什麼東西，然後backScan乾點事情，最後clear Context內容，清除資料，釋放記憶體，以幫助GC回收垃圾。

一開始是一大片很長的，此專案雖小，寫一個檔案裡是可以的。但是一個方法巨長。然後就是每一個步驟的業務，像是Pipeline一樣，也可以說是單一責任，一個業務模組處理一件事情。每個模組又可以拆分更細的模組，由淺入深，保證每一塊都是先梗概，後細節。

像這樣，這個方法裡，一行處理一個事情。

待續….