做軟件開發項目實習的心得體會

做軟件開發項目實習的心得體會

　　現在很多行業都需要開發軟件，軟件開發需求越來越大。下文是做軟件開發項目實習的心得體會，希望可以幫到你們。

　　篇【1】：做軟件開發項目實習的心得體會

　　問題，再也不可能以“逃避”而了之了。也讓我感覺到做為一個程序員所應該具備的基本素質在這不到一個月的實習過程中也讓我深深體會到了作為一個合格的程序員應該具備的基本素質。

　　團隊精神和協作能力是程序員應該具備的基本素質，最近的工作中讓我深深休會到了這一點，由于小組成員配合不好，使本來很方便的cvs給自己的工作帶來的及大的麻煩，一不小心自己寫的的東西就會被小組別的成員在上傳文件的時候給覆蓋掉，一整天的工作可能就這樣被反工，我們小組這次就是因為協作不好，導致各模塊之間不法連接，給工作帶來了及大的麻煩，消耗了大量的勞動力還沒有提高工作效率。這使我深深的體會到：一個成功商業性軟件的開發必須有一個有強大凝聚力的團隊，個人的力量是有限的，團隊精神和良好的協作會使我們做出優秀的軟件。

　　良好的文檔是正規研發流程中非常重要的環節，作為代碼程序員，30%的工作時間寫技術文檔是很正常的，缺乏文檔，一個軟件系統就缺乏生命力，在未來的查錯，升級以及模塊的`復用時就都會遇到極大的麻煩。這次的這個小小的項目，就因為文檔上的一點點理解錯誤讓我們花了很大的工夫去改代碼，改頁面。很慶幸的是，這是一個小項目，要是大項目，這種問題可能就會導致大量的代碼修改，可見文檔在一個項目中起者巨大的做用。

　　此外，良好的代碼編寫習慣，不但有助于代碼的移植和糾錯，也有助于不同技術人員之間的協作。作為一個程序員，對需求的理解能力也是很重要的，只有真正理解了一個模塊的作用，才會寫出高效率的代碼，才能使整個軟件項目作出來更加優秀，具備更好的安全性和穩定性，我在寫代碼的過程中就遇到了需求理解上的問題，使得寫出來的代碼功能不全，幸好不是給客戶發現在，要不，這個軟件的商業價值可能就會打折扣了。單元測試對于一個程序員來說是不可不做的一項工作，不做好測試就會給后期的集成工作帶來麻煩，往往為了一個小問題會讓我們查找好多模塊，給后期工作帶來很大麻煩。

　　這一段時間的工作也讓我明白了一點：一個優秀的程序員必須不斷的學習，隨時總結，找到自己的不足，這樣逐步提高，才能讓自己很快的成長起來。

　　篇【2】：做軟件開發項目實習的心得體會

　　作為就業培訓，項目的好壞對培訓質量的影響十分大，常常是決定性的作用。這篇文章是關于在學習JAVA軟件開發時練習項目的總結，簡單總結為以下幾點：作為就業培訓，項目的好壞對培訓質量的影響十分大，常常是決定性的作用。這篇文章是關于在學習JAVA軟件開發時練習項目的總結，簡單總結為以下幾點：

　　1、項目一定要全新的項目，不能是以前做過的，

　　2、項目一定要企業真實項目，不能是精簡以后的，不能脫離實際應用系統，

　　3、在開發時要和企業的開發保持一致，

　　4、在做項目的時候不應該有參考代碼。

　　長話短說就是以上幾點，如果你想要的了解，可以繼續往后看。

　　一：項目的地位因為參加就業培訓的學員很多都是有一定的計算機基礎，大部分都具備一定的編程基礎，尤其是在�；蛘呤莿偖厴I的學生，多少都有一些基礎。他們欠缺的主要是兩點：(1)不能全面系統的、深入的掌握某種技術，也就是會的挺多，但都是皮毛，不能滿足就業的需要。(2)沒有任何實際的開發經驗，完全是想象中學習，考試還行，一到實際開發和應用就歇菜了。解決的方法就是通過項目練習，對所學知識進行深化，然后通過項目來獲取實際開發的經驗，從而彌補這些不足，盡快達到企業的實際要求。

　　二：如何選擇項目項目既然那么重要，肯定不能隨隨便便找項目，那么究竟如何來選擇呢?根據Java的研究和實踐經驗總結，選擇項目的時候要注意以下方面：

　　1：項目不能太大，也不能太小這個要根據項目練習的階段，練習的時間，練習的目標來判斷。不能太大，太大了做不完，也不能太小，太小了沒有意義，達不到練習的目的。

　　2：項目不能脫離實際應用系統項目應該是實際的系統，或者是實際系統的簡化和抽象，不能夠是沒有實戰意義的教學性或者是純練習性的項目。因為培訓的'時間有限，必須讓學員盡快地融入到實際項目的開發當中去。任何人接受和掌握一個東西都需要時間去適應，需要重復幾次才能夠真正掌握，所以每個項目都必須跟實際應用掛鉤。

　　3：項目應能覆蓋所學的主要知識點 學以致用，學完的知識點需要到應用中使用，才能夠真正理解和掌握，再說了，軟件開發是一個動手能力要求很高的行業，什么算會了，那就是能夠做出來，寫出代碼來，把問題解決了，你就算會了。

　　4：最后綜合項目一定要是實際應用系統學員經過這個項目的練習，就要走上實際的工作崗位了，如果這個系統還達不到實際應用系統的標準，學員練習過后也還是達不到企業實際的需要，那么這個培訓應該說質量就不高了。理想的狀況是這個項目就是實際項目，到時候學員就業到另外一個公司，不過是換個地方干活而已，完全沒有技能上的問題。

　　篇【3】：做軟件開發項目實習的心得體會

　　經過為期4個月的專業實習，令我更深一步的了解和學習了軟件開發的一般過程，不再是以前那樣，都不知道軟件開發是什么東西。對于一個應用系統他們為什么要那么多人來做，而這么多人一起做，代碼又是如何進行管理的。對于每一個應用系統，企業到底用到哪些技術，他們為什么要選擇這些技術，我們開發人員的主要任務是什么等等，這些概念都漸漸的清晰。人，孰能無過，過而改之，善莫大焉!沒有誰，在編寫代碼的過程中永遠不會犯錯，即使他非常的厲害，那也是從不斷的犯錯過程中鍛煉出來的，但亦有“犯錯”的時候，因為需求是不斷的改變的，即使你當時沒錯，但需求改了之后，你的代碼不符合需求，那也是你的錯。有錯那當然就要調試咯，以前老是害怕出錯，找不到問題所在是件令人煩惱的事。但是當調試的`錯誤多了之后，你就會發現，每當一看到相類似的錯誤之后，你就會立即知道這個錯誤是什么原因造成的!所以，我們不應該害怕出錯，應該把調試錯誤當成一種提高個人能力的方式。對于測試人員發回來的bug我們要認真的對待，造成這種bug就證明了我們的思路還是不怎么的清晰，所以有必要再去看看相關的資料。溝通是人與人之間傳遞信息的途徑，好的溝通能很完美的傳達你的思想，你的見解。在企業中，每一個系統的開發過程一般來說都不是一個人從頭做到尾的，一般都有分工的，如此一來，溝通就必不可少了，因為你要把你做的工作，你為什么這樣做，告訴別人，別人才更好的去完成他的任務。

