第一篇：軟件開發心得總結

有感于網盤開發過程

有感于網盤開發過程............................1

一、軟件開發個人體會：......................2

二、做軟件開發我覺得要明白：........................2

三、在開發中遇到問題應該怎么去解決？................2

四、怎么樣才能提高自身的能力？.....................2

五、怎么樣才能做好軟件開發？........................2

六、文檔的重要性...........................3

七、我的收獲............................3

八、網盤項目開發的最大體會.....................4

九、軟件測試（單體測試和連接測試）....................4常熟理工學院SIG小組3/28/2013

一、軟件開發個人體會：

1.軟件領域中的知識在于積累。

2.做軟件開發，就類似算數學題和世界杯足球賽一樣：重在結果，而不在乎過程。

3.軟件服務于人類，軟件是在解決一些生活中的問題和錯誤，問題決定解決方案。

二、做軟件開發我覺得要明白：

1.職業的樂趣：

(A)用自己的智慧去創建新事物的快樂

(B)開發對別人有用的東西

(C)不斷學習來充實自己

2.職業的苦惱:

(A)總是追求完美

(B)所有要實現的功能由他人而定

(C)概念設計計是有趣的，但找Bug總是很苦惱的三、在開發中遇到問題應該怎么去解決？

1.2.3.4.不明白就多問，不要自已一直去琢磨。一個問題如果30分鐘還沒有解決就應該考慮是不是問問別人。一個問題在沒有用過3種以上的方法解決過就不要去問別人。解決問題思路是關鍵：

相信問題總歸有解決的辦法，就算連技術上都沒法實現的問題，相信通過良好的溝通終究也會有解決的方法。

5.解決問題的前提是：理解別人的意思，理解別人的需求，多溝通，及時給客戶反饋信息。

四、怎么樣才能提高自身的能力？

1.程序員怎么樣進步最快？ － 理論結合實踐

2.不要怕出錯，不怕遇到錯誤，有錯誤就有挑戰，這樣才可以進步，但不要讓同一個石頭

把你絆倒2次。

五、怎么樣才能做好軟件開發？

1.首先要明白解決的問題是什么，理解問題，其次再決定怎么解決這個問題

2.碰到很復雜的問題，我們就簡單想，把問題簡單化，細化到能夠實現為止

3.出了問題，我們要先分析問題，然后知道引起問題的原因，最后并想出問題的解決辦法

4.我們應該從2個方面去把握一個項目：從業務角度和項目的關鍵問題上去把握一個項目

(A)從不同的系統場景

(B)從不同的用戶角色（充當什么角色）

(C)從不同的系統使用角度（擁有那些權限）

5.其實我覺得開發人員說實在應該要比使用系統的人更了解系統需求，只有真正徹底的了

解了項目的業務需求，我們才能做真的做好這個項目

六、文檔的重要性

記得我當初剛開發項目的時候都是寫個大致的需求說明書，做一個E-R圖，畫幾個大致的數據流程圖，然后建立數據字典和表結構關系。再接著搭建一個開發環境，配置幾臺服務器，劃分一下模塊，分工，我們就可以Coding了，一直到項目結束了，也沒有完整的設計文檔，更沒有完整的測試文檔，雖然這樣的確是很快的完成了Coding工作，感覺上好像節省了好多成本和開發時間，但后期的維護和Bug 就是經常出現的事。

小項目沒有文檔關系不大，但如果遇到一個大項目的時候，那這樣的開發方式就很有問題很危險的。

大項目沒有文檔： 首先維護就很麻煩，也很亂，寫的代碼，過幾天都不知道它是完成什么功能的了，其次系統的穩定性和可靠性也讓人懷疑，擴展性就不用說了。

七、我的收獲

A.程序員大多都不喜歡寫文檔,我們以前也是特討厭,記得以前都是系統開發完了，為了應付項目驗收，就匆匆忙忙的一組人在那里補文檔。在我們的思想里,所謂的文檔就是一些廢話,一句話硬是用十句話來代替的無聊透頂。

B.代碼風格要規范

