我正式參加的第乙個專案是移動渠道運營，由於公司人手不夠，老大將渠道資源的大模組交給我乙個人來負責，由於之前的詳細設計極為粗略，庫表設計也沒有，所以一切就得自己來搞定了。
開發過程中與客戶進行過2次粗略的互動，可由於我是新手，對移動業務很是不熟悉，他們的需求我難以全部消化。兩個月後一期開發完畢，昨天在現場與客戶測試的時候，發現很多地方都沒想到，雖然介面和已實現的功能他們頗為滿意，可還是提出很多他們需要的功能以及需要修改的功能。客戶的素質頗高，只是希望我盡快考慮他們的需求，新增一些他們迫切要求的功能。還好，老大沒有批評我。
經歷這次事情，感覺需求與詳細設計是多麼的重要。出現這樣的問題，我分析了一下，有以下原因：
1. 前期與客戶交流不夠，只是粗略的溝通，很多細節問題都沒有涉及到；
2. 自己對移動業務不熟悉，造成對客戶的要求不能完全理解，出現偏差；
3. 設計的實現方式自己還是欠缺，比如如何設計乙個高效的庫表系統，庫表之間如何關聯等；
解決的方法依次如下：
1.. 前期溝通一定要充分，在開發過程中哪兒有問題，需及時和客戶進行確認，萬不可按照自己的主觀臆斷行事；
2..多閱讀客戶方提供的業務資料，通過閱讀以及與客戶的溝通，做到盡可能熟悉客戶方的業務需要，這樣對開發有很大幫助，提高軟體的實用性；
3. 資料庫設計方面，多與公司的前輩溝通，參考公司以前做的系統，並結合業務需要。全面的模擬整個使用環境，考慮到在使用中可能出現的各種問題；
4. 從使用者的角度出發進行分析。比如設計乙個票據領用登記歸還的模組，那首先得領用登記吧，得做個領用登記的頁面和功能，需要個領用主表和，明細表；領完了得查詢吧，這段時間誰領了多少票吧？好，得提供查詢功能；票領完了發現領多了或者沒用完，得歸還吧？ok，加個**登記的功能。可要**那肯定是有領用記錄才行，所以還是先得查詢。庫表設計方面，可以設計成四張表，分別是領用主表、領用明細、歸還主表、歸還明細；可這樣的話關聯也太多了，歸還主表得記錄領用記錄主鍵；歸還明細得記錄領用記錄主鍵。不可取。何不就設計成兩張表呢，乙個是主表，乙個是明細表，主表字段有領用id、領用人、領用部門、領用原因、歸還原因等基本資訊；明細表欄位有 明細id、領用id(外來鍵)、發票型別、領用數量、領用日期、歸還數量、歸還日期等。這樣存領用的時候歸還欄位均為空；歸還的時候直接先查出領用id，然後直接把歸還資訊存入不就行了嗎？
注：我是個剛畢業半年的新手，啥也不懂，都是剛開始學，這是小弟積累的一點點經驗。希望能給和我一樣的新手有所幫助，我這裡面肯定有不對的地方，還望高手看到後能給予指點啊，小弟不勝感激！
RESTful API 設計入門
前後端對接其實主要是面向 api 文件開發，而 api 的設計中，有一種 restful api 的設計，具有規範，從某一種角度，我覺得 restful api 可以很好的把後端 api 從繁雜的業務中抽象出來，更好地進行管理和編寫，同時也具有良好的可讀性。對於一些現代化的 mvc 框架，在腳手架階...
Hbase roekey設計入門
rowkey類似於主鍵，可以唯一的標識一行記錄 由於資料按照rowkey的字典序 byte order 排序儲存，因此hbase中的資料永遠都是有序的。rowkey可以由使用者自己指定，只要保證這個字串不重複就可以了。不可以 會被覆蓋 hbase main 006 0 put csdn emp rk...
WSDL檔案設計入門
在 wsdl 中，服務被定義為三個截然不同的部分 服務的位址，組成，繫結 在 wsdl 中，服務被定義為三個截然不同的部分 port port 定義了可用服務的實際位置 端點 例如，soap 服務所在的 http url。porttype 功能 服務的組成 porttype定義了由服務提供的抽象介面...