- 相關(guān)推薦
做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )
現在很多行業(yè)都需要開(kāi)發(fā)軟件，軟件開(kāi)發(fā)需求越來(lái)越大。下文是做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )，希望可以幫到你們。
篇【1】：做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )
問(wèn)題，再也不可能以“逃避”而了之了。也讓我感覺(jué)到做為一個(gè)程序員所應該具備的基本素質(zhì)在這不到一個(gè)月的實(shí)習過(guò)程中也讓我深深體會(huì )到了作為一個(gè)合格的程序員應該具備的基本素質(zhì)。
團隊精神和協(xié)作能力是程序員應該具備的基本素質(zhì)，最近的工作中讓我深深休會(huì )到了這一點(diǎn)，由于小組成員配合不好，使本來(lái)很方便的cvs給自己的工作帶來(lái)的及大的麻煩，一不小心自己寫(xiě)的的東西就會(huì )被小組別的成員在上傳文件的時(shí)候給覆蓋掉，一整天的工作可能就這樣被反工，我們小組這次就是因為協(xié)作不好，導致各模塊之間不法連接，給工作帶來(lái)了及大的麻煩，消耗了大量的勞動(dòng)力還沒(méi)有提高工作效率。這使我深深的體會(huì )到：一個(gè)成功商業(yè)性軟件的開(kāi)發(fā)必須有一個(gè)有強大凝聚力的團隊，個(gè)人的力量是有限的，團隊精神和良好的協(xié)作會(huì )使我們做出優(yōu)秀的軟件。
良好的文檔是正規研發(fā)流程中非常重要的環(huán)節，作為代碼程序員，30%的工作時(shí)間寫(xiě)技術(shù)文檔是很正常的，缺乏文檔，一個(gè)軟件系統就缺乏生命力，在未來(lái)的查錯，升級以及模塊的`復用時(shí)就都會(huì )遇到極大的麻煩。這次的這個(gè)小小的項目，就因為文檔上的一點(diǎn)點(diǎn)理解錯誤讓我們花了很大的工夫去改代碼，改頁(yè)面。很慶幸的是，這是一個(gè)小項目，要是大項目，這種問(wèn)題可能就會(huì )導致大量的代碼修改，可見(jiàn)文檔在一個(gè)項目中起者巨大的做用。
此外，良好的代碼編寫(xiě)習慣，不但有助于代碼的移植和糾錯，也有助于不同技術(shù)人員之間的協(xié)作。作為一個(gè)程序員，對需求的理解能力也是很重要的，只有真正理解了一個(gè)模塊的作用，才會(huì )寫(xiě)出高效率的代碼，才能使整個(gè)軟件項目作出來(lái)更加優(yōu)秀，具備更好的安全性和穩定性，我在寫(xiě)代碼的過(guò)程中就遇到了需求理解上的問(wèn)題，使得寫(xiě)出來(lái)的代碼功能不全，幸好不是給客戶(hù)發(fā)現在，要不，這個(gè)軟件的商業(yè)價(jià)值可能就會(huì )打折扣了。單元測試對于一個(gè)程序員來(lái)說(shuō)是不可不做的一項工作，不做好測試就會(huì )給后期的集成工作帶來(lái)麻煩，往往為了一個(gè)小問(wèn)題會(huì )讓我們查找好多模塊，給后期工作帶來(lái)很大麻煩。
這一段時(shí)間的工作也讓我明白了一點(diǎn)：一個(gè)優(yōu)秀的程序員必須不斷的學(xué)習，隨時(shí)總結，找到自己的不足，這樣逐步提高，才能讓自己很快的成長(cháng)起來(lái)。
篇【2】：做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )
作為就業(yè)培訓，項目的好壞對培訓質(zhì)量的影響十分大，常常是決定性的作用。這篇文章是關(guān)于在學(xué)習JAVA軟件開(kāi)發(fā)時(shí)練習項目的總結，簡(jiǎn)單總結為以下幾點(diǎn)：作為就業(yè)培訓，項目的好壞對培訓質(zhì)量的影響十分大，常常是決定性的作用。這篇文章是關(guān)于在學(xué)習JAVA軟件開(kāi)發(fā)時(shí)練習項目的總結，簡(jiǎn)單總結為以下幾點(diǎn)：
1、項目一定要全新的項目，不能是以前做過(guò)的，
2、項目一定要企業(yè)真實(shí)項目，不能是精簡(jiǎn)以后的，不能脫離實(shí)際應用系統，
3、在開(kāi)發(fā)時(shí)要和企業(yè)的開(kāi)發(fā)保持一致，
4、在做項目的時(shí)候不應該有參考代碼。
長(cháng)話(huà)短說(shuō)就是以上幾點(diǎn)，如果你想要的了解，可以繼續往后看。
一：項目的地位因為參加就業(yè)培訓的學(xué)員很多都是有一定的計算機基礎，大部分都具備一定的編程基礎，尤其是在�；蛘呤莿偖厴I(yè)的學(xué)生，多少都有一些基礎。他們欠缺的主要是兩點(diǎn)：(1)不能全面系統的、深入的掌握某種技術(shù)，也就是會(huì )的挺多，但都是皮毛，不能滿(mǎn)足就業(yè)的需要。(2)沒(méi)有任何實(shí)際的開(kāi)發(fā)經(jīng)驗，完全是想象中學(xué)習，考試還行，一到實(shí)際開(kāi)發(fā)和應用就歇菜了。解決的方法就是通過(guò)項目練習，對所學(xué)知識進(jìn)行深化，然后通過(guò)項目來(lái)獲取實(shí)際開(kāi)發(fā)的經(jīng)驗，從而彌補這些不足，盡快達到企業(yè)的實(shí)際要求。
二：如何選擇項目項目既然那么重要，肯定不能隨隨便便找項目，那么究竟如何來(lái)選擇呢?根據Java的研究和實(shí)踐經(jīng)驗總結，選擇項目的時(shí)候要注意以下方面：
1：項目不能太大，也不能太小這個(gè)要根據項目練習的階段，練習的時(shí)間，練習的目標來(lái)判斷。不能太大，太大了做不完，也不能太小，太小了沒(méi)有意義，達不到練習的目的。
2：項目不能脫離實(shí)際應用系統項目應該是實(shí)際的系統，或者是實(shí)際系統的簡(jiǎn)化和抽象，不能夠是沒(méi)有實(shí)戰意義的教學(xué)性或者是純練習性的項目。因為培訓的'時(shí)間有限，必須讓學(xué)員盡快地融入到實(shí)際項目的開(kāi)發(fā)當中去。任何人接受和掌握一個(gè)東西都需要時(shí)間去適應，需要重復幾次才能夠真正掌握，所以每個(gè)項目都必須跟實(shí)際應用掛鉤。
3：項目應能覆蓋所學(xué)的主要知識點(diǎn) 學(xué)以致用，學(xué)完的知識點(diǎn)需要到應用中使用，才能夠真正理解和掌握，再說(shuō)了，軟件開(kāi)發(fā)是一個(gè)動(dòng)手能力要求很高的行業(yè)，什么算會(huì )了，那就是能夠做出來(lái)，寫(xiě)出代碼來(lái)，把問(wèn)題解決了，你就算會(huì )了。
4：最后綜合項目一定要是實(shí)際應用系統學(xué)員經(jīng)過(guò)這個(gè)項目的練習，就要走上實(shí)際的工作崗位了，如果這個(gè)系統還達不到實(shí)際應用系統的標準，學(xué)員練習過(guò)后也還是達不到企業(yè)實(shí)際的需要，那么這個(gè)培訓應該說(shuō)質(zhì)量就不高了。理想的狀況是這個(gè)項目就是實(shí)際項目，到時(shí)候學(xué)員就業(yè)到另外一個(gè)公司，不過(guò)是換個(gè)地方干活而已，完全沒(méi)有技能上的問(wèn)題。
篇【3】：做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )
經(jīng)過(guò)為期4個(gè)月的專(zhuān)業(yè)實(shí)習，令我更深一步的了解和學(xué)習了軟件開(kāi)發(fā)的一般過(guò)程，不再是以前那樣，都不知道軟件開(kāi)發(fā)是什么東西。對于一個(gè)應用系統他們?yōu)槭裁匆敲炊嗳藖?lái)做，而這么多人一起做，代碼又是如何進(jìn)行管理的。對于每一個(gè)應用系統，企業(yè)到底用到哪些技術(shù)，他們?yōu)槭裁匆x擇這些技術(shù)，我們開(kāi)發(fā)人員的主要任務(wù)是什么等等，這些概念都漸漸的清晰。人，孰能無(wú)過(guò)，過(guò)而改之，善莫大焉!沒(méi)有誰(shuí)，在編寫(xiě)代碼的過(guò)程中永遠不會(huì )犯錯，即使他非常的厲害，那也是從不斷的犯錯過(guò)程中鍛煉出來(lái)的，但亦有“犯錯”的時(shí)候，因為需求是不斷的改變的，即使你當時(shí)沒(méi)錯，但需求改了之后，你的代碼不符合需求，那也是你的錯。有錯那當然就要調試咯，以前老是害怕出錯，找不到問(wèn)題所在是件令人煩惱的事。但是當調試的`錯誤多了之后，你就會(huì )發(fā)現，每當一看到相類(lèi)似的錯誤之后，你就會(huì )立即知道這個(gè)錯誤是什么原因造成的!所以，我們不應該害怕出錯，應該把調試錯誤當成一種提高個(gè)人能力的方式。對于測試人員發(fā)回來(lái)的bug我們要認真的對待，造成這種bug就證明了我們的思路還是不怎么的清晰，所以有必要再去看看相關(guān)的資料。溝通是人與人之間傳遞信息的途徑，好的溝通能很完美的傳達你的思想，你的見(jiàn)解。在企業(yè)中，每一個(gè)系統的開(kāi)發(fā)過(guò)程一般來(lái)說(shuō)都不是一個(gè)人從頭做到尾的，一般都有分工的，如此一來(lái)，溝通就必不可少了，因為你要把你做的工作，你為什么這樣做，告訴別人，別人才更好的去完成他的任務(wù)。
這次實(shí)習，是進(jìn)行實(shí)戰性工作，學(xué)到了很多東西，我相信對以后的生活和工作都有很大的幫助。
篇【4】：做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )
一、前期規劃：
我理解的前期規劃是：在市場(chǎng)人員們匯總一個(gè)需求提交給產(chǎn)品專(zhuān)家帶領(lǐng)的產(chǎn)品經(jīng)理團隊，然后經(jīng)過(guò)這個(gè)團隊根據公司具體情況再次分析和規劃出一個(gè)最終需求文檔。
這個(gè)需求文檔應當首先提交給技術(shù)研發(fā)部門(mén)的負責人以及核心開(kāi)發(fā)人員。由開(kāi)發(fā)團隊對其進(jìn)行技術(shù)和風(fēng)險分析。如果對此需求統一有異議的地方，需要返回給產(chǎn)品團隊，重新修正需求。反復如此，直至需求完善準確，細致，清晰。
前期規劃就像高樓的地基，如果馬馬虎虎，就算是一塊磚塊沒(méi)擺好都可能導致整個(gè)高樓建設的失敗。在規劃中我認為，交流永遠是需要雙方積極主動(dòng)，能認真聽(tīng)取每個(gè)人的建議。前期工作思維不慎重，不細致，不認真，不夠完善，將產(chǎn)生連鎖效應直接導致整個(gè)工程和項目的失敗。
這種失敗可能表現為：第一種，軟件按需求實(shí)現但是功能根本不能滿(mǎn)足用戶(hù)需要。第二種，功能都有了，軟件沒(méi)有達到可用性、易用性。
對于第一種，當然是因為前期規劃疏漏了某些細小功能，沒(méi)能把需求文檔做完善。應該是規劃工作做的還不夠認真和細致。
對于第二種情況，我認為更多是在產(chǎn)品設計規劃方面經(jīng)驗還不夠成熟。這種問(wèn)題應該是很難避免的。因為每種新產(chǎn)品對產(chǎn)品團隊來(lái)說(shuō)都很陌生。即使以前做過(guò)類(lèi)似的東西，也難免面面俱到。這只能通過(guò)不斷努力和認真的態(tài)度來(lái)彌補。
前期規劃的交流涉及了市場(chǎng)、產(chǎn)品和技術(shù)研發(fā)等多個(gè)團隊之間。需要的不僅是團隊內部的交流，更多需要協(xié)調好團隊之間的交流�？赡苡袝r(shí)候需要公司高層和中層參與協(xié)調。
目前，很多開(kāi)發(fā)人員深感項目的需求文檔寫(xiě)的都很單薄。大家可以想一想，如果沒(méi)有好的開(kāi)始，怎么會(huì )有好的結束呢?需求文檔單薄，不夠細致，由誰(shuí)來(lái)繼續完善呢?難道讓程序員們自己去完善。我想程序員也可能沒(méi)有這種能力。對于程序員能把代碼寫(xiě)的'很健壯很穩定就已經(jīng)是很不容易的事情了。
二、概要設計：
我理解的概要設計步驟：(以項目為中心的開(kāi)發(fā)流程)
1〉 項目經(jīng)理仔細閱讀項目需求文檔。
2〉 項目經(jīng)理召集項目開(kāi)發(fā)成員，開(kāi)項目啟動(dòng)會(huì )議。具體商議項目的開(kāi)發(fā)任務(wù)和責任分配。
3〉 核心開(kāi)發(fā)人員開(kāi)發(fā)確定，以及各模塊開(kāi)發(fā)人員確定。
4〉 由系統分析員和核心開(kāi)發(fā)人員仔細閱讀需求文檔，對系統整個(gè)架構分析和做技術(shù)規劃。
5〉 系統分析員整理和書(shū)寫(xiě)最終的系統架構和概要設計文檔。
6〉 系統分析員在文檔提交日，提交給項目經(jīng)理。項目經(jīng)理確認文檔并審批。
7〉 項目經(jīng)理召集項目開(kāi)發(fā)成員，開(kāi)一個(gè)概要設計以及系統架構確定的會(huì )議。向每個(gè)成員分發(fā)文檔，并討論確定最終概要設計文檔。
8〉開(kāi)始詳細設計文檔的工作
做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )
三、詳細設計：
1〉 項目經(jīng)理組織成立各個(gè)模塊的開(kāi)發(fā)小組，并確定開(kāi)發(fā)小組組長(cháng)(程序經(jīng)理)。
2〉 各開(kāi)發(fā)組長(cháng)書(shū)寫(xiě)各自模塊的詳細設計文檔，開(kāi)發(fā)成員需要協(xié)助，配合。
3〉 在指定提交日，開(kāi)發(fā)組長(cháng)提交文檔給系統分析員。由系統分析員審批。
4〉 系統分析員組織召開(kāi)一個(gè)詳細設計文檔確認的會(huì )議。
5〉 然后開(kāi)發(fā)組長(cháng)分發(fā)各自模塊的詳細設計文檔給程序員，程序員在指定時(shí)間內完成。
6〉 程序員做內部測試。開(kāi)發(fā)組長(cháng)協(xié)調并配合。
7〉 確認無(wú)bug提交給開(kāi)發(fā)組組長(cháng)。
8〉 所有模塊整合工作，由整個(gè)開(kāi)發(fā)組成員參與完成。由所有開(kāi)發(fā)組長(cháng)和系統分析員負責主要部分工作。程序員協(xié)助和配合。
9〉 對整合后工程做詳細測試。
10〉 確認測試通過(guò)后，開(kāi)發(fā)組長(cháng)根據開(kāi)發(fā)成員表現以及提交成果填寫(xiě)績(jì)效考核表。然后提交給項目經(jīng)理。
11〉 項目經(jīng)理會(huì )召開(kāi)項目總結會(huì )，同時(shí)向優(yōu)秀成員頒獎。同時(shí)鼓勵所有成員繼續努力。對不能按時(shí)完成導致項目能按時(shí)提交，以及對導致失敗的
關(guān)鍵人員給與懲罰處理。
當然，以上只是一個(gè)簡(jiǎn)單的開(kāi)發(fā)流程，一定是有很多不足的地方。希望能起到拋磚引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，關(guān)鍵還是在人本身了。沒(méi)有一個(gè)流程和制度，一個(gè)團隊也必將是一盤(pán)散沙。正所謂“無(wú)規矩無(wú)以成方圓”。這句話(huà)說(shuō)得很有道理。
四、具體編碼：
開(kāi)發(fā)幾個(gè)項目之后，對編寫(xiě)程序有了更進(jìn)一步的了解。
好的程序應該具有: 易讀性，易擴展性，容錯性。
易讀性: 所有變量和函數以及類(lèi)名用簡(jiǎn)單易懂易記憶的命名方式。所有類(lèi)和函數甚至變量都有關(guān)鍵的注釋說(shuō)明。這點(diǎn)很重要，也是最基礎的。如果代碼書(shū)寫(xiě)不夠美觀(guān)和易懂，我想自己以后也不想再看。就更別談功能的擴展和新版本開(kāi)發(fā)了。
易擴展性: 整體系統架構邏輯簡(jiǎn)單清晰。模塊與模塊之間盡量做到互不影響，也就是盡可能的獨立。這部分工作主要體現在前期設計工作中，需要掌握好的設計經(jīng)驗和方法才能夠做得比較好。
容錯性: 對數據流和指針以及數組都做數據有效性檢查;對第三方接口的調用失敗的容錯性。對所有代碼都做調用失敗后的錯誤處理。以及在大的工程中加入trace文件輸出，把關(guān)鍵的數據流和關(guān)鍵處理部分的操作信息輸出。以便對工程異常情況產(chǎn)生條件的定位，及時(shí)解決問(wèn)題。
我覺(jué)得程序員能在這三方面做得很好就算一個(gè)優(yōu)秀的programmer了。
五、調試、跟蹤與測試：
1 測試需要注意的：
對每個(gè)模塊的接口做測試，數據邊界的檢查。在對整個(gè)模塊做測試。
主要測試穩定性，效率以及功能是否正常。
確認單個(gè)模塊完全正常后，再加入工程。
在系統架構設計的時(shí)候，可能會(huì )引入原型參考。要對原型做完成測試后，確認沒(méi)有問(wèn)題后，才可使用。
2 可以采用VC自帶Trace或者將信息輸出為文本文件的方式跟蹤程序并輸出關(guān)鍵信息，以便定位程序異常的原因。
3 對于通信模塊的測試，特別注意服務(wù)端和客戶(hù)端的數據流�？梢葬槍π缘膶�(xiě)一個(gè)客戶(hù)端或服務(wù)端的測試程序，檢驗通訊過(guò)程是否正常。
4 在用VC做開(kāi)發(fā)中，一定先要讓Debug版本正常運行，保證沒(méi)有任何異常，內存泄漏和Assert等調試警告信息。如果用到其他Lib,一定要保證Lib本身不存在問(wèn)題。
這里只是提到一些自己容易忽略的東西，希望能對大家有所幫助，歡迎指正!謝謝。
【做軟件開(kāi)發(fā)項目實(shí)習的心得體會(huì )】相關(guān)文章：
軟件開(kāi)發(fā)項目實(shí)習心得體會(huì )09-24
做項目的心得體會(huì )10-17
淺談軟件開(kāi)發(fā)項目的管理03-29
軟件開(kāi)發(fā)與項目管理簡(jiǎn)歷范文02-24
軟件開(kāi)發(fā)項目經(jīng)理的自我評價(jià)07-26
軟件開(kāi)發(fā)項目管理制度01-15
項目管理在A(yíng)SP軟件開(kāi)發(fā)中的應用03-23