以前做項目，我們都是不怎么去注意代碼風格和寫代碼的規范，都是稍微想一下就直接開始寫代碼了。注釋也很少用，總感覺我們自己寫的代碼，我們怎么會不知道它做了些什么事呢 ？總覺得我們自己寫的代碼我們怎么會不知道它是用來做什么的呢。一直都不相信這是個事實，但事實上，項目驗收后，系統剛開始使用的人少，也就不會出現潛在的錯誤，隨著時間的增加，久而久之，當大量用戶并發訪問的時候，系統的Bug 就暴漏出來了，那時你再用熟悉的Eclipse打開整個項目的源碼時，再去看自己寫的代碼的時候，真的發現，我們定義的這個變量名是什么意思啊 ？ 我們的這個Flag 是用來判斷什么的啊 ？我們的if（）中條件不知道是判斷什么？ Function（）也忘記是什么功能了？ 想想好可怕啊。難道真的都忘記了嗎 ？回答是肯定的： 真的忘了。

C.心得體會:

通過做該網盤項目，在這2年的鍛煉中，我們才真的體會到，良好的文檔是正規研發流程中非常重要的環節,一個好的程序是先寫好設計文檔再進行編程的，在設計文檔的指導下，才能寫出安全的代碼。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設計好的路線走，而是想到哪寫到哪。小功能還好說，要是大功能，就容易混亂.剛開始我們還很不習慣這一系列的編程風格，很多的規范，尤其是命名，方法和注釋，都有這著很多限制，讓我們覺得真羅唆，寫個程序完成功能不就可以了嗎，明明1小時做完的事情非得讓人用3、4個小時去做，我們現在真的明白這樣做的好處了，我們已經習慣這樣的編程風格了，這也養成了我們的一個編程習慣了，深有體會啊。

最忙的時候就是我們成長和收獲最多的時候。

八、網盤項目開發的最大體會

我們覺得項目開發的開始時候，應該由項目負責人很好的對項目是什么項目，具體大概做什么事情，是誰提出來的，目的是解決什么問題，以及里面用到的很多專有名詞做個細致的說明，而不是從一開始就分幾本式樣書，給個靜態Html 的Demo看看，然后搭建好開發環境就按照式樣設計書來開發。

九、軟件測試（單體測試和連接測試）

我們首先認為，編寫程序的時候不要想出了問題再解決，而是要想如何不會出現問題，要根據經驗來預測可能出現的問題，然后避免出現。

測試，說的直接點就是給軟件找錯誤。

很多人認為發現錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上我們不這么認為。

我們覺得對開發人員來說，我們要把測試出來的Bug都應該做個分析，知道錯的原因之后，我們就應該在下個項目中防止類似的錯誤發生，而真正來提高我們開發的效率。

第二篇：軟件開發心得總結

有感于網盤開發過程

有感于網盤開發過程..............................................................................................................................1

一、軟件開發個人體會：.................................................................................................................2

二、做軟件開發我覺得要明白：.....................................................................................................2

三、在開發中遇到問題應該怎么去解決？......................................................................................2

四、怎么樣才能提高自身的能力？..................................................................................................2

五、怎么樣才能做好軟件開發？.....................................................................................................2

六、文檔的重要性.............................................................................................................................3

七、我的收獲.....................................................................................................................................3

八、網盤項目開發的最大體會.........................................................................................................4

九、軟件測試（單體測試和連接測試）..........................................................................................4

常熟理工學院SIG小組

3/28/2013

一、軟件開發個人體會：

1.軟件領域中的知識在于積累。

2.做軟件開發，就類似算數學題和世界杯足球賽一樣：重在結果，而不在乎過程。3.軟件服務于人類，軟件是在解決一些生活中的問題和錯誤，問題決定解決方案。

二、做軟件開發我覺得要明白：

1.職業的樂趣：

(A)用自己的智慧去創建新事物的快樂(B)開發對別人有用的東西(C)不斷學習來充實自己 2.職業的苦惱:(A)總是追求完美

(B)所有要實現的功能由他人而定

(C)概念設計計是有趣的，但找Bug總是很苦惱的

三、在開發中遇到問題應該怎么去解決？

1.2.3.4.不明白就多問，不要自已一直去琢磨。

一個問題如果30分鐘還沒有解決就應該考慮是不是問問別人。一個問題在沒有用過3種以上的方法解決過就不要去問別人。解決問題思路是關鍵：

相信問題總歸有解決的辦法，就算連技術上都沒法實現的問題，相信通過良好的溝通終究也會有解決的方法。

