已經很久很久沒有發博客了，自從上次解決完實習招聘的事之后，就一直忙於學習上的事了，最近考完了最惡心的算法分析與設計，總算是有點時間來寫寫有關於技術，項目的事了。在這一個月左右的時間了，我做了兩個很小的，相當於課程設計的大作業，兩個都是B/S結構，一個是物品銷售的系統，實現銷售商和生產商在網頁上操作數據，因為是軟件質量保證和測試的大作業，所以我們還用了qunit和loadui進行了代碼測試，這會在我另外一篇文章。另一個就是我要說的網頁在線聊天的大作業，這里主要用到了websocket實現雙向通信，百度地圖API實現位置定位這兩門技術，不難。
這里主要是和大家分享一下做這個大作業的感悟，當然不能和大公司，或者一個大項目相提並論，畢竟還是一個學生，對於項目開發和管理的經驗就那么點，所以如果要噴，請就事論事，勿涉及雙方的父母。
以前我一直覺得，技術第一，我掌握了很多的技術，我就能開發好一個項目，請原諒我這種想法，我也上過很多有關於項目管理，項目開發，軟件工程的課，老師也會一直指出要分需求分析，概要設計，詳細設計，編碼，發布這五部驟，但是從沒有重視過，開發么，實現功能就可以了。但是真的不一樣，只有自己真的作為一個leader開始開發一個項目的時候才會有所感悟。先說說這個項目開發的基本情況，我們是三個人，其中一個人是醬油，對於編碼不太會，可以偶爾負責寫一些文檔（大家都懂的），另一個人會一些后台開發，但是也不是很靠譜，還有一個我。
大作業的題目是我定的，因為我覺得會比較有趣，而且難點都在前端，我是負責前端開發的，這樣保證起碼這個作業可以做完。在分工上，我定義了那位醬油同學X負責寫文檔，實際上到后來，文檔都是有我和另一個同學Z寫完的，這是后話了。另一個同學負責建立數據庫和編寫后台基礎代碼（enity，DAO），然后我負責前台開發，當時我估摸着最后也會是我來負責前后台的交互，即編寫action類。事實上也是如此。
定義完分工之后，我開始估算這個大作業的大小，這時候，其實是初略的估計大作業的功能模塊。當時初步構想是好友管理，聊天，地圖，管理員管理四個主要的模塊。
然后分析技術難點，好友管理那塊如果時間來不及，就直接拖一個表格控件，技術都已經成熟了，應該沒有問題；
聊天那塊，websocket交互沒有做過，但是聽室友說挺簡單的，這里定義一個優先解決的困難點，因為這時基礎模塊；
地圖那塊，百度地圖api用過一次，基本的流程都還有點印象，而且寫過一些demo，正好可以用上，實現的時候，可能有些困難，但是應該都可以解決，划分為第二需要解決的困難點；
管理員管理那塊，懶一點就類似於好友管理，直接拖datatable控件解決；
經過上面的一陣分析，估計到個人的能力，覺得這個大作業是可行的，就是可能到時候自己要累一些。接下來就開始正式的需求分析階段
需求分析，其實說白了，就是寫文檔，寫需求分析文檔，在和同學Z討論了一下，一起分析設計了大作業的功能模塊，用戶功能（用戶基礎功能，用戶核心功能，用戶附近功能），開發順序也是依次。管理員功能（用戶管理，公告管理）。
在定義完需求之后，我們又馬上開始定義概要設計和詳細設計了，這其中包括數據庫設計，項目總的文檔結構，所用的技術，然后開始寫文檔，這里要說一下，不要太急着開始詳細設計，很可能需求還會變，這會付出慘重的代價的，這次大作業我深刻的體會了為什么程序員討厭寫文檔，實在是因為寫文檔可能會耽誤很多的開發時間，我們這個大作業最后的文檔有70多頁，20000左右的字數，幸好有些地方是復制粘貼的，但是那也是很蛋疼的一件事，因為實在是分不開身再寫文檔了，說一句哦，本人其實不討厭寫文檔，相反還是覺得寫文檔很好，有利於理清思路，但是在特殊情況下，實在是覺得有些討厭了。
在偷懶以及直接忽略概要設計文檔和詳細設計文檔之后，我直接開始了前端頁面的開發，Z同學也是不久之后就直接開始建立數據庫，然后開始寫enity，dao層。在網上找到了一個不錯的開源的desktop模版，然后試着將所需要的頁面集成進去，這樣可以省去自己設計的一些時間，主要是設計這塊不太會，css寫的也不好，讓我寫出漂亮的頁面不太現實，所以只有直接套用現有的，然后再此基礎上改，相信很多同學也是這樣的，但是帶來的一個問題是，有時候你可能根本找不到應該在哪里改樣式，哪里改js代碼。這可能跟經驗相關了，看你的直覺了，一般css代碼，可以選擇用chorme打開，按f12，然后放大鏡，選中頁面的某一模塊，然后你就可以在調試器中看到css代碼了。
回到正題，這樣我們的項目提前開始了，因為只有兩個人，而且時間也比較緊了，開始開發，留給我們的時間只有5天了，其中包括一個周末，這時候，我開始首先解決我的技術難點，實現websocket，在網上找了一份代碼，調試更改之后，在tomcat7下運行成功了，然后分析源碼，找到了到時候需要更改的部分，這樣第一個核心技術解決了，然后開始第二個技術難點，地圖，通過查看官網上的demo，然后自己的demo，功能都差不多實現了，到時候只需要從后台讀取數據，然后顯示出來就可以了，這時候就發現，當初的數據庫設計有些問題，需要改，老實說，這時候代價已經挺大的，好吧，解決完上述兩個最主要的問題，基本上心里已經有底了，這時候已經是星期六的晚上了，還有三天，星期天，我就開始整合階段了，將Z同學已經寫的東西和起來，然后自己開始actio層的編碼，當然不用想，dao層肯定需要更改的，這時候項目的開發人員就已經只剩一個了。我開始集中代碼開發階段了。最終項目怎么樣其實就取決於我一個人了，我不是想說自己有多厲害，其實我一直覺得每個人都是可以在一個項目中找到自己的位置的，關鍵在於leader怎么管理，這里就是我管理的一個問題，為什么不能定義好統一的數據交互接口，為什么剛開始的分析設計的時候不詳細一些，這時候也不需要將所有的重任都壓於一個人身上。這就是個bug。
雖然最后項目差不多完成了，效果也還不錯，有關於項目的技術總結，看情況吧，其實也沒什么好說的，都是一些簡單的技術，稍微學一下，研究一下就會了。關鍵在於項目的管理。通過這個項目我有一些體會，與各位共勉：
1. 需求分析階段，盡量慢一些，和概要設計，詳細設計有一定的間隔，這樣可以有時間反映，修改需求分析，不至於讓概要設計和詳細設計做出太大的變更
2. 應該分配合適的工作給合適的人，每個人在項目中都是可以有所作為的，關鍵在於你怎么去管理他。
3. 定義統一的數據交互接口很重要，大家有一份接口文檔，就差不多可以實現前后台分離開發，我相信一些真正的項目也肯定是這么做的
4. 一般晚上，夜深人靜的時候，頭腦比較清楚，適合進行需求分析，詳細設計，還有一個人永遠是想不全的，需要集思廣益。
5. 寫代碼最好的就是在先解決完所有的技術難點之后，進行集中開發，一天，兩天就一直在開發代碼，效率不錯，bug也少。
6. leader必須適當的關注一下小組內各個成員的進度，還有不要催的太嚴，注意交流和處理問題，矛盾，分歧，其實主要是做人了。
7. 小的項目可以先從頁面開發開始，先進行頁面原型設計，因為一旦頁面確定，基本上的功能也就確定了，所以誰說web前端不適合項目架構，其實前台分析的好，對於整個項目的架構是很有好處的。我就想成為這樣的人，由前台轉向項目架構，當然我不僅僅會web前端，后台也會一些。
8. 項目管理真的是一門學問。