第一篇：大型軟件開發(fā)心得

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

立項前

1、統(tǒng)一元素設計需考慮周全

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

哪些元素應該做到統(tǒng)一？

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

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

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

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

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

2、原有功能的去留

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

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

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

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

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

3、產品線上下游的對接

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

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

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

項目中

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

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

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

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

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

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

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

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

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

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

2、需求變更

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

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

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

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

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

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

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

第二篇：軟件開發(fā)心得體會

受某文化公司委托，開發(fā)一款用于視頻和圖像處理的軟件，開發(fā)難度高，高到從未搞過，開發(fā)周期長，長到是我以前項目監(jiān)控最長開發(fā)周期的兩倍，開發(fā)成本之底，讓我覺得程序員成了高級打字員。首先是需求分析書、產品規(guī)格說明書、設計說明書、代碼規(guī)范說明書、測試計劃，光文稿就不知道熬了多久才做完。

緊接著，遇到一系列問題，首先是語言選擇，vc++和c#都是可以保證開發(fā)完成的選擇，但是vc++內存容易報錯，界面很難修改，而客戶要求的界面質量甚至比程序的功能更嚴格，沒辦法，客戶就是上帝，上帝做事一定有他的道理。c#語言易于開發(fā)，而且圖形界面繪制也易于修改，可以做出客戶體驗很好的界面，但是在資源的消耗上，讓我很吃驚。做到第二個月，大概的界面已經(jīng)完成時，出現(xiàn)界面刷新的問題，刷新時開始卡，界面不流暢。沒辦法，改。

開會，總結，技術骨干找問題，拿出解決方案，力爭第一次做軟件把它做好：

重新做軟件開發(fā)進度計劃和軟件測試計劃，并且讓獨立功能demo制作和測試先行；

用direct drawww.hmlawpc.com)考慮這樣的開發(fā)人員

- 太活潑，太易興奮

太易興奮，說到投機處，“是是是是，對對對對。。。”，又蹦又跳，還時不時來點，“oh yeah, you are right“，然后還擺個 v 手型。討論問題，不易固守在技術問題本身，時常跑到“我們產品中用到的技術（或第3方產品）很強，我挺他們，不可能有問題”，又或者“我們對客戶要強勢，我們要堅持我們的產品沒問題"。

軟件開發(fā)工作本身，顯得比較沉悶，優(yōu)秀的技術人員，都略顯有些內向，因為解決問題，很多時候需要耐得住寂寞，時刻保持相對冷靜。

太活潑的人，會在遇到問題之初，表現(xiàn)出很強的沖勁，但當長時間不能解決時，會表現(xiàn)出沒有耐心，會經(jīng)常抱怨（對team、管理、產品、流程等），非常情緒化。有些女程序員還會吵，會哭，這時項目經(jīng)理只能放下手中的活，下去給她買點零食來哄哄，“莫哭，這里有你最愛吃的貓哆哩。”一邊擦著鼻涕、眼淚，一邊嘴里塞滿東西，鼓鼓啷啷“這是酸角口味的，那個西番蓮口味的才叫好吃..."

這些通常不太容易在面試時表現(xiàn)出來，在試用期時，要觀察。

第三篇：軟件開發(fā)心得總結

有感于網(wǎng)盤開發(fā)過程

有感于網(wǎng)盤開發(fā)過程 ............................ 1

一、軟件開發(fā)個人體會： ...................... 2

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

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

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

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

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

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

八、網(wǎng)盤項目開發(fā)的最大體會 ..................... 4

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

常熟理工學院sig小組3/28/201*

一、軟件開發(fā)個人體會：

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

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

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

二、做軟件開發(fā)我覺得要明白：

1. 職業(yè)的樂趣：

(a) 用自己的智慧去創(chuàng)建新事物的快樂

(b) 開發(fā)對別人有用的東西

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

2. 職業(yè)的苦惱:

(a) 總是追求完美

(b) 所有要實現(xiàn)的功能由他人而定

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

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

1.

2.

3.

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

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

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

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

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

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

把你絆倒2次。

五、怎么樣才能做好軟件開發(fā)？

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

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

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

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

(a) 從不同的系統(tǒng)場景

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

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

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

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

六、文檔的重要性

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

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

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

七、我的收獲

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

b.代碼風格要規(guī)范

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

c.心得體會:

