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

最近做的一個(gè)項(xiàng)目從需求分析到上線綿延了四個(gè)月之久，這也是目前接手過功能點(diǎn)最繁復(fù)，產(chǎn)品線對(duì)接最多的一個(gè)項(xiàng)目。從中得到的一些關(guān)于設(shè)計(jì)較大型產(chǎn)品的心得，拿出來跟大家分享。

立項(xiàng)前

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

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

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

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

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

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

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

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

2、原有功能的去留

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

改進(jìn)已有產(chǎn)品常常需要面對(duì)一個(gè)最棘手的問題：原有功能是去是留？

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

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

這些問題當(dāng)接到項(xiàng)目的時(shí)候，產(chǎn)品經(jīng)理就應(yīng)該考慮周全了。特別需要注意的是，如果這個(gè)產(chǎn)品之前不是自己設(shè)計(jì)的，那么最好找到prd說明文檔細(xì)細(xì)研究一遍，對(duì)把握不準(zhǔn)的功能點(diǎn)找到原負(fù)責(zé)人確認(rèn)，畢竟樹苗是ta摘的，別把將來最能結(jié)果的枝干給砍了。

3、產(chǎn)品線上下游的對(duì)接

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

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

這要求在產(chǎn)品設(shè)計(jì)開始前，需要把該產(chǎn)品“連根拔起”，仔細(xì)梳理相關(guān)脈絡(luò)，如果產(chǎn)品線夠長(zhǎng)，一個(gè)清晰的產(chǎn)品線結(jié)構(gòu)圖很有必要。

項(xiàng)目中

1、項(xiàng)目期間來自相關(guān)產(chǎn)品線調(diào)整的影響

項(xiàng)目期間相關(guān)產(chǎn)品線的調(diào)整是我最不愿意遇到的情況，這就像你在通往目的地的道路上高速行駛，就快要到達(dá)終點(diǎn)了，突然一個(gè)人告訴你：你走錯(cuò)路了。

項(xiàng)目里有一個(gè)通用模塊，產(chǎn)品設(shè)計(jì)到一半，這個(gè)通用模塊改了；項(xiàng)目里有一個(gè)流程，產(chǎn)品做到一半，這個(gè)流程廢棄了；最要命的是已經(jīng)立項(xiàng)開發(fā)了，你不得不硬著頭皮跟程序員說：“因?yàn)橐恍┎豢煽咕茉�因，這個(gè)需求咱不做了。”

對(duì)于一個(gè)耗時(shí)較長(zhǎng)的項(xiàng)目來說，這種情況難以避免，事出原因私自總結(jié)有三：

a、嚴(yán)重體驗(yàn)性問題：例如某個(gè)流程遭到大量用戶的不滿，為防止用戶流失，不得不做臨時(shí)調(diào)整，而倒霉的是，你也在用這個(gè)流程。

b、相關(guān)項(xiàng)目的影響：包括并行項(xiàng)目和新項(xiàng)目。例如你的同事在設(shè)計(jì)另一個(gè)產(chǎn)品，你們的產(chǎn)品相互牽扯較多，所以需求分析時(shí)做過很多溝通，但有一天，同事告訴你，ta的一個(gè)需求做臨時(shí)調(diào)整了會(huì)影響到你，怎么辦？

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

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

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

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

2、需求變更

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

當(dāng)遇到不得不變更需求的時(shí)候，產(chǎn)品經(jīng)理應(yīng)該怎樣處理呢？下面是個(gè)人的四條建議：

a、積極處理。往往，當(dāng)一個(gè)設(shè)計(jì)愈是趨于完成，人們愈是傾向于局部調(diào)整，而不是做重新設(shè)計(jì)。當(dāng)一個(gè)需求因?yàn)楸娝�周知的原因不得不調(diào)整的時(shí)候，作為產(chǎn)品經(jīng)理需要做的第一件事便是積極面對(duì)問題，積極處理。

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

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

這是很多產(chǎn)品經(jīng)理表示非常痛苦的過程，因?yàn)榭赡軙?huì)遭到數(shù)落和冷眼，日本有一個(gè)禮儀原則是“不要給別人添麻煩”，但是在項(xiàng)目中，這不可避免。

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

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

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

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