5.解決問題的前提是：理解別人的意思，理解別人的需求，多溝通，及時給客戶反饋信息。

四、怎么樣才能提高自身的能力？

1.程序員怎么樣進步最快？ － 理論結合實踐

2.不要怕出錯，不怕遇到錯誤，有錯誤就有挑戰，這樣才可以進步，但不要讓同一個石頭把你絆倒2次。

五、怎么樣才能做好軟件開發？

1.首先要明白解決的問題是什么，理解問題，其次再決定怎么解決這個問題 2.碰到很復雜的問題，我們就簡單想，把問題簡單化，細化到能夠實現為止

常熟理工學院SIG小組

3/28/2013

3.出了問題，我們要先分析問題，然后知道引起問題的原因，最后并想出問題的解決辦法 4.我們應該從2個方面去把握一個項目：從業務角度和項目的關鍵問題上去把握一個項目

(A)從不同的系統場景

(B)從不同的用戶角色（充當什么角色）(C)從不同的系統使用角度（擁有那些權限）

5.其實我覺得開發人員說實在應該要比使用系統的人更了解系統需求，只有真正徹底的了解了項目的業務需求，我們才能做真的做好這個項目

六、文檔的重要性

記得我當初剛開發項目的時候都是寫個大致的需求說明書，做一個E-R圖，畫幾個大致的數據流程圖，然后建立數據字典和表結構關系。再接著搭建一個開發環境，配置幾臺服務器，劃分一下模塊，分工，我們就可以Coding了，一直到項目結束了，也沒有完整的設計文檔，更沒有完整的測試文檔，雖然這樣的確是很快的完成了Coding工作，感覺上好像節省了好多成本和開發時間，但后期的維護和Bug 就是經常出現的事。

小項目沒有文檔關系不大，但如果遇到一個大項目的時候，那這樣的開發方式就很有問題很危險的。

大項目沒有文檔： 首先維護就很麻煩，也很亂，寫的代碼，過幾天都不知道它是完成什么功能的了，其次系統的穩定性和可靠性也讓人懷疑，擴展性就不用說了。

七、我的收獲

A.程序員大多都不喜歡寫文檔,我們以前也是特討厭,記得以前都是系統開發完了，為了應付項目驗收，就匆匆忙忙的一組人在那里補文檔。在我們的思想里,所謂的文檔就是一些廢話,一句話硬是用十句話來代替的無聊透頂。B.代碼風格要規范

以前做項目，我們都是不怎么去注意代碼風格和寫代碼的規范，都是稍微想一下就直接開始寫代碼了。注釋也很少用，總感覺我們自己寫的代碼，我們怎么會不知道它做了些什么事呢 ？總覺得我們自己寫的代碼我們怎么會不知道它是用來做什么的呢。一直都不相信這是個事實，但事實上，項目驗收后，系統剛開始使用的人少，也就不會出現潛在的錯誤，隨著時間的增加，久而久之，當大量用戶并發訪問的時候，系統的Bug 就暴漏出來了，那時你再用熟悉的Eclipse打開整個項目的源碼時，再去看自己寫的代碼的時候，真的發現，我們定義的這個變量名是什么意思啊 ？ 我們的這個Flag 是用來判斷什么的啊 ？我們的if（）中條件不知道是判斷什么？ Function（）也忘記是什么功能了？ 想想好可怕啊。難道真的都忘記了嗎 ？回答是肯定的： 真的忘了。C.心得體會: 通過做該網盤項目，在這2年的鍛煉中，我們才真的體會到，良好的文檔是正規研發流程中非常重要的環節,一個好的程序是先寫好設計文檔再進行編程的，在設計文檔的指導下，才能寫出安全的代碼。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設計好的路線走，而是想到哪寫到哪。小功能還好說，要是大功能，就容易混亂.常熟理工學院SIG小組

3/28/2013

剛開始我們還很不習慣這一系列的編程風格，很多的規范，尤其是命名，方法和注釋，都有這著很多限制，讓我們覺得真羅唆，寫個程序完成功能不就可以了嗎，明明1小時做完的事情非得讓人用3、4個小時去做，我們現在真的明白這樣做的好處了，我們已經習慣這樣的編程風格了，這也養成了我們的一個編程習慣了，深有體會啊。

最忙的時候就是我們成長和收獲最多的時候。

