一份從 0 到 1 的 Java 項目實踐清單

看了一篇文章，感受還能夠，就給你們共享一下：

對於着手一個項目的時候，要從如下入手（即項目清單）：

1. 項目規劃

1.1 首先，你得完全明白到底要作什麼？

這個過程，多是你要讀需求一遍、兩遍、三遍。。。 而後假設，你已經在使用這個產品了。

1.2 其次，明白需求後，就要進行總體框架的構思！

好比用什麼呈現給用戶，用什麼來存儲數據，須要些什麼樣的系統等。

在這個層次上，通常都會遵循公司的規定，而後再根據項目自己需求，作些相應的調整。

咱們在這個項目裏的總體框架爲：前端使用 APP(ios&android)、H5進行用戶界面呈現 ===>> 接入網關進行數據加解密，流控轉發等 ===>> 第一層API服務，接受客戶端請求，作簡單業務檢驗組裝 ===>> 第二層核心業務SERVICE服務，進行核心業務處理，如寫庫、調用第三方接口等 ===>> 最下層基礎服務，提供單一的功能服務，如消息服務，訂單服務。

前期只提供APP，所以不存在單獨H5調用API服務的狀況，可是H5的應用場景仍然存在，此時的H5地址，由服務接口提供地址返回到APP進行webview加載。

1.3 人員規劃

項目總體框架出來後，得要有人去實施才行。

這裏通常須要遵循一個最小原則，即劃分出的人員，儘可能作到可以獨立完成自有的模塊，而不是必定要依賴於另外一方的實現才能進一步。好比 android,ios各一人，API與SERVICE能夠多我的，可是都要讓其有所有權限，由於API與SERVICE有強依賴，脫離一方，將沒法獨立完成。基礎服務各自安排相關人員實現。最後進行聯調便可。

1.4 時間規劃

有了人員以後，也不能無限時間的去作事。確定是要規劃的，不然沒有壓力也沒有動力。項目不知什麼時候才能結束。訂時間計劃必定要去詢問當事人，要多少時間，儘可能站在專業的角度給出合理的建議和評估。促進項目的完成。

2. 框架規劃及搭建

2.1 有了總體框架的構思後，就要細節到每一個層次的實踐了

由於都是應用的分層，因此，不可能有統一的描述，只能是針對每一個應用層。作本身該作的事。如 android/ios 有本身的開發框架；h5有本身的開發框架(由於不少應用場景可能涉及到h5與app原生的交互，因此即便功能簡單，也儘可能利用一些已有的框架進行開發)。

而服務端，雖分爲多層應用，可是應儘可能使用同一門語言，利用同一套開發框架，本身公司有研發框架天然最好，沒有也儘可能利用統一的開源框架。這樣作的好處是，當有人員變更時，能夠當即熟悉其代碼及應用場景，從而增長適應性和管理性。

針對服務端的框架，我以爲有必要多說點。由於整個應用運行的流暢性，可靠性，準確性，都是由服務端來決定的。雖然用戶看到的是APP或者H5，可是能夠說，服務端纔是應用的核心。因此，服務端要作的事情天然不少了。

2.2 怎樣搭建好一些服務端的框架呢？

首先，框架類的東西，天然是要提早學習的。可是，就目前市場行情來講，要想利用框架應該都是比較簡單的，尤爲是公司內部提供的框架，必定要有demo。這樣，照着demo，一步步調試，直到整個應用接通；

刪除不須要的模塊，添加特別須要的模塊，保證在具體開發過程當中，可以想利用啥就有啥可利用；

充分了解框架須要的一些配置參數，知道事務從哪裏來，到哪裏去？這裏，應有一個配置中心與之對應，可是本身得清楚。

使用一個順手的IDE工具，不是說你技術不夠牛逼，而是一個好的工具，可以讓你事半功倍。（其實可以多背點套路，也不必定非要體如今正式項目上）

寫出第一個可供使用的接口服務，能夠說，第一個永遠是比較重要的。由於，第一個的思路，就是你後續全部功能的方向，所以，寫好第一個」hello, world.」；

3. 開發環境的搭建(服務端)

3.1 其實這項工做是及其重要的，之因此把它放在第三點，是由於，沒有代碼做鋪墊，開發環境搭了也沒用。

3.2 開發環境的搭建，主要也是服從於總體框架的構思。

主要包括，須要多少個服務，須要多少臺服務器，須要多少個基礎應用，須要多少個基礎配置等等。

固然，開發環境自己就是一個很大的難題，通常仍是交給專業運維幾十年的老司機來完成了。本身就看成了解得了。

目前的項目開發，除一些小規模公司還在利用一套服務端代碼，幹完全部的事外，大部分應該都是多個應用的配合完成。而測試環境，不太可能利用多個服務器提供服務。所以，使用docker進行測試環境搭建尤佳。創建多個docker進行多個服務器模擬，也算是和線上環境保持一致了。

目前的主流技術得用上（固然關鍵還得看你的框架規劃），zookeeper, dubbo, redis, mongo, mq, …