開會(huì)，總結(jié)，技術(shù)骨干找問題，拿出解決方案，力爭(zhēng)第一次做軟件把它做好：

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

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

- 太活潑，太易興奮

太易興奮，說到投機(jī)處，“是是是是，對(duì)對(duì)對(duì)對(duì)。。。”，又蹦又跳，還時(shí)不時(shí)來點(diǎn)，“oh yeah, you are right“，然后還擺個(gè) v 手型。討論問題，不易固守在技術(shù)問題本身，時(shí)常跑到“我們產(chǎn)品中用到的技術(shù)（或第3方產(chǎn)品）很強(qiáng)，我挺他們，不可能有問題”，又或者“我們對(duì)客戶要強(qiáng)勢(shì)，我們要堅(jiān)持我們的產(chǎn)品沒問題"。

軟件開發(fā)工作本身，顯得比較沉悶，優(yōu)秀的技術(shù)人員，都略顯有些內(nèi)向，因?yàn)榻鉀Q問題，很多時(shí)候需要耐得住寂寞，時(shí)刻保持相對(duì)冷靜。

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

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

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

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

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

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

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

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

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

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

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

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

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

九、軟件測(cè)試（單體測(cè)試和連接測(cè)試） .................... 4

常熟理工學(xué)院sig小組3/28/201*

一、軟件開發(fā)個(gè)人體會(huì)：

1. 軟件領(lǐng)域中的知識(shí)在于積累。

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

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

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

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

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

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

(c) 不斷學(xué)習(xí)來充實(shí)自己

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

(a) 總是追求完美

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

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

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

1.

2.

3.

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

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

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

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

1. 程序員怎么樣進(jìn)步最快？ － 理論結(jié)合實(shí)踐

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

把你絆倒2次。

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

1. 首先要明白解決的問題是什么，理解問題，其次再?zèng)Q定怎么解決這個(gè)問題

2. 碰到很復(fù)雜的問題，我們就簡(jiǎn)單想，把問題簡(jiǎn)單化，細(xì)化到能夠?qū)崿F(xiàn)為止

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

4. 我們應(yīng)該從2個(gè)方面去把握一個(gè)項(xiàng)目：從業(yè)務(wù)角度和項(xiàng)目的關(guān)鍵問題上去把握一個(gè)項(xiàng)目

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

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

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

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

解了項(xiàng)目的業(yè)務(wù)需求，我們才能做真的做好這個(gè)項(xiàng)目

六、文檔的重要性

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

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

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

七、我的收獲

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

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

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

c.心得體會(huì):

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

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

最忙的時(shí)候就是我們成長(zhǎng)和收獲最多的時(shí)候。

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

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

九、軟件測(cè)試（單體測(cè)試和連接測(cè)試）

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

測(cè)試，說的直接點(diǎn)就是給軟件找錯(cuò)誤。

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

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

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

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

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

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

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

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

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

對(duì)軟件開發(fā)的一點(diǎn)心得體會(huì)

一、前期規(guī)劃：

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

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

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

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

對(duì)于第一種，當(dāng)然是因?yàn)榍捌谝?guī)劃疏漏了某些細(xì)小功能，沒能把需求文檔做完善。應(yīng)該是規(guī)劃工作做的還不夠認(rèn)真和細(xì)致。

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

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

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

二、概要設(shè)計(jì)：

我理解的概要設(shè)計(jì)步驟：（以項(xiàng)目為中心的開發(fā)流程）

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

2〉項(xiàng)目經(jīng)理召集項(xiàng)目開發(fā)成員，開項(xiàng)目啟動(dòng)會(huì)議。具體商議項(xiàng)目的開發(fā)任務(wù)和責(zé)任分配。

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

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

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

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

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

8〉開始詳細(xì)設(shè)計(jì)文檔的工作

三、詳細(xì)設(shè)計(jì)：

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

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

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

4〉系統(tǒng)分析員組織召開一個(gè)詳細(xì)設(shè)計(jì)文檔確認(rèn)的會(huì)議。

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

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