通過做該網(wǎng)盤項目，在這2年的鍛煉中，我們才真的體會到，良好的文檔是正規(guī)研發(fā)流程中非常重要的環(huán)節(jié),一個好的程序是先寫好設計文檔再進行編程的，在設計文檔的指導下，才能寫出安全的代碼。如果你不寫文檔，一開始就寫程序，這樣你就不會按已設計好的路線走，而是想到哪寫到哪。小功能還好說，要是大功能，就容易混亂.

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

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

八、網(wǎng)盤項目開發(fā)的最大體會

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

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

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

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

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

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

第四篇：軟件開發(fā)實習心得

軟件開發(fā)實習心得

一直以來期望從事自己喜歡的事業(yè)的我，對軟件開發(fā)有者及大的興趣，可由說種種原因使我從事工作以來走了好幾年彎路，心中的夢想遲遲不能得以實現(xiàn)，可程序員的夢想從來沒有從我的心中抹去，但這扇大門好像并沒有向我敞開，今天，貴公司給了我敲開這扇大門的機會，讓我真實體驗了程序員的誕生過程。早就聽說，程序員的前幾個月是最苦的，可從來沒有感受到，海馬實習基地讓我提前感受到了剛剛進入軟件行業(yè)的壓力和困惑，再也沒有在自己家里隨便寫段小程序后的那種“自豪”感了。要面對每天必須面對的問題，再也不可能以“逃避”而了之了。也讓我感覺到做為一個程序員所應該具備的基本素質在這不到一個月的實習過程中也讓我深深體會到了作為一個合格的程序員應該具備的基本素質。

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

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

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

這一段時間的工作也讓我明白了一點：一個優(yōu)秀的程序員必須不斷的學習，隨時總結，找到自己的不足，這樣逐步提高，才能讓自己很快的成長起來。建站俠客 發(fā)表于 201*-4-28 10:19

對軟件開發(fā)的一點心得體會

一、前期規(guī)劃：

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

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

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

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

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

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

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

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

二、概要設計：

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

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

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

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

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

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

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

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

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

三、詳細設計：

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

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

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

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

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

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

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

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

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

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

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

關鍵人員給與懲罰處理。

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

四、具體編碼：

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

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

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

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

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

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

五、調試、跟蹤與測試：

1 測試需要注意的：

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

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

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

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

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

3 對于通信模塊的測試，特別注意服務端和客戶端的數(shù)據(jù)流。可以針對性的寫一個客戶端或服務端的測試程序，檢驗通訊過程是否正常。

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

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

第五篇：軟件開發(fā)核心心得

軟件開發(fā)核心心得

在一個有效的組織中，必定擁有杰出的一線人才。軟件設計也是一樣的，一線人才的素質決定了軟件的質量。從敏捷的觀點來看，代碼是檢驗軟件過程是否有效的最終標準。目前為止，以及在短時間的未來，我們都不太可能完全脫離代碼進行軟件設計。所以，軟件過程中的任何一個活動都是為了能夠產出優(yōu)秀的代碼。所以，代碼才是核心。

1. 代碼是軟件開發(fā)的基礎

編碼是軟件開發(fā)過程中最基本、最底層的技藝，然而也是最重要的技藝。任何一個領域的專家都需要花費大量的時間來進行基本技藝的鍛煉，木匠需要花費大量的時間來鍛煉他們對各種工具的掌握，廚師則需要練習刀工和火候。程序員也是一樣的，對我們來說，語言的各種特性必須要了然于胸。而對軟件的管理也需要從代碼做起。

從201*年到現(xiàn)在，國內興起了一股軟件工程熱，需求管理、配置管理、甚至cmm。面對紛至沓來的各種方法學、uml、ooa，大家似乎已經(jīng)熱衷于這些概念本身了，卻往往忽略了軟件開發(fā)中最基本的元素:代碼。在和很多軟件組織的接觸過程中，我們認為大多數(shù)組織急切需要的并不是這些工程理論，不是說這些理論不重要，而是這些組織的癥結不在于此。很多的組織連代碼的質量都管理不好，又何談其它呢？代碼管理是基礎的基礎，從管理的角度上來看，任何一個組織的管理都需要一個從上至下的管理過程，有基層的管理人員，也有高層的管理人員。對代碼的管理就是軟件開發(fā)中的基層管理，它起到的作用就是能夠把需求、設計的思路貫徹到最終的代碼中。

“管理無大事”。對軟件的管理也是一樣，大部分的問題都是由于很小的原因引起的。例如，一個產品如果后期在debug上花費了大量的時間，那么，這種現(xiàn)象是由于什么原因引起的？一種可能的原因是前期的代碼設計中對代碼質量的把握不嚴。每一次代碼功能的演化并不會產生太多的問題，但是當代碼累積越來越多的時候，問題也就慢慢出現(xiàn)了。那么如何解決呢？可以加強qa的力量，也可以引入復審，還可以引入單元測試。總之，要有一種方法對代碼進行控制。