八、網盤項目開發的最大體會

我們覺得項目開發的開始時候，應該由項目負責人很好的對項目是什么項目，具體大概做什么事情，是誰提出來的，目的是解決什么問題，以及里面用到的很多專有名詞做個細致的說明，而不是從一開始就分幾本式樣書，給個靜態Html 的Demo看看，然后搭建好開發環境就按照式樣設計書來開發。

九、軟件測試（單體測試和連接測試）

我們首先認為，編寫程序的時候不要想出了問題再解決，而是要想如何不會出現問題，要根據經驗來預測可能出現的問題，然后避免出現。

測試，說的直接點就是給軟件找錯誤。

很多人認為發現錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上我們不這么認為。

我們覺得對開發人員來說，我們要把測試出來的Bug都應該做個分析，知道錯的原因之后，我們就應該在下個項目中防止類似的錯誤發生，而真正來提高我們開發的效率。

常熟理工學院SIG小組

3/28/2013

第三篇：軟件開發心得

軟件開發心得體會

08軟件（1）班 陳會敏 24號

歲月流轉，時光匆匆，轉眼間我的大學生活已經接近了尾聲。回首往昔，有太多美好的，也有太多艱辛。我的大學生活的主旋律還是學習，我所選學的專業是軟件技術，在這條道路上走了那么久，也有一些小小的感悟與體會。

還記得上初中時，英語課本上有一篇關于比爾蓋茨的文章，當時真的很佩服比爾蓋茨，也就是那時我才第一次接觸到軟件一詞，學過那篇文章后我有個想法，就是也要做個比爾蓋茨，可是由于家庭條件的限制，那也只能是個美好的夢想。后來上了高中，再報考時我就選擇了軟件技術這個專業，這樣我想就向那個遙遠而又美好的夢想邁進了一點點吧。

然而當我真正上了大學，學了這個專業，我才知道要做個比爾蓋茨是多么的難，要想學好我的專業要花費很大的精力。第一學期我們開設了C語言這門課程，當時我學著真的是云里霧里、一竅不通，很是失落，學了不久之后我開始覺得自己可能并不喜歡這個專業，只是一時昏了頭，錯以為喜歡了。現實的打擊讓我有點不知所措，然而我已經選擇了它，有句話說：既然選擇了遠方便只顧風雨兼程。我既然選擇了這個專業，我便也只有硬著頭皮也要走下去了。有了這樣的想法之后，在之后的一段時間里，只要是沒課的時候我就抱起了C語言課本，努力的看，記語法知識，語法規則，學語句、小算法等等。經過一段時間的研究學習，我發現C語言并沒有我想象中的那么難

了，還是很有意思的。就這樣在學與玩中我的大學第一個星期就過完了。

后來又開設了很多課程，有VB、網絡、數據庫、操作系統、數據結構等。在這些課程中最令我頭疼的就是數據庫了，老師講的時候老是劃重點，講的很少，當時學的時候真的好難受，一學期下來啥也不會，后來看書上的操作，一步一步的操作，才終于學會了建個數據庫，做下備份還原等操作。開設的那么多課程也有我很喜歡的課程，比如數據結構，這門課程理論的比較多，上機操作的很少，這門課程是很需要理解的，當然有的還是要死記的。學習這門課的時候，我覺得并不像其它課程那么吃力，可能高中是學理科的緣故吧，理解起來并不太費勁。所以當時就很喜歡這門課，然而這門課表皮的好學，但要深學起來還是很有難度的，所以期末考試的時候我的成績并不太理想，但這些打擊不了我對它的興趣，至少我知道我所學的這個專業還是有很多我是很喜歡的。

這樣走著走著就到了大二的下學期了，那個學期，我們有一門課是C++，這門課的老師很和藹，能力也很高，從他那里我學到了很多東西。老師教給了我們很多算法，也很系統的講解了語法知識，還教我們做小系統，有的時候他會給我門們一些小系統的代碼，讓我們去改寫，剛開始的時候我也是不會，后來經過學習請教改寫成功了，這個時候我就會很開心，很有成就感。就這樣在學與玩中，在快樂和憂愁中我們迎來了我們的大三時光。

大三剛一開學，老師們就告訴我們這學期就上十二周的課，然后