7〉確認(rèn)無bug提交給開發(fā)組組長(zhǎng)。

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

9〉對(duì)整合后工程做詳細(xì)測(cè)試。

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

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

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

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

四、具體編碼：

開發(fā)幾個(gè)項(xiàng)目之后，對(duì)編寫程序有了更進(jìn)一步的了解。

好的程序應(yīng)該具有: 易讀性，易擴(kuò)展性，容錯(cuò)性。

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

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

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

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

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

1 測(cè)試需要注意的：

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

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

確認(rèn)單個(gè)模塊完全正常后，再加入工程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 面向?qū)ο蟮拇�碼

面向?qū)ο蟮拇�碼已經(jīng)在現(xiàn)在的軟件開發(fā)中占據(jù)了主流的位置，面向?qū)ο蟮乃悸芬灿衅鋬?yōu)勢(shì)所在，就像后文所討論的，面向?qū)ο蟠�碼有著非面向?qū)ο蟠�碼的很多優(yōu)勢(shì)，而軟件業(yè)中很多新的思潮的產(chǎn)生，也都是基于面向?qū)ο笳Z(yǔ)言的，所以我們關(guān)注的代碼將是面向?qū)ο蟠�碼。

面向?qū)ο蟮乃枷雭碜杂诔橄髷?shù)據(jù)類型。對(duì)于面向?qū)ο髞碚f，它最重要的改進(jìn)就是把世間萬物都描述為對(duì)象，而類則描述了同一種對(duì)象的特征，而不是像傳統(tǒng)的開發(fā)方法那樣，按照機(jī)器指令的執(zhí)行順序來進(jìn)行設(shè)計(jì)。當(dāng)然，面向?qū)ο蟠�碼最終仍然是要按照時(shí)序來執(zhí)行的，但是從程序員的角度看來，面向?qū)ο蟠�碼更側(cè)重于對(duì)象之間的交互，多個(gè)對(duì)象各司其職，相互協(xié)作以完成目標(biāo)。而面向?qū)ο蠹夹g(shù)的發(fā)展，也是朝著更加貼近我們世界觀的方向發(fā)展。從這點(diǎn)來看，有人說完全沒有程序設(shè)計(jì)經(jīng)驗(yàn)的人學(xué)習(xí)面向?qū)ο罂赡軙?huì)更加的容易，因?yàn)樗�不需要從原先的時(shí)序程序的桎梏中擺脫出來，但這未必是事實(shí)。面向?qū)ο鬀Q不是一種簡(jiǎn)單的程序設(shè)計(jì)思路。這是我們的觀點(diǎn)，也會(huì)在下文中反復(fù)的論證。

和所有的職業(yè)一樣，程序員，或者是面向?qū)ο蟪绦騿T，始終堅(jiān)持的一點(diǎn)就是嚴(yán)謹(jǐn)。你會(huì)看到各種各樣優(yōu)秀的代碼，但那決不是一次能夠?qū)懗傻�，要不斷的嘗試，不斷的改進(jìn)。為什么重構(gòu)和測(cè)試優(yōu)先是敏捷方法中很重要的一項(xiàng)實(shí)踐？因?yàn)槌绦騿T不是神，他們需要慢慢改進(jìn)他們的代碼。雖然羅馬不是一天能夠建成的，但是在編寫面向?qū)ο蟠�碼的過程中，有一些實(shí)踐是需要堅(jiān)持的，它體現(xiàn)了我們所說的嚴(yán)謹(jǐn)。

3. 編寫并管理面向?qū)ο蟮拇�碼

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

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

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

4. 面向?qū)ο筌浖�開發(fā)過程

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

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

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

4.2 準(zhǔn)備一份簡(jiǎn)潔的文檔，并保持更新。

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

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

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

來源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問題，請(qǐng)聯(lián)系我們及時(shí)刪除。

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

• 上一篇：雷鋒心得體會(huì)(精選多篇)
• 下一篇：領(lǐng)導(dǎo)力培訓(xùn)心得體會(huì)(精選多篇)