軟件的開發(fā)過程就象是一部精密的機器，任何一個環(huán)節(jié)的變化，都會對其它的環(huán)節(jié)產生影響。把軟件過程按照瀑布的形式進行劃分是一種分解的處理思路，但同時我們還應該看到不同活動之間的相互影響。軟件開發(fā)中的生命周期模型也是一個層次模型，從業(yè)務建模一直到軟件實現(xiàn)，需要跨越數(shù)個層次，同樣會出現(xiàn)執(zhí)行不力的情況，例如，代碼設計偏離需求、偏離設計的情況比比皆是。

如何避免這種情況呢？這就需要我們從源代碼的角度，反思其上游的實踐活動，是否足

以約束代碼設計？就拿xp來說，他解決這個問題的方式是盡快的進入代碼開發(fā)階段，從代碼開發(fā)中發(fā)現(xiàn)問題，并在下一輪的開發(fā)中解決。這種思路是正確的，但xp畢竟是方法論，他不會告訴你過于細節(jié)的東西，盡管xp已經(jīng)提供了大量面向代碼的實踐。因為方法論的抽象級別比較高，使得他必須舍棄部分的細節(jié)。而這篇文章告訴你的，就是這些細節(jié)。就像我們在下一節(jié)中討論的例子，需要在代碼中加入對異常的處理，那么，異常的源頭在哪里呢？是需求，在需求中，我們發(fā)現(xiàn)了一些業(yè)務的非正常的處理序列，發(fā)現(xiàn)了一些業(yè)務實體的限制性的要求，所以在代碼實現(xiàn)中，就需要有相應的異常處理。在例如，一個優(yōu)秀的異常處理，還需要讓客戶端程序員了解可能發(fā)生的異常，以保證不同代碼間正確的集成。

2. 面向對象的代碼

面向對象的代碼已經(jīng)在現(xiàn)在的軟件開發(fā)中占據(jù)了主流的位置，面向對象的思路也有其優(yōu)勢所在，就像后文所討論的，面向對象代碼有著非面向對象代碼的很多優(yōu)勢，而軟件業(yè)中很多新的思潮的產生，也都是基于面向對象語言的，所以我們關注的代碼將是面向對象代碼。

面向對象的思想來自于抽象數(shù)據(jù)類型。對于面向對象來說，它最重要的改進就是把世間萬物都描述為對象，而類則描述了同一種對象的特征，而不是像傳統(tǒng)的開發(fā)方法那樣，按照機器指令的執(zhí)行順序來進行設計。當然，面向對象代碼最終仍然是要按照時序來執(zhí)行的，但是從程序員的角度看來，面向對象代碼更側重于對象之間的交互，多個對象各司其職，相互協(xié)作以完成目標。而面向對象技術的發(fā)展，也是朝著更加貼近我們世界觀的方向發(fā)展。從這點來看，有人說完全沒有程序設計經(jīng)驗的人學習面向對象可能會更加的容易，因為他不需要從原先的時序程序的桎梏中擺脫出來，但這未必是事實。面向對象決不是一種簡單的程序設計思路。這是我們的觀點，也會在下文中反復的論證。

和所有的職業(yè)一樣，程序員，或者是面向對象程序員，始終堅持的一點就是嚴謹。你會看到各種各樣優(yōu)秀的代碼，但那決不是一次能夠寫成的，要不斷的嘗試，不斷的改進。為什么重構和測試優(yōu)先是敏捷方法中很重要的一項實踐？因為程序員不是神，他們需要慢慢改進他們的代碼。雖然羅馬不是一天能夠建成的，但是在編寫面向對象代碼的過程中，有一些實踐是需要堅持的，它體現(xiàn)了我們所說的嚴謹。

3. 編寫并管理面向對象的代碼

編寫優(yōu)秀的面向對象代碼并不是一件容易的事情，優(yōu)秀的oo代碼如行云流水，糟糕的oo代碼讓人覺得渾身起雞皮疙瘩。編寫優(yōu)秀的oo代碼要求程序員有一定的自我修養(yǎng)，能夠以抽象的思路看待問題，找到問題的核心并對問題域進行分解。它強調的是一種解題的思路，但這個解不是唯一的。