就考試，就畢業了。這讓我很有緊迫感，一想到畢業在即，心頭就有種不舍，這兒有我美好的時光，然而我就要對這里說再見了。大三了我們的課全變成了專業課，也幾乎全成了上機課，老師還給我們布置了一個程序，就是一個小組要交一個系統來算作成績。我們這小組所選的課題是圖書管理系統，針對這個系統，我們上機的時候，利用網絡資源在網上查找了相關的資料，因為說實話，我們對此并不太理解，也只有通過網絡來查找信息，做好需求分析，功能模塊設計等工作。在這同時我們還去了學校的圖書館理解了相關的信息，這個系統并不要求功能有多么強大，關鍵在與一種鍛煉，思維的鍛煉，對所學東西的總結等。建立數據庫時我們就根據需要建立幾個表，里面的數據也是從我們學校圖書館里找來的。后來的界面設計，為了追求美觀，我們又在網上搜了很多美麗的圖片來美化界面。具體到功能的時候，有很多東西都不會，后來老師在課堂在做了講解，我們就把它用到了我們的系統中，真的就是學一步做一步的。整個的系統做下來，我學到了很多東西，也對那么知識有了很好的應用能力。

現在這個星期也就到了期末，這短暫的校園時光也在飛速的流逝著。回首過去學習的經歷，真是苦中有樂，樂中亦多苦，然而無論如何這些都已經走過去了，未來的路還要我們好好的走下去。人生本就是一個不斷的學習的過程，也是一個不斷完善的過程，在未來的道路上我會更加努力地學習，走出一個美好的人生。

第四篇：軟件開發實習心得

軟件開發實習心得

參加軟件開發實習的同學，你們從中收獲了哪些實習心得?不妨分享一下吧!以下是軟件開發實習心得，歡迎閱覽!

軟件開發實習心得1

不知不覺，在XX實習的日子快過去半個月了，記得剛來XX的頭幾天，感覺非常不適應。首先是環境：這里吃的東西很貴，而且這里的物價很高。其次是XX人：XX人辦事的效率很高，這就是鐵人的精神吧。

對于以上種種，待了3，4天基本就適應了，難怪一些長輩老是說：習慣了，就好了。

來的第一天，我們聽了付X萍老師講了一節課，可以說完全不知所云，但還是可以聽到一些東西的，譬如：工作環境的適應，人與人之間的交際，處理各種事情的能力，其中最重要的就是養成良好的工作習慣。有良好的工作習慣，才會被上司，老板和同事認可，將來也會比同輩有著更快更多的升職機會，而且一個良好的工作習慣，無論你從事哪個行業，都是受用終生的。然后，就是認識我們的董亮老師了，一個可親可愛的老師，傳說中他們一個月會賺十幾萬呢!天文數字，望塵莫及啊。

在隨后的一段時間里，我們被分為了八組，每組六七個人，有一個組長帶領。我們組織作一個項目論壇，在第二，第三個禮拜感覺沒有剛來時那么拘謹了，我更明顯感覺到自我計劃，制定目標的重要性了。在我們犯錯誤的時候，老師會懲罰我們，陳發的方式很另類唱歌或者講笑話，不算是體罰大事可以達到對我們的約束。然而，歇息期間有組織我們做游戲，看似很簡單的游戲其實是想培養我們合作意識。

在實習的過程中，我深刻的體會到了三點：第一，項目是以迎合客戶和使用者為目的的，不可能像教師那樣為我們制定一套教學計劃。想要知道些什么，渴望懂得些什么，全要靠你自己想學，你自己不問，沒人會主動來告訴你。第二，紙上得來終覺淺，絕知此事要躬行!在短暫的實習過程中，讓我深深的感覺到自己在實際運用中的專業知識的匱乏，在行業中的經驗真的很重要。

第三，能更早的接觸你所在行業的真實情況。不出來自己轉一圈，根本不知道自己學的一些專業知識，哪些是十分重要，十分實用的。就比如說英語。以前聽老師說過，聽朋友也說過，將來工作了，英語相當有用，外企就更不用說了。當時沒什么感覺，但當我頻繁的看到一打打英文資料手冊、幫助文檔時，我已經切身地，的的確確地感受到英語的重要性。

這次實訓讓我學到的東西太多，使我受益非淺，它讓我知道了工作上的辛

