個人終于第一次完成了一個java web項目從策劃到最終上線的全過程，雖然項目十分簡單，但全流程跑通的感覺還是倍爽的，之后再做項目則只是各個環節上的細化了。

現在我將我的“第一次”分享給大家

項目名稱：最美80周年，共同記錄

開發文檔：https://www.showdoc.cc/rucday?page_id=15376272

源碼地址：https://github.com/sunym1993/dataU-RUCDay.git

項目簡介：自己做著玩的一個項目，為某校80周年校慶準備的，頁面模仿微信聊天界面，用戶可在上面說話。

?

一、準備階段

服務器：阿里云服務器ECS（2核4G ￥825/年）

　　買了一年的阿里云服務器，個人感覺還是很值的，內部裝好了空的CentOS 6.9 64位 linux系統。首先第一步就是安裝java環境，以便之后我在上面跑的程序能夠運行起來。總結起來我需要jdk，mysql，redis。安裝linux系統環境每次都要查找各種教程，索性總結成了一篇清單文章給自己看：linux的java環境搭建清單

　　當然后續，還在阿里云買了域名，域名需要備案才能用的事，留在后面吐槽。

文檔管理：showdoc文檔，poccessOn流程圖

　　showdoc在線文檔清晰明了，很適合個人或者小型團隊用來共享開發文檔。配合poccessOn流程圖軟件（我買了專業版 ￥115/年），已經可以很好完成開發文檔方面的工作了。當然工具的選擇只是個人喜好問題。

代碼管理：github

開發工具：idea

　　應該是最智能的編輯器了，但我還是更佩服用notepad或者txt寫代碼的人。

開發環境：jdk1.8，mysql，redis，springboot

　　現在是springboot的時代咯，打成一個jar包直接就能跑web項目，也可以跑微服務，十分便于管理。

?

二、瘋狂打碼階段

　　?開發過程總結起來可以說很簡單，1、寫好開發文檔； 2、建好數據庫； 3、寫好代碼并打成jar包。描述起來真的特別簡單，而且基本都是這樣的流程。

　　困難之處就在于，開發文檔寫得糟糕，數據庫設計得糟糕，代碼總是出一堆bug。于是可能回過頭再改開發文檔，改數據庫。于是再次遇到開發文檔改得糟糕，數據庫改得糟糕，如此往復。最終的結論就是代碼越來越難以維護。所以如果不是在最初設計的時候就能預料到之后的各種坑，回過頭改則會越改越糟，除非推倒重來。

1.寫開發文檔

　　由于自身比較追求代碼的質量，實現所謂的高內聚、低耦合，所以在意識上還是很明白設計階段的重要性的，雖然后面看來一開始的設計簡直是糟糕透頂。

　　我給自己的原則就是文檔寫完之前一行代碼都不要寫，文檔寫好之后代碼自然就出來。雖然花了近一周時間在寫文檔階段（拋去上班時間其實就兩天），但仍然不夠，代碼寫到后面已經完全拋棄文檔了。我后來總結自己代碼時可以明顯感覺到，文檔中設計好的部分代碼還是很清晰整潔的，但其余部分就有點混亂不堪的意思了。尤其是對cookie和session的忽略導致一些問題直到上線也沒能很好地解決，只能采用臨時的，不可拓展的垃圾代碼頂替，看得我自己都想吐。

2.建數據庫

　　其實如果開發文檔設計好，數據庫自然也不用再考慮。可是我寫開發文檔懶了，只考慮了表的字段，沒有涉及到具體類型、索引等信息。這導致了我之后寫代碼的時候修改了幾個表字段的數據類型。雖然造成的改動量不大，但修改底層往往是很心累的。我們都希望封好了一層之后就不在打開這個封條，站在新一層的高度考慮問題，顯然這次的實踐沒有處理好。

3.寫代碼

　　寫代碼的過程真心可以總結為，從條理清晰到不管三七二十一。

　　初步搭建框架的時候思路還是很清晰的，代碼寫的也比較干凈，因為畢竟之前練習時搭建過很多次。web層、業務層、持久層，再封裝一層redis，整個過程一氣呵成。