3.3 只有開發環境搭建好了，才能讓後面的流程無憂。搭建的過程必定是，又搭建，又改代碼，又排錯…

4. 進度的同步

4.1 及時向領導同步項目進度

對於一個新項目，有些地方行動緩慢是很正常的。而部分開發同窗（好比我本身），就喜歡沉浸在本身的小世界裏糾結，走不出來，從而忘卻向領導彙報工做。而做爲一個有點同理心的領導來講，他又不肯意實時都來盯着你作事，由於也怕你遇到困難，想多給你點時間解決。可是，這種狀況，開發同窗本身實際上是要吃虧的，由於，給外人的感受就是，你啥都沒作。因此，解決問題的同時，也不忘向領導彙報。

4.2 有處理不了的問題，及時向大牛們或者領導請教

獨立解決問題是好事，可是千萬別過了頭，實在解決不了，就要及時請教。不然，浪費的是時間。進步最快的方式，莫過於向比本身牛逼的人請教。知之爲知之，不知爲不知！

4.3 儘可能將問題分攤下去

問題確定是有的，並且會不少。千萬不要把全部的事情都壓在本身這兒，那樣本身會累死的，並且項目進度也會所以變得緩慢。要多利用小組成員的各自優勢，適當多讓其搞點事情。

工做永遠都不是單一的一件事，確定還會有其餘的事情插入進來，觀察事情的重要性解決。若是可以讓其餘同窗解決的，儘可能讓其餘同窗處理，這點也得與領導同步。不然分心過於利害，受阻的只有項目進度，延期可不是本身一人的事情了。

需求也不可能一下就是完善的，在作的過程當中，纔可能發現一些潛在的問題，這時及時與需求方溝通，保持高效的狀態。固然，後期的跟進，也是儘可能作到不要一人大包大攬，而是相應的人就去負責相應事情的跟進。其餘人只要知道結果就行。

5. 功能模塊的完成

5.1 說到具體的業務實現，我的以爲，已經不那麼難了。不過就是，先盡力提出的一個初稿，而後發現問題解決問題，發現問題，解決問題的過程。

5.2 各自系統能作的事情完成後，就是聯調各系統間的調用關係，保持高效的溝通，讓問題在短期內解決，尤其重要。在這種時候，我以爲，一個小黑屋也許也是個不錯的選擇。

5.3 聯調的過程，其實就是一個自測的過程，應把儘量多狀況給考慮到位。

5.4 代碼檢查，本身開發的代碼，基本上很難發現其中的問題，即時找到相應人幫忙檢查代碼，是比較好的解決代碼問題的方案。其實，在給別人檢查的時候，也是本身檢查的時候，至關於本身再一次的開發，也能及時發現問題。

6. 多輪的測試驗證

6.1 測試同窗，其實在開發快結束的時候，已經把測試用例給到你們。這也是另外一個角度的開發，所以，參考測試用例進行相應開發修改也是頗有必要的。

6.2 第一輪測試，可能主要是大功能的驗證，小功能的檢查，擋板環境便可，無需真實環境。

6.3 第二輪測試，則是要把以前的測試及各類配置，所有清空，以一個全新的項目來對待，從新進行相應環境搭建，代碼部署，而後再進行測試，確保問題解決後，作好了相應的處理方案備份。這時，就須要用到真實的應用環境了。對以前一些暫未解決的問題進行從新測試。確保無問題。

6.4 第三輪測試，應該是一個灰度發佈的環境，也能夠認爲是預上線。將全部環境看成是線上來處理，若是運行ok,便可準備發佈上線了。

6.5 在測試過程當中，因測試人員只是人工的處理，有時不必定能捕獲全部的問題，開發在這時，也應站在測試的角度，發現問題，即時監控，即時處理。

6.6 自動化測試，這個其實應該是靠後的處理，可是若是能作到這些的話，也可以快速的重現問題。

6.7 壓力測試，應對線上環境，需有必定的能力評估，否則，只瞎猜，恐怕也不是好事。隨時準備橫向擴展，也只是出現問題後的解決方案。作好壓測，發現代碼中存在的問題，即時處理掉。

7. 外圍處理(上線前)

7.1 上線前，確定是有不少事務要處理的。

• 測試環境中的各類基礎數據，隨時導出備份，到線上時，直接插入使用；

• 服務器，在架構評審過程當中進行數量評估；

• 域名，對外網提供服務必定是要域名的；

• 權限，好比上線後，出現了問題，誰有權限來處理問題，必定提早給到；

• 驗收，這是關鍵的一點，功能完成後，及時驗收，若是上線有些小問題，儘可能協商，不要在線上頻繁改動。

如此！整個項目就完工了。

其實發現，一個項目真正的功能實現，並無佔多大的比例，而是一些前期的準備及後續的處理，反而佔了更多的時間。

第一個版本上線後，可能接着就是迅速迭代了。（若是運營還能夠的話！）

以上，就是一整個項目的流程清單，以一步一個腳印的經歷總結，不涉及具體語言代碼，可是思路都是相通的，但願對你有幫助！