苦，讓我知道工作并不像在學校里學習一樣輕松。不過，雖然辛苦了點，但能讓我學到不同的東西、很充實，我心里還是高興的。人非生而知之，要學得知識，一靠學習，二靠實踐。沒有實踐，學習就是無源之水，無本之木。以上就是我在成都的進行實訓的心得和感受。不到半年的時間就將步入社會的我們，面臨是繼續深造，還是就業的壓力，我想我們更應該把握住最后的一段時間，充實、完善自我，爭取做一名出色的大學生!對于這次實習，我很珍惜也很懷念。

軟件開發實習心得2

本人自XX年9月份參加工作至今, 六個月的實習時間已經結束。在這段時間里, 在領導和同事們的悉心關懷和指導下, 通過自己的不懈努力, 在各方面都取得了進步。

實踐讓我的技能不斷增長, 工作能力不斷加強。剛開始工作的時候, 發現自己以前在學校學習的知識很死, 知識

面很窄, 以前做的練習項目的實用性也不是很好。在開始的幾周公司給我們實習員工培訓了xxxx平臺的使用, 通過這次培訓使我認識到xxxx平臺的優勢, 可以大大提高軟件開發效率

隨后我就加入到xxxxx稅源控管系統項目的開發中, 成為開發小組中的一員。在項目開發過程中一邊是同事們的悉心指導, 一邊是自己反復琢磨與理解, 幾個月下來大大提高了自己業務和技術兩方面的技能, 已經能夠比較熟練的掌握基本的工作方法和一些技巧, 而且能夠獨立完成一些模塊的開發。

通過實踐, 我解決實際問題的能力得到了很好的鍛煉。工作中也遇到了很多的以前沒有遇到過的新技術, 面對技術難題我總是直接面對, 沒有逃避, 也因此自學了好多新的技術, 大大提高了自己的自學能力, 也加深了對自己工作要負責的信念。在項目開發過程中也遇到了一些自己確實無法解決的困難, 在經理和同事的幫助下也順利的解決了，在此表示感謝。

在開發團隊中, 加強了自己的團結精神和集體感, 對工作認真負責, 對團隊認真負責。通過這個項目不僅學習到了很多技術也了解了整個項目的大體流程, 從需求分析、數據庫設計、詳細設計、代碼編寫、測試、項目維護等方面, 使自己不僅從一個代碼編寫人員的角度還從一個整體的角度來看整個項目開發, 加深了軟件開發概念的理解。

不斷學習使我對工作有了更進一步的認識和了解。不懂就學、就問, 是一切進步取得的前提和基礎。因為有大學專業課的底子和參加過專門的java培訓使我在工作過程中遇到的技術知識能更快的理解和掌握。工作中時常遇到新的問題, 就需要查閱相關資料, 請教同事和經理, 一個問題一個問題的解決, 一個困難一個困難的克服, 不僅將原有知識溫習鞏固, 產生新的理解, 而且學到很多新知識, 有了許多新的認識。但某些認識都還是膚淺的, 還需要我在實踐當

中去不斷深入地理解。

現場開發與維護使我不僅從一個開發人員的角度而且從客戶的角度去思考問題。在項目的開發后期, 也就是項目即將上線的階段我與其他幾位同事被派往現場去開發與維護項目。以前的開發都是根據需求分析來進行, 功能要求一般在分析里面都寫的很清楚, 但是在現場開發直接面對客戶, 客戶提出的需求一開始只是一個大體的功能描述, 如何將這個只是語言描述的功能轉化為技術實現需要很強的抽象能力和對業務的深入理解, 這個過程大大鍛煉了自己的綜合能力。在第一時間接觸客戶的需求, 從客戶的角度思考問題, 只有更了解客戶需求才能更合理的設計軟件的結構, 功能。

軟件開發實習心得3

短短兩周的很快就過去了，在xx的實習馬上就要過去了。雖然只有短短的兩周，但我學會了很多知識，熟悉了軟件開發的流程，也很好的增強了自己 的動手能力。

我是一名即將大四的學生，縱觀現在的就業形勢，國家高校的擴招，世界金融危機的橫掃，大學生應該有一種居安思危的緊迫感，特別是對已經度過兩年大學的我來說，畢業并不是一個遙遠的詞匯。寶劍鋒從磨礪出，梅花香自苦寒來，缺少了平時的鍛煉，沒有厚積當然不能有薄發。首先我得有思想上的緊迫感，在學校學習的都是理論知識，實踐經驗則是少之又少。綜合能力強的人才才是這個社會需要的，成長成為社會需要的人才是我的個人奮斗目標。有了強大的精神動力，有了堅如磐石的毅力，相信成功并不遙遠。

