做軟件開發(fā)項目實習的心得體會

時間：2022-12-12 18:12:11 實習心得我要投稿

相關(guān)推薦

做軟件開發(fā)項目實習的心得體會

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

做軟件開發(fā)項目實習的心得體會

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

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

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

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

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

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

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

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

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

　　2、項目一定要企業(yè)真實項目，不能是精簡以后的，不能脫離實際應用系統(tǒng)，

　　3、在開發(fā)時要和企業(yè)的開發(fā)保持一致，

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

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

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

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

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

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

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

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

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

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

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

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

　　一、前期規(guī)劃：

　　我理解的前期規(guī)劃是：在市場人員們匯總一個需求提交給產(chǎn)品專家?guī)ьI的產(chǎn)品經(jīng)理團隊，然后經(jīng)過這個團隊根據(jù)公司具體情況再次分析和規(guī)劃出一個最終需求文檔。

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

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

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

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

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

　　前期規(guī)劃的交流涉及了市場、產(chǎn)品和技術(shù)研發(fā)等多個團隊之間。需要的不僅是團隊內(nèi)部的交流，更多需要協(xié)調(diào)好團隊之間的交流�？赡苡袝r候需要公司高層和中層參與協(xié)調(diào)。

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

　　二、概要設計：

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

　　1〉項目經(jīng)理仔細閱讀項目需求文檔。

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

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

　　4〉由系統(tǒng)分析員和核心開發(fā)人員仔細閱讀需求文檔，對系統(tǒng)整個架構(gòu)分析和做技術(shù)規(guī)劃。

　　5〉系統(tǒng)分析員整理和書寫最終的系統(tǒng)架構(gòu)和概要設計文檔。

　　6〉系統(tǒng)分析員在文檔提交日，提交給項目經(jīng)理。項目經(jīng)理確認文檔并審批。

　　7〉項目經(jīng)理召集項目開發(fā)成員，開一個概要設計以及系統(tǒng)架構(gòu)確定的會議。向每個成員分發(fā)文檔，并討論確定最終概要設計文檔。

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

　　做軟件開發(fā)項目實習的心得體會

　　三、詳細設計：

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

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

　　3〉在指定提交日，開發(fā)組長提交文檔給系統(tǒng)分析員。由系統(tǒng)分析員審批。

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

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

　　6〉程序員做內(nèi)部測試。開發(fā)組長協(xié)調(diào)并配合。

　　7〉確認無bug提交給開發(fā)組組長。

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

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

　　10〉確認測試通過后，開發(fā)組長根據(jù)開發(fā)成員表現(xiàn)以及提交成果填寫績效考核表。然后提交給項目經(jīng)理。

　　11〉項目經(jīng)理會召開項目總結(jié)會，同時向優(yōu)秀成員頒獎。同時鼓勵所有成員繼續(xù)努力。對不能按時完成導致項目能按時提交，以及對導致失敗的

　　關(guān)鍵人員給與懲罰處理。

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

　　四、具體編碼：

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

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

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

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

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

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

　　五、調(diào)試、跟蹤與測試：

　　1 測試需要注意的：

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

　　主要測試穩(wěn)定性，效率以及功能是否正常。

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

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

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

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

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

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

【做軟件開發(fā)項目實習的心得體會】相關(guān)文章：