　　這次實習，是進行實戰性工作，學到了很多東西，我相信對以后的生活和工作都有很大的幫助。

　　篇【4】：做軟件開發項目實習的心得體會

　　一、前期規劃：

　　我理解的前期規劃是：在市場人員們匯總一個需求提交給產品專家帶領的產品經理團隊，然后經過這個團隊根據公司具體情況再次分析和規劃出一個最終需求文檔。

　　這個需求文檔應當首先提交給技術研發部門的負責人以及核心開發人員。由開發團隊對其進行技術和風險分析。如果對此需求統一有異議的地方，需要返回給產品團隊，重新修正需求。反復如此，直至需求完善準確，細致，清晰。

　　前期規劃就像高樓的地基，如果馬馬虎虎，就算是一塊磚塊沒擺好都可能導致整個高樓建設的失敗。在規劃中我認為，交流永遠是需要雙方積極主動，能認真聽取每個人的建議。前期工作思維不慎重，不細致，不認真，不夠完善，將產生連鎖效應直接導致整個工程和項目的失敗。

　　這種失敗可能表現為：第一種，軟件按需求實現但是功能根本不能滿足用戶需要。第二種，功能都有了，軟件沒有達到可用性、易用性。

　　對于第一種，當然是因為前期規劃疏漏了某些細小功能，沒能把需求文檔做完善。應該是規劃工作做的還不夠認真和細致。

　　對于第二種情況，我認為更多是在產品設計規劃方面經驗還不夠成熟。這種問題應該是很難避免的。因為每種新產品對產品團隊來說都很陌生。即使以前做過類似的東西，也難免面面俱到。這只能通過不斷努力和認真的態度來彌補。

　　前期規劃的交流涉及了市場、產品和技術研發等多個團隊之間。需要的不僅是團隊內部的交流，更多需要協調好團隊之間的交流。可能有時候需要公司高層和中層參與協調。

　　目前，很多開發人員深感項目的需求文檔寫的都很單薄。大家可以想一想，如果沒有好的開始，怎么會有好的結束呢?需求文檔單薄，不夠細致，由誰來繼續完善呢?難道讓程序員們自己去完善。我想程序員也可能沒有這種能力。對于程序員能把代碼寫的'很健壯很穩定就已經是很不容易的事情了。

　　二、概要設計：

　　我理解的概要設計步驟：(以項目為中心的開發流程)

　　1〉 項目經理仔細閱讀項目需求文檔。