首先，我的自我能力得到了加強。在實習的前幾天主要進行的是與JAVA有關知識的學習及預備知識的普及。在這之前由于種種原因我沒有學習過JAVA，所以對于J我幾乎一無所知。但我曾經學習過C++，所以對語言的理解和接受能力還不算太慢，盡管老師講解

速度較快但我還是盡量跟上老師的速度。在這個過程中我學會一種自學方法可以在第一遍時不求甚解，先了解知識框架，之后再在使用的過程中不斷加強對知識的理解，從而較快的學會知識并應用于實踐。

其次我的實際的操作能力得到了加強。知識講解告一段落后我們就進入了緊張而又短暫的項目中。但不得不說剛開始就碰了一鼻子灰代碼書寫總是出錯。由于對原理理解不夠透徹，語言使用缺乏足夠經驗所以進度極慢。在經過多次的討論后我們對項目理解逐漸深入，所以在此投入的過程就比較順利了。在這個過程中我明白了實踐和理論的差距及二者不可分割的關系。

最后是團隊協作能力的提高。在整個過程中團隊協作發揮著不可替代的作用。從在剛拿到項目時對項目進行分析，然后進行分工，之后就開始工作，既各干各的又不失默契的合作。在這個過程中我們誰遇到問題會互相幫助解決提高

了工作效率。由于各種原因，我們這組也存在些問題(自己編)。

這次實習拉近了我就和社會的距離，也讓自己在實踐中開拓了視野，增長了才干。社會和大學一樣也是受教育和學習的地方，在(寫實習地)的實習我收獲頗豐，再次感謝實習期間各位老師的指導教誨，你們給我的知識財富將讓我受益終生。但是我知道學無止境，僅僅這段時間的學習還是不夠的，在以后的生活中我會繼續努力學習，培養自己能力，進一步完善自己。

第五篇：大型軟件開發心得

最近做的一個項目從需求分析到上線綿延了四個月之久，這也是目前接手過功能點最繁復，產品線對接最多的一個項目。從中得到的一些關于設計較大型產品的心得，拿出來跟大家分享。

立項前

1、統一元素設計需考慮周全

也許是初創團隊的緣故，我不得不感嘆團隊對產品經理要求之嚴格之縝密，項目全程只有一個人負責，所以大到產品線對接，小到一句提示的位置和展示形式都需要一一推敲。

哪些元素應該做到統一？

a、提示方面：統一的操作成功/失敗提示；統一的彈窗形式；提示語言采用較統一的句型；為空情況的友好提醒；溢出情況的友好提醒；表單實時驗證的提醒形式等。

b、文字方面：是否有統一的段落前“·”號；統一的鏈接狀態；統一的字體、間距、行高等。

c、圖片方面：調取圖片的統一尺寸；如果是上傳圖片類的操作，需要考慮周全全站的調取情況，以及考慮是否統一預覽圖的尺寸等。

d、細節交互：未激活功能的按鈕做“灰色”處理（例如用戶沒有勾選信息時批量刪除按鈕不可使用）；按鈕點擊的狀態統一（例如增加“提交中”的按鈕狀態，以防止網速慢用戶狂點某一按鈕的情況）；特殊控件的統一等。

也許會有朋友說，上面有些是交互設計師需要做的事，但我一直認為作為一個產品經理考慮周全一些，沒壞處。這些“統一”同樣可以用在驗收階段，要知道，即使一個像素也可以改變整個產品的感覺。

2、原有功能的去留

我一直覺得升級已有產品比開發新產品難一些。這就像栽培植物一樣，新種下一棵果樹無非需要選對了土地，然后刨個坑種下去，然而成長期的去病枝、打頂等各種修剪所消耗的精力往往更多。

改進已有產品常常需要面對一個最棘手的問題：原有功能是去是留？

原功能去掉的話是不是會影響部分用戶使用？是否需要通過公告、站內信、界面引導等方式友好地告知用戶？怎樣把對用戶的傷害降至最低？