　　但到后面遇到實際業務時就慌亂了。首先，我遇到了以前沒用過的redis數據結構list，我把用戶的消息，群內的消息都存到了redis的list里，如何索引這個list里的數據成了困擾我的地方，雖然最后都通過記錄其索引值解決，但感覺并不是長久之計。之后，session中存哪些信息又成為了一大亂點，最后發現很多地方都要用到，不得不不斷往里面存數據。有時執行某個方法時會忘記同步更新session中的數據。導致了很多bug。還有數據的同步問題，數據庫，redis，session中的數據如何保持同步，我目前只在邏輯上去保證，只能祈禱系統不出問題。消息的實時更新，我用了ajax長回調機制，據說是效果最好也最節約開銷的方式。頁面啊！頁面真是救命了，對于一個后端開發人員，我對頁面的美觀簡直毫無辦法，只能找網上的模板，還好找到了一個仿微信頁面的前端模板，拯救了我

　　這部分確實比較亂，沒經驗，趕著項目上線很多問題都沒能很好解決，日后將一一總結。

?

三、上線前

?　　上線前遇到的一些問題讓我一度想要放棄，有些跟代碼無關，給大家講講。

1、阿里云有安全組策略的

　　之前不知到，數據庫、redis什么都配置好了，也允許外網訪問，可是就是一直訪問不了。一直找配置中的錯誤，不斷重新安裝，一度想要放棄。結果后來發現問題很簡單，阿里云有自己的安全組策略，你必須配置以允許外放訪問這個云的哪些端口才行，不配置默認就是拒絕訪問。找到問題根源時我笑哭了。。。

2、大天朝的域名是需要備案的

　　直到最后我才把項目端口改成80，也用了自己的域名，結果發現無法訪問，跳出來一個“友好頁面”。后來知道，在中國域名是需要備案的，于是走阿里云備案流程，發現需要25天（北京），還要郵寄幕布讓你來拍照什么的，上線時間緊迫，一度要放棄的時候，想到了“某寶”，于是。。。

　　　　

3、微信需要域名加標準端口才能直接跳轉

　　如果你用微信訪問一個 http://185.10.10.195 這樣的地址，它會先跳出

　　

　　如果你用微信訪問一個 http://www.datauuu.com:7001 這樣的地址，它會先跳出

　　

　　也就是說，只有域名配web標準80端口，微信才能直接打開自己的瀏覽器做跳轉。這個也是我購買域名以及想到要備案的原因。哎真是經驗不足啊，不然上線前不必為這些事操心

?

四、上線后

　　沒有日志系統，沒有監控系統，沒有管理系統。只有一個自己做的超簡單的管理頁面，只能初始化數據庫數據，同步數據庫和redis，所有查詢都是直接用sqlyog看數據庫。

　　現在明白為什么一個項目要如此重視日志系統和監控系統了，真是太有用了。我這個項目好在比較簡單，最重要的是我只是玩一玩，出問題那就出了也不用負責人。要是一個正規的系統，我現在的狀態只能用聽天由命來形容了。

　　總之在做一個項目之前，以下事情還是比較重要的。

　　一是各種“常識”，比如阿里云的一些事，還有域名備案這種事，不過自己經歷過一遍就都明白了，這些坑也是必須自己踩過一遍才行的，不難，但很討厭。

　　二是架構設計，真的非常非常重要！就不說三遍了。你代碼中遇到的幾乎大部分的坑，都源于設計階段的不合理，也都是能通過重視設計來解決的。而且設計階段可以弱化其實現過程，把精力用在模塊與模塊，接口與接口的交互之間，站在一個高度上看問題，就不會被細節影響了大方向。

　　三是多學知識，這個我便沒有做好，很多功能都是想用我現有的知識去解決。其實優秀的解決方案有很多種，不妨多多參考別人優秀的設計，切記不能為了暫時解決問題用不合適的方式。

　　四是要做日志系統和管理系統，這在項目上線后是很重要的，即使是練習項目，也能通過它們發現項目的更多問題。雖然不會影響項目的使用效果，有些人會覺得多余，但這其實是必要的。

　　總的來說，我發現我用在實際寫代碼上的時間并不多，大多都在設計、修改代碼、還有搞阿里云啊這些瑣事上，大家一定要重視這些環節，碼代碼只是其中一小部分而已。一個優秀的設計會讓你的代碼寫起來輕松高效，出錯的概率也小很多。

?

from:?https://www.cnblogs.com/flashsun/p/7651742.html?

總結

以上是生活随笔為你收集整理的记一个自己项目上线的全过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。