典型的例子是設計模式，設計模式確實給了我們以很大的啟發(fā)，通過它，我們能夠了解到優(yōu)秀的代碼是如何用于解決實際問題的。但是是不是你必須在軟件中照搬設計模式呢？如果你這么做，那么你對設計模式的理解仍然不夠。我曾和在建筑行業(yè)的朋友聊起christopher alexander的建筑的永恒之道。他很興奮的告訴我，那確實是一本很好的書，能夠引發(fā)人很深的思考，但是現(xiàn)在也有另外的一種觀點，認為美仍然是無形的，應該發(fā)自建筑師的內心。對這句話我思考了很久，其實建筑是給人使用的，因此最重要的是它能都給人帶來的價值，隱含在其中的那種活生生的氣質，這是建筑師文化底蘊的外在表露。所以，christopher alexander在那本書中的目的，也是為了找到一種總結自己觀點的方法，來總結自己對人文的認識。至于現(xiàn)在大家對他的思路提出了質疑，那也是一件好事，這說明大家對建筑之道的認識到了新的高度。建筑是這樣，軟件中的模式也是一樣的，我也曾熱衷于研究模式的使用，直到某一天我猛然驚醒，與其沉迷于模式的表面形式，為什么不去研究隱藏在它背后的文化底蘊呢？武俠小說中常說無招勝有招，模式的應用也應當?shù)竭_這個境界，你如果可以在不經(jīng)意間應用模式的思想，那又何必拘泥于模式的形式呢？

編寫優(yōu)秀oo代碼雖難，但還有更難的事情，就是讓整個開發(fā)團隊都產出優(yōu)秀的oo代碼。我們剛才說了，oo對問題的解不是唯一的，但各個不同的優(yōu)秀解匯集到一起，可能就是一個糟糕的解，這是風格和架構的問題。你如何在團隊中制定制度，營造氛圍，讓優(yōu)秀oo代碼成為團隊最終的成果？這些問題，在我看來，要比cmm難得多，這個問題并不是靠花錢就能夠解決的。如果能夠解決這個問題，這個團隊的創(chuàng)造力一定是驚人的。

4. 面向對象軟件開發(fā)過程

普通的軟件開發(fā)過程和面向對象開發(fā)過程有著很大的不同�；叵胛覀冊诜敲嫦驅ο笾虚_發(fā)過程中，最經(jīng)常采用的任務分配方法就是以軟件模塊為單位，這樣的好處是分配簡單，不同任務之間耦合程度低，容易操作。壞處是幾乎無法做到重用，也缺乏整體性的設計。而面向對象軟件開發(fā)則不同，它是以類、類集合作為基本單位的。類之間關系錯綜復雜（雖然我們提倡低耦合的設計，但類之間的關系仍然是相對復雜的）。這種情況下程序員之間相互協(xié)作的要求就非常之高，這種關系如果處理恰當，則能夠完全體現(xiàn)出面向對象的威力，否則，那將會是一場大災難，面向對象的軟件開發(fā)過程要養(yǎng)成一些好的習慣：

4. 1 盡量簡化和穩(wěn)定客戶端。

個人編程可以是一種享受，但團隊開發(fā)始終是一項嚴謹?shù)穆殬I(yè)活動，因此多考慮別人，不要設計復雜的接口，雖然你省事了，但這會給理解和使用你的接口和人造成障礙。

4.2 準備一份簡潔的文檔，并保持更新。

隨便一種形式的穩(wěn)定，可以是代碼，可以是uml圖，也可以是純粹的文字（估計沒幾個程序員喜歡這種形式）。只要它能夠傳達你的代碼的目的，那就足夠。記住，更新代碼后，同時更新你的文檔。過期的文檔不僅是廢紙這么簡單，它會給其它人造成麻煩。切記！

4. 3 盡可能多的考慮異常和錯誤的情況。

寫出一個功能并沒有什么，但是要把這個功能寫的非常的完善那就很難了，因為你需要考慮各種各樣的情況，正常的、非正常的。所以，寫完一個類的定義應該是，完成編碼和穩(wěn)定，并通過原定的測試。本文摘自惠集網(wǎng)

來源：網(wǎng)絡整理 免責聲明：本文僅限學習分享，如產生版權問題，請聯(lián)系我們及時刪除。

《大型軟件開發(fā)心得(精選多篇)》由互聯(lián)網(wǎng)用戶整理提供,轉載分享請保留原作者信息,謝謝!
鏈接地址：http://www.hmlawpc.com/gongwen/285908.html

• 上一篇：雷鋒心得體會(精選多篇)
• 下一篇：領導力培訓心得體會(精選多篇)