原功能留下的話是不是可以優化完善？聽到了什么用戶群怎樣的聲音？是否要在這次升級中做調整？

這些問題當接到項目的時候，產品經理就應該考慮周全了。特別需要注意的是，如果這個產品之前不是自己設計的，那么最好找到prd說明文檔細細研究一遍，對把握不準的功能點找到原負責人確認，畢竟樹苗是ta摘的，別把將來最能結果的枝干給砍了。

3、產品線上下游的對接

昨天有跟朋友聊起淘寶強勢之處，就是產品與產品緊密捏合，線上線下、跨平臺跨行業形成了一個盤根錯節、根深蒂固的根基，無可撼動。

所以把握產品線上下游和產品周邊很重要，即使一個看似簡單的新聞展示頁面修改也會牽扯到編輯后臺、廣告位管理、幫助中心，甚至是訪問統計、數據需求的變更。

這要求在產品設計開始前，需要把該產品“連根拔起”，仔細梳理相關脈絡，如果產品線夠長，一個清晰的產品線結構圖很有必要。

項目中

1、項目期間來自相關產品線調整的影響

項目期間相關產品線的調整是我最不愿意遇到的情況，這就像你在通往目的地的道路上高速行駛，就快要到達終點了，突然一個人告訴你：你走錯路了。

項目里有一個通用模塊，產品設計到一半，這個通用模塊改了；項目里有一個流程，產品做到一半，這個流程廢棄了；最要命的是已經立項開發了，你不得不硬著頭皮跟程序員說：“因為一些不可抗拒原因，這個需求咱不做了。”

對于一個耗時較長的項目來說，這種情況難以避免，事出原因私自總結有三：

a、嚴重體驗性問題：例如某個流程遭到大量用戶的不滿，為防止用戶流失，不得不做臨時調整，而倒霉的是，你也在用這個流程。

b、相關項目的影響：包括并行項目和新項目。例如你的同事在設計另一個產品，你們的產品相互牽扯較多，所以需求分析時做過很多溝通，但有一天，同事告訴你，ta的一個需求做臨時調整了會影響到你，怎么辦？

c、老板的突然決定：不舉例。

最終的解決方法不外乎三種：立即調整、延期調整、不調整。個人的處理原則一般是對a種情況進行立即調整，對b、c情況討論并選擇性延期。

為什么這么做呢？a情況是必須要改的，時間早晚問題，長痛不如短痛，b、c兩種情況必須坐下來細細討論。需了解這個需求為什么要改？是長期對策還是臨時決定？能否延期，記錄需求等下一版本再開發？如果b、c情況提出來的需求沒過兩天又有改變，那與你配合的前端和程序員也太沒有安全感了。

這個時代能耐心閱讀完XX枚漢字的人越來越少，較大型項目的產品工作心得[下]未完待續，歡迎交流……

2、需求變更

承上，需求變更是每個程序員、產品經理、設計師等都會遇到的情況。產品經理不是神，項目組也不可能是開了無敵狀態抵擋任何外界的影響。

當遇到不得不變更需求的時候，產品經理應該怎樣處理呢？下面是個人的四條建議：

a、積極處理。往往，當一個設計愈是趨于完成，人們愈是傾向于局部調整，而不是做重新設計。當一個需求因為眾所周知的原因不得不調整的時候，作為產品經理需要做的第一件事便是積極面對問題，積極處理。

項目開發往往是一個緊張的過程，每半天甚至每幾個小時就有若干個功能點開發完成，當一個需求變更傳達出現“延遲”，這個變更對項目的正常進程的“破壞力”就會更大一些。

b、保持溝通。“說話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時候，溝通是個自己掙扎的過程”這話沒錯。需求變更直接會影響到下一道工序，產品經理需要將需求變更的細節和原因傳達給相關人員，包括視覺、前端、程序、測試等。

這是很多產品經理表示非常痛苦的過程，因為可能會遭到數落和冷眼，日本有一個禮儀原則是“不要給別人添麻煩”，但是在項目中，這不可避免。

個人認為所有溝通的障礙都源于思想的不統一，如果讓大家覺得這個需求修改是在浪費時間，那么溝通上的不暢快在所難免。項目不是這樣算的，需求既然更改一定有所目的，產品經理需要將這個原因講明白，不做修改或節約溝通時間導致的返工，后果往往更嚴重。