　　2〉 項目經理召集項目開發成員，開項目啟動會議。具體商議項目的開發任務和責任分配。

　　3〉 核心開發人員開發確定，以及各模塊開發人員確定。

　　4〉 由系統分析員和核心開發人員仔細閱讀需求文檔，對系統整個架構分析和做技術規劃。

　　5〉 系統分析員整理和書寫最終的系統架構和概要設計文檔。

　　6〉 系統分析員在文檔提交日，提交給項目經理。項目經理確認文檔并審批。

　　7〉 項目經理召集項目開發成員，開一個概要設計以及系統架構確定的會議。向每個成員分發文檔，并討論確定最終概要設計文檔。

　　8〉開始詳細設計文檔的工作

　　做軟件開發項目實習的心得體會

　　三、詳細設計：

　　1〉 項目經理組織成立各個模塊的開發小組，并確定開發小組組長(程序經理)。

　　2〉 各開發組長書寫各自模塊的詳細設計文檔，開發成員需要協助，配合。

　　3〉 在指定提交日，開發組長提交文檔給系統分析員。由系統分析員審批。

　　4〉 系統分析員組織召開一個詳細設計文檔確認的會議。

　　5〉 然后開發組長分發各自模塊的詳細設計文檔給程序員，程序員在指定時間內完成。

　　6〉 程序員做內部測試。開發組長協調并配合。

　　7〉 確認無bug提交給開發組組長。

　　8〉 所有模塊整合工作，由整個開發組成員參與完成。由所有開發組長和系統分析員負責主要部分工作。程序員協助和配合。

　　9〉 對整合后工程做詳細測試。

　　10〉 確認測試通過后，開發組長根據開發成員表現以及提交成果填寫績效考核表。然后提交給項目經理。

　　11〉 項目經理會召開項目總結會，同時向優秀成員頒獎。同時鼓勵所有成員繼續努力。對不能按時完成導致項目能按時提交，以及對導致失敗的

　　關鍵人員給與懲罰處理。

　　當然，以上只是一個簡單的開發流程，一定是有很多不足的地方。希望能起到拋磚引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，關鍵還是在人本身了。沒有一個流程和制度，一個團隊也必將是一盤散沙。正所謂“無規矩無以成方圓”。這句話說得很有道理。

　　四、具體編碼：

　　開發幾個項目之后，對編寫程序有了更進一步的了解。

　　好的程序應該具有: 易讀性，易擴展性，容錯性。

　　易讀性: 所有變量和函數以及類名用簡單易懂易記憶的命名方式。所有類和函數甚至變量都有關鍵的注釋說明。這點很重要，也是最基礎的。如果代碼書寫不夠美觀和易懂，我想自己以后也不想再看。就更別談功能的擴展和新版本開發了。

　　易擴展性: 整體系統架構邏輯簡單清晰。模塊與模塊之間盡量做到互不影響，也就是盡可能的獨立。這部分工作主要體現在前期設計工作中，需要掌握好的設計經驗和方法才能夠做得比較好。

　　容錯性: 對數據流和指針以及數組都做數據有效性檢查;對第三方接口的調用失敗的容錯性。對所有代碼都做調用失敗后的錯誤處理。以及在大的工程中加入trace文件輸出，把關鍵的數據流和關鍵處理部分的操作信息輸出。以便對工程異常情況產生條件的定位，及時解決問題。

　　我覺得程序員能在這三方面做得很好就算一個優秀的programmer了。

　　五、調試、跟蹤與測試：

　　1 測試需要注意的：

　　對每個模塊的接口做測試，數據邊界的檢查。在對整個模塊做測試。

　　主要測試穩定性，效率以及功能是否正常。

　　確認單個模塊完全正常后，再加入工程。

　　在系統架構設計的時候，可能會引入原型參考。要對原型做完成測試后，確認沒有問題后，才可使用。

　　2 可以采用VC自帶Trace或者將信息輸出為文本文件的方式跟蹤程序并輸出關鍵信息，以便定位程序異常的原因。

　　3 對于通信模塊的測試，特別注意服務端和客戶端的數據流�？梢葬槍π缘膶懸粋�客戶端或服務端的測試程序，檢驗通訊過程是否正常。

　　4 在用VC做開發中，一定先要讓Debug版本正常運行，保證沒有任何異常，內存泄漏和Assert等調試警告信息。如果用到其他Lib,一定要保證Lib本身不存在問題。

　　這里只是提到一些自己容易忽略的東西，希望能對大家有所幫助，歡迎指正!謝謝。

【做軟件開發項目實習的心得體會】相關文章：

軟件開發項目實習心得體會09-24

做項目的心得體會10-17

淺談軟件開發項目的管理03-29

軟件開發與項目管理簡歷范文02-24

軟件開發項目經理的自我評價07-26

軟件開發項目管理制度01-15

項目管理在ASP軟件開發中的應用03-23

軟件開發-項目經理簡歷模板03-05

軟件開發實習報告01-02

軟件開發實習心得04-29