記一個本身項目上線的全過程

我的終於第一次完成了一個java web項目從策劃到最終上線的全過程，雖然項目十分簡單，但全流程跑通的感受仍是倍爽的，以後再作項目則只是各個環節上的細化了。

如今我將個人「第一次」分享給你們

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

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

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

項目簡介：本身作着玩的一個項目，爲某校80週年校慶準備的，頁面模仿微信聊天界面，用戶可在上面說話。

 

1、準備階段

服務器：阿里雲服務器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項目，也能夠跑微服務，十分便於管理。

 

2、瘋狂打碼階段

　　 開發過程總結起來能夠說很簡單，一、寫好開發文檔； 二、建好數據庫； 三、寫好代碼並打成jar包。描述起來真的特別簡單，並且基本都是這樣的流程。

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

1.寫開發文檔

　　因爲自身比較追求代碼的質量，實現所謂的高內聚、低耦合，因此在乎識上仍是很明白設計階段的重要性的，雖而後面看來一開始的設計簡直是糟糕透頂。

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

2.建數據庫

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

3.寫代碼

　　寫代碼的過程真心能夠總結爲，從條理清晰到無論三七二十一。

　　初步搭建框架的時候思路仍是很清晰的，代碼寫的也比較乾淨，由於畢竟以前練習時搭建過不少次。web層、業務層、持久層，再封裝一層redis，整個過程一鼓作氣。

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

　　這部分確實比較亂，沒經驗，趕着項目上線不少問題都沒能很好解決，往後將一一總結。

 

3、上線前

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

一、阿里雲有安全組策略的

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

二、大天朝的域名是須要備案的

　　直到最後我才把項目端口改爲80，也用了本身的域名，結果發現沒法訪問，跳出來一個「友好頁面」。後來知道，在中國域名是須要備案的，因而走阿里雲備案流程，發現須要25天（北京），還要郵寄幕布讓你來拍照什麼的，上線時間緊迫，一度要放棄的時候，想到了「某寶」，因而。。。

　　　　

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

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

　　

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

　　

　　也就是說，只有域名配web標準80端口，微信才能直接打開本身的瀏覽器作跳轉。這個也是我購買域名以及想到要備案的緣由。哎真是經驗不足啊，否則上線前沒必要爲這些事操心

 

4、上線後

　　沒有日誌系統，沒有監控系統，沒有管理系統。只有一個本身作的超簡單的管理頁面，只能初始化數據庫數據，同步數據庫和redis，全部查詢都是直接用sqlyog看數據庫。

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

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

　　一是各類「常識」，好比阿里雲的一些事，還有域名備案這種事，不過本身經歷過一遍就都明白了，這些坑也是必須本身踩過一遍才行的，不難，但很討厭。

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

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

　　四是要作日誌系統和管理系統，這在項目上線後是很重要的，即便是練習項目，也能經過它們發現項目的更多問題。雖然不會影響項目的使用效果，有些人會以爲多餘，但這實際上是必要的。

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

 

下個項目醞釀中。。。嘿嘿