若是沒有一個可以拍板的人,那麼整個團隊將會伴隨着愈來愈多的爭議而走向消亡。web
特別是若是在一個團隊中,存在着那種很是執拗任性的,不服從指揮,堅持我行我素的人,那麼這個團隊消亡的速度就會愈發的快了。數據庫
算了,不叨叨這多了,開始正題!編程
首先先了解一下開發的大體步驟。緩存
▍開發步驟tomcat
一、需求分析服務器
二、頁面原型設計架構
三、數據庫建模框架
四、架構eclipse
五、類設計函數
六、編碼
七、測試與調試
八、部署
▍項目前期
第一個也是最重要的:找好領頭羊,不是每一個人都適合做爲領導者,這個領頭人必定要在團隊中有威信,有公信力和領導力。
另外若是本身自身在團隊中沒有威信,領導力不夠,那麼最好不要當這個領頭人,乖乖的當個小組員,作好本身的本職工做就好。
團隊互補是很重要的,好的搭配纔是精彩的開始,糟糕的人員搭配只會讓事情變得很糟。
組隊的時候不能只看我的能力,還要看我的的溝通表達能力,有時候我的的性格脾氣也會對整個項目的進度產生影響。
人員分工必定要合理,包含兩點:第一好鋼要用在刀刃上(不要讓不熟悉相關工做的人作相關的事情),第二每一個人的工做量儘可能作到最好的「均分」。
▍需求分析
單人完成!
主要分析這個系統是幹什麼的,須要哪些功能,用戶主要是哪一類人羣。
在需求中須要有完整的用例圖和用例表,不僅是作到「差很少」,而是要作到用例全覆蓋。如下爲單個用例表實例:
在需求中要指出變量、函數、類等的命名規範。
肯定頁面緩存方式,哪些表格是按照整個表格緩存,哪些表格是按照單個字段緩存。
需求文檔必定要完整清晰,發現其中有欠缺的地方要及時完善補充。
▍頁面原型設計
單人完成!多人同時提供設計思想會致使頁面始終難以肯定。
若是其餘人有任何意見,能夠在設計完成後提出,若是最後關於某個問題爭執不下,那麼就團隊投票表決或者是組長作決策,不要在一個小問題上糾結過久。
▍數據庫建模
單人完成!
在數據庫表的設計上要保證科學合理,數據表的構建必定要符合3NF範式。
每張表必須有一個自增id做爲主鍵,不作其餘用處,只是用來標識數據的數量。
▍架構
架構構建的時候,儘可能使用當前流行且成熟的框架,保證架構的實用性與牢固性。
▍類設計
類設計就是要設計出有哪些類,這些類中又分別有哪些方法, 每一個方法是作什麼用的,而後這些方法之間又是怎麼鏈接在一塊兒的。
▍編碼
我我的認爲編碼應該分爲兩個小的階段:
第一階段先後臺獨立編碼,前臺完成頁面的製做,後臺根據頁面原型圖敲定大致上會用到的函數以及函數以及所涉及到的變量,這段時間內先後臺是互不影響的,能夠獨立同時進行的;
而後先後臺獨立工做完成以後,就能夠進行整合了,第二階段先後臺整合,前臺在後臺中找到所要請求的函數,若是有而且正確,那麼就直接調用這個函數,若是後臺沒有考慮到這個函數,或者函數的參數與返回值不知足前臺的請求方式,那麼就須要對後臺進行微調,這個時候先後臺人員的交流就要多一些了。
不要想着能一次性寫好,這是不可能的事情,或者說是作夢。。。
若是是先後等後臺完成以後再動工,或者是後臺等前臺完成以後再動工,那樣的話中間等待的時間就會被浪費掉。
個人隊員就犯了這樣一個錯誤,我作前臺,他作後臺,我把前臺頁面作好以後,問他後臺的編碼工做完成沒有,結果他說他在等我前臺的變量名定好以後再動工,我簡直要氣死了。
離提交時間就只有這麼短了,他居然告訴他尚未動工!!!
不過要說怪的話,也怪我沒有事先說好編程階段的時候怎麼作,沒有把個人見解拿出來跟他們交流(我覺得他們應該跟我想的同樣)。
團隊中的每一個個體都須要有良好的編程規範,多寫註釋。
網站或者軟件在開發過程當中,必需要使用版本控制器進行版本控制(小型團隊使用SVN學習||SVN的正確打開姿式,大型團隊使用GitGit簡潔教程-本地項目推送到GitHub),不然會作不少無用功。
▍測試與調試
這一步驟是爲了保證程序可以正常跑起來。測試是爲了找出Bug,而調試是爲了找出出現Bug的緣由,而後修改程序修復Bug。
團隊之間確定會存在方式思路不一樣的時候,調試過程當中,當咱們以爲隊友的代碼或者處理邏輯有所欠缺或不足時,在沒有與原始編碼人員商討的狀況下,不得擅自修改,防止出現「交叉版本」。
▍部署
運用不一樣工具開發的項目,其發佈的方式也可能會有相應的區別。
好比若是是普通的web項目,有兩種方式:第一種在編輯工具中配置服務器(例如在eclipse中配置tomcat),而後啓動配置在編輯工具中的服務器,項目就能夠跑了;第二種是將web項目打包成war包,而後放在放到服務器中運行。
▍項目後期
項目完成以後,要看到這些文檔:
需求分析文檔
項目整體設計報告
項目詳細設計報告
項目進度報告
項目測試報告
項目使用說明書
項目風險評估報告