? ? ?esri開發大賽項目已經完結，每一次項目的完成，都應該有一次總結，這也一向是我個人的習慣。 對于這次參加比賽的作品開發過程，其實這里我也不確定這能否真正稱得上是一個項目，畢竟這其中存在著很多問題以及極其不規范的地方。但在這里我姑且將其稱為一個項目吧，只是他可能不完整罷。現在已經大四，面臨畢業、擇業、就業或者其他的選擇，在學校的日子也已經不多了，或許這也是大學期間做的最后一個項目了，嚴格意義來說應該是在大學最后期間做的最為完整的一個項目了，每一次的實戰歷練，對自己都是一次很好地提升，在項目開發過程中所遇到的問題更是值得去進行總結和反思，這才是項目實戰的意義所在。 三月中旬，四個人的團隊組建起來，算是真正開始了開發大賽。但一切都是未知的，很多東西都得打上一個問題。 第一個問題便是選主題的問題。按照軟件項目開發流程來說，便是需求分析的問題。選擇什么主題內容？ 選擇什么何種開發？ B/S？ C/S？ 這所有的問題都得解決。好在人多，這個想一個，那個再想個，主題算是確定下來，也沒有去仔細地去考慮到選擇這個主題后面要面臨的東西，更多地去考慮這個主題是否夠新穎，覺得很新穎，覺得沒見過，好，ok就是這個了！。_ ?。這個主題在B/S(作品是在B/S下)的開發下是否夠有優勢？選擇這個主題是否具有很好的功能擴展性？按照我們自己現有的想法搞下去是否真的可行？我么搞這個主題在數據收集上是否是存在很大的難度？。。。這些問題，在討論主題的時候似乎都是沒有涉及，或是設計的很少，現在想來，的確覺得當時的我們無知的有點過了。好在人多膽大，這個新穎，這個別人沒搞過，我們就搞這個吧，主題這樣便是定下來了——“基于GIS的中國近代歷史名人事件年譜”。需求分析是一個搞清楚接下來應該做什么的過程，而在整個開發的開始，卻將其忽略地那么徹底，這算是項目開發中一個致命錯誤。需求的不明確，將直接導致后面整個系統設計階段的全面崩盤。 系統設計怎么搞？數據庫該怎么設計，一拖再拖，大家都不知道究竟該怎么搞下去。在這個地方，犯了一個錯誤——“數據庫的設計究竟是應該圍繞功能來設計，還是功能應該圍繞著現有的數據以及數據庫來來設計？”。“數據庫與功能誰應該是主導”這個問題其實我一直在思考， 如果把數據庫給改了，那之前想的功能又怎么辦，功能又實現不了，如果按照功能來，數據庫的設計模式好像的得改，怎么辦？后來才搞明白數據庫與功能之間的關系其實怎么想都應該相互依賴的關系，其實不存在什么主導關系，但如果非要哪個才是主導地位的話，我想是數據。越到后面的開發過程，越會明白這一點的，數據庫對數據進行管理，只是作為一個數據的存儲管理容器，功能的設計是為了將數據呈現或是在另一個方式下通過數據庫的操作來對數據進行管理。所以數據庫和功能之間其實不存在什么主導地位，而應該相互依賴的關系。他們兩者相互聯系的紐帶這是圍繞著數據來展開的。所以在這一點可見在第一階段需求分析的重要了，不明確要做什么，不明確系統需要呈現些什么、需要些什么數據，這都直接導致系統設計階段的數據庫設計出現很大的困難。在這里我是搞懂了團隊內專門負責數據的伙伴，為什么一直都在說不知道應該怎么找數據了。一切都得歸咎于需求的分析不明確。另外，在系統的設計階段，團隊除了一直搞數據庫、收集數據庫之外，也沒有將我們整個系統的各個功能給徹底地細化，尤其是對于做web開發來說，涉及到的東西很多，都沒有一個明確的文檔性規范，尤其對各個功能實現所要涉及到的大體內容都沒一個集體性地討論，直接導致了開發編碼過程中各自為站，進度緩慢，代碼風格各異。 編碼階段。對于這個方面，對于系統框架什么的我就不去討論了，畢竟自己還是個coder ，只能對在這個階段中自己出現的很多代碼規范性上的東西多做下總結。在做這個開發之前，自己也已經自學過了一段時間的web了，但是，終究紙上得來終覺淺，絕知此事要躬行，缺乏實戰是不可能把編程學好的，所以這應該是第一次完整的真正動手實戰。webgis的開發不像常規的web開發，除了建立常規的屬性關系數據庫之外，還需要地理數據庫，我主要負責屬性數據庫邊的開發，另外一個同學負責與地理數據庫的處理，與地圖的交互操作。對于屬性數據庫的操作部分，我最開始采用的是Apache+PHP+mysql的結構，一開始也沒什么問題，指導老師也沒有說什么，就這樣搞了近一個月，老師讓數據庫換成access，后臺用Csharp，沒辦法，改吧，其實還是有那么一點抱怨，但是還是花了近一個周的時間給換了過來，好在花的時間不多。在后臺結構上采用了常規的三層架構，其實后來我發現這對于我們這個小項目有點大材小用了，對數據的操作基本涉及到的是查詢操作，多表查詢操作有比較多，采用三層結構，又得一個一個去寫實體，一層一層往前端傳數據，也是將本簡單的東西搞得有點過于復雜了。但經過這樣一次的實際操作也讓自己對三層結構有了更深刻認識，收獲挺大。在編碼上，代碼命名的規范性特別重要，在項目的編碼開始初期，還不會發覺，越到后面越會發現，命名的重要性，對于不同方法，都應該嚴格根據其實際用途來命名，不能隨便給個命名，在某處調用了一個方法，到最后可能自己都得去看方法體本身才知道是干什么的，浪費時間，自己看著也不爽，最好是見名知意，比如GetdeventDescById(),見名知意，看著也舒服。另一個方面就是代碼的組織上，十分凌亂，功能分析的不徹底，導致做到哪兒寫到哪，寫一個小功能模塊的時候不能想到在另一個地方還會用到相同的代碼，直到寫到下一個模塊，才發現好像是同上一個功能模塊一樣，趕快有掉頭回去改代碼，將前面已經寫好的功能又拆開來封裝寫個方法，如此一來明顯感覺到整個代碼極其的糟糕凌亂，代碼的強健性也極其的降低了。極其浪費時間，在系統設計階段沒有對功能進行仔細的剖析和規劃，這些都會導致這一系列的問題。 最后就是系統整合版本控制問題，兩個人或者幾個人同時開發者，集成的時候，由于前端也是我在寫，我倒是將我所有的東西都寫在一塊，前端后臺都在一塊，倒也不存在什么問題。我拿出第一個版本來讓另外的人往上面集成他們寫的工能的同時，我又發現我這邊的前端界面要改一下，后臺代碼得改一下，改了之后，產生了一個新的版本，而別人又在之前的那個版本上集成了部分功能，沒辦法，又讓在新的版本上集成，如此一來，又浪費了很多時間。版本控制做的也是不夠好。 總結就到這里，仍然還有多需要提高的地方，仍然還有很多需要學習的地方。每一次的歷練都是一次提升，每一次提升都來源于點滴的積累。

總結

以上是生活随笔為你收集整理的esri开发大赛项目总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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