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

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

立項前

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

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

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

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

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

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

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

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

2、原有功能的去留

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

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

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

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

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

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

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

所以把握產(chǎn)品線上下游和產(chǎn)品周邊很重要，即使一個看似簡單的新聞?wù)故卷撁嫘薷囊矔砍兜骄庉嫼笈_、廣告位管理、幫助中心，甚至是訪問統(tǒng)計、數(shù)據(jù)需求的變更。

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

項目中

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

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

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

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

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

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

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

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

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

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

2、需求變更

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

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

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

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

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

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

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

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

軟件開發(fā)心得體會

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

歲月流轉(zhuǎn)，時光匆匆，轉(zhuǎn)眼間我的大學(xué)生活已經(jīng)接近了尾聲?；厥淄?，有太多美好的，也有太多艱辛。我的大學(xué)生活的主旋律還是學(xué)習(xí)，我所選學(xué)的專業(yè)是軟件技術(shù)，在這條道路上走了那么久，也有一些小小的感悟與體會。

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

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

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

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

這樣走著走著就到了大二的下學(xué)期了，那個學(xué)期，我們有一門課是C++，這門課的老師很和藹，能力也很高，從他那里我學(xué)到了很多東西。老師教給了我們很多算法，也很系統(tǒng)的講解了語法知識，還教我們做小系統(tǒng)，有的時候他會給我門們一些小系統(tǒng)的代碼，讓我們?nèi)ジ膶懀瑒傞_始的時候我也是不會，后來經(jīng)過學(xué)習(xí)請教改寫成功了，這個時候我就會很開心，很有成就感。就這樣在學(xué)與玩中，在快樂和憂愁中我們迎來了我們的大三時光。

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

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

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

第三篇：某大型公司軟件開發(fā)管理制度

某大型公司公司軟件開發(fā)管理制度 版本：1.0 SDM審批：

QA經(jīng)理

[時間] CTO

[時間]

目 錄

1.目的和作用 3 2.適用范圍： 3 3.參考文件 3 4.適用對象 3 5.軟件開發(fā)流程 4 5.1可行性研究與計劃 4 5.1.1實施 4 5.1.2 文檔 4 5.1.2.1 應(yīng)交付的文檔 4 5.1.2.2 提交步驟 4 5.2需求分析 4 5.2.1實施 4 5.2.2要求 5 5.2.3交付文檔 5 5.2.4審批 5 5.3概要設(shè)計 5 5.3.1實施 5 5.3.2要求 6 5.3.3交付文檔 6 5.3.4補充說明 6 5.3.5審批 6 5.4詳細(xì)設(shè)計 7 5.4.1實施 7 5.4.2要求 7 5.4.3文檔 7 5.4.4審批 7 5.5實現(xiàn) 7 5.5.1實施與要求 7 5.5.2交付文檔 8 5.5.3審批 8 5.6組裝測試 8 5.6.1實施 8 5.6.2要求 8 5.6.3交付文檔 8 5.6.4審批 8 5.7確認(rèn)測試 9 5.7.1實施 9 5.7.2要求 9 5.7.3交付文檔 9 5.7.4 補充說明 9 5.7.5 審批 9 5.8發(fā)布 10 5.8.1過程 10 5.8.2 文檔 10 5.8.3 審核 10 5.9 交接 10 6.附錄1：項目文檔清單 11

1.目的和作用

本流程詳細(xì)規(guī)定軟件開發(fā)程的各個階段及每一階段的任務(wù)、要求、交付文件，使整個軟件開發(fā)過程階段清晰、要求明確、任務(wù)具體，實現(xiàn)軟件開發(fā)過程的標(biāo)準(zhǔn)化。2.適用范圍：

公司的軟件開發(fā)產(chǎn)品均適用。3.參考文件 各種文檔模板 文檔命名規(guī)則 交接流程 4.適用對象

軟件管理人員，軟件開發(fā)人員，軟件維護人員 5.軟件開發(fā)流程

5.1可行性研究與計劃 5.1.1實施

5.1.1.1 軟件開發(fā)部分析人員進(jìn)行市場調(diào)查與分析，確認(rèn)軟件的市場需求 5.1.1.2 在調(diào)查研究的基礎(chǔ)上進(jìn)行可行性研究，寫出可行性報告 5.1.1.3 評審和審批，決定項目取消或繼續(xù)

5.1.1.4 若項目可行，制訂初步的軟件開發(fā)計劃，建立項目日志 5.1.1.5 根據(jù)市場環(huán)境、公司軟硬件情況預(yù)測十大風(fēng)險因素 5.1.2 文檔

5.1.2.1 應(yīng)交付的文檔 1）可行性研究報告* 2）初步的軟件開發(fā)計劃 3）十大風(fēng)險列表* 4）軟件項目日志* 5.1.2.2 提交步驟

1)適用于以后各階段的文檔提交。

2)項目相關(guān)文檔用sourcesafe進(jìn)行版本管理，相關(guān)書寫人員可根據(jù)各文檔模板形式撰寫文檔，正式提交的文檔以存入軟件管理服務(wù)器相關(guān)目錄時間為準(zhǔn)。以后每次修改都應(yīng)注明修改內(nèi)容。

5.2需求分析 5.2.1實施

5.2.1.1 調(diào)查被開發(fā)軟件的環(huán)境

5.2.1.2 軟件開發(fā)提出的需求進(jìn)行分析并給出詳細(xì)的功能定義 5.2.1.3 做出簡單的用戶原型，與用戶共同研究，直到用戶滿意

5.2.1.4 對可利用的資源（計算機硬件、軟件、人力等）進(jìn)行估計，制定項目進(jìn)度計劃（可有相應(yīng)的緩沖時間）

5.2.1.5 制定詳細(xì)的軟件開發(fā)計劃

5.2.1.6 QA部門制訂質(zhì)量控制計劃和測試計劃 5.2.1.7 編寫初步的用戶手冊 5.2.1.8 評審 5.2.2要求

5.2.2.1 必須以運行環(huán)境為基礎(chǔ) 5.2.2.2 應(yīng)有用戶指定人員參加

5.2.2.3 需求說明書必須明確，并經(jīng)過用戶確認(rèn) 5.2.3交付文檔

1）軟件需求說明書 2）用戶手冊(概要)* 3）更新后的軟件開發(fā)計劃 4）項目進(jìn)度計劃* 5）QA計劃 6）測試計劃* 7）更新后的十大風(fēng)險列表* 8）軟件日志* 5.2.4審批

5.2.4.1 經(jīng)評審?fù)ㄟ^的各項內(nèi)容形成相應(yīng)的文檔后，提交給項目經(jīng)理審核確認(rèn) 5.2.4.2 軟件需求說明書經(jīng)項目經(jīng)理確認(rèn)后再提交給CTO進(jìn)行審核確認(rèn)。

5.3概要設(shè)計 5.3.1實施

5.3.1.1確定目標(biāo)系統(tǒng)的總體結(jié)構(gòu)

l 對于大型系統(tǒng)，可按主要的軟件需求劃分成子系統(tǒng)，然后為每個系統(tǒng)定義功能模塊及各功能模塊間的關(guān)系，并描述各子系統(tǒng)的接口界面

l 對于一般系統(tǒng)，可按軟件需求直接定義目標(biāo)系統(tǒng)的功能模塊及各功能模塊間的關(guān)系 5.3.1.2 給出每個功能模塊的功能描述，數(shù)據(jù)接口描述，外部文件及各功能模塊部的關(guān)系 5.3.1.3 設(shè)計數(shù)據(jù)庫或數(shù)據(jù)結(jié)構(gòu)

5.3.1.4 制定各階段開發(fā)的目標(biāo)（以下稱里程碑）計劃 5.3.1.5 制訂第一個里程碑的測試計劃 5.3.1.6 評審 5.3.2要求

5.3.2.1 在設(shè)計目標(biāo)系統(tǒng)的整體結(jié)構(gòu)時，應(yīng)力爭使其具有好的形態(tài)，各功能模塊間應(yīng)滿足低耦合度，而各功能模塊內(nèi)應(yīng)滿足高內(nèi)聚度。功能模塊的作用范圍應(yīng)在其控制范圍之內(nèi)。5.3.2.2 在設(shè)計目標(biāo)系統(tǒng)的總體結(jié)構(gòu)時，應(yīng)降低模塊接口的復(fù)雜性，提高目標(biāo)系統(tǒng)的可靠性 5.3.3交付文檔

1）概要設(shè)計說明書 2）數(shù)據(jù)庫/數(shù)據(jù)結(jié)構(gòu)設(shè)計說明書 3）更新后的用戶手冊* 4）更新后的項目進(jìn)度計劃* 5）更新后的十大風(fēng)險列表* 6）更新后的軟件開發(fā)計劃 7）更新后的軟件項目日志* 5.3.4補充說明

5.3.4.1 測試程序的編寫需與項目經(jīng)理協(xié)商根據(jù)開發(fā)小組和QA小組的工作量確定由QA組還是由開發(fā)組完成

5.3.4.2 每一個里程碑又可分為詳細(xì)設(shè)計、實現(xiàn)、組裝測試、確認(rèn)測試、發(fā)布、交接等階段。5.3.5審批

5.3.5.1 經(jīng)評審?fù)ㄟ^的各項內(nèi)容形成相應(yīng)的文檔后，提交給項目經(jīng)理審核確認(rèn) 5.3.5.2 數(shù)據(jù)庫/數(shù)據(jù)結(jié)構(gòu)設(shè)計說明書、概要設(shè)計說明書經(jīng)項目經(jīng)理確認(rèn)后還須提交給CTO進(jìn)行審核確認(rèn)。5.4詳細(xì)設(shè)計 5.4.1實施

5.4.1.1 將概要設(shè)計產(chǎn)生的構(gòu)成軟件系統(tǒng)的各個功能模塊逐步細(xì)化，形成若干個程序模塊（可編程模塊）

5.4.1.2 確定各程序模塊之間的詳細(xì)接口信息 5.4.1.3 撰寫擬定單元測試計劃 5.4.1.4 評審 5.4.2要求

5.4.2.1 確定程序模塊內(nèi)的數(shù)據(jù)流或控制流，對每個程序模塊必須確定所有輸入、輸出和處理功能。

5.4.2.2 規(guī)定符號的使用，確定命名規(guī)則。5.4.3文檔

1)詳細(xì)設(shè)計說明書 2)單元測試計劃* 5.4.4審批

5.4.4.1 經(jīng)評審?fù)ㄟ^的各項內(nèi)容形成相應(yīng)的文檔后，提交給項目經(jīng)理審核確認(rèn).5.4.4.2 詳細(xì)設(shè)計說明書經(jīng)項目經(jīng)理確認(rèn)后還須提交給CTO進(jìn)行審核確認(rèn)。

5.5實現(xiàn)

5.5.1實施與要求

5.5.1.1 對每個程序模塊用所選定的程序設(shè)計語言進(jìn)行編碼，寫出的程序應(yīng)該是結(jié)構(gòu)良好、清晰易讀、且與設(shè)計一致，符合公司編碼規(guī)范

5.5.1.2 單元測試：開發(fā)人員按單元測試計劃對自己編寫的程序進(jìn)行測試

5.5.1.3 編程及單元測試過程用sourcesafe進(jìn)行版本管理，主要由項目組長負(fù)責(zé) 管理。

5.5.2交付文檔 單元測試報告 5.5.3審批

所有文檔必須提交給項目經(jīng)理審核確認(rèn)。5.6組裝測試 5.6.1實施

5.6.1.1 開發(fā)組單元自測完成后，填寫測試申請單連同要測試產(chǎn)品清單交給QA 5.6.1.2 相關(guān)QA人員根據(jù)提交申請單將源程序、文檔等拷貝到測試中產(chǎn)品目錄 5.6.1.3 執(zhí)行測試計劃中所有要求的組裝測試

5.6.1.4 對測試結(jié)果進(jìn)行分析，生成當(dāng)前問題列表（BUGLIST），返回項目組長 5.6.1.5 開發(fā)人員經(jīng)過分析，修復(fù)并自測完畢，生成BUG修復(fù)報告，返回QA 5.6.1.6 完成：反復(fù)直至QA通過。5.6.2要求

5.6.2.1 組裝測試應(yīng)保證模塊間無錯誤的連接

5.6.2.2 應(yīng)對軟件系統(tǒng)或子系統(tǒng)的輸入/輸出能力進(jìn)行測試，使其達(dá)到設(shè)計要求 5.6.2.3 應(yīng)測試軟件系統(tǒng)或子系統(tǒng)正確能力和經(jīng)受錯誤的能力 5.6.3交付文檔

1）運行的軟件系統(tǒng)源程序清單 2）組裝測試計劃* 3）當(dāng)前問題列表（BUGLIST）4）BUG修復(fù)報告 5）組裝測試分析報告 5.6.4審批

所有文檔必須提交給項目經(jīng)理審核確認(rèn)。5.7確認(rèn)測試 5.7.1實施

5.7.1.1 模擬的環(huán)境中進(jìn)行強度測試，即在事先規(guī)定的一個時期內(nèi)運行軟件的所有功能，以證明該軟件無嚴(yán)重錯誤

5.7.1.2 執(zhí)行測試計劃中的所有確認(rèn)測試

5.7.1.3 使用用戶手冊，以進(jìn)一步證實其實用性和有效性，并改正其中的錯誤 5.7.1.4 對測試結(jié)果進(jìn)行分析，生成當(dāng)前問題列表（BUGLIST）5.7.1.5 反復(fù)查找BUG原因，直到修復(fù) 5.7.1.6 對所有文件進(jìn)行整理 5.7.2要求

5.7.2.1 全部系統(tǒng)存儲量、輸入及輸出通道，以及處理必須有足夠的余量 5.7.2.2 全部預(yù)期結(jié)果、測試結(jié)果及測試數(shù)據(jù)全部存檔 5.7.3交付文檔

1)確認(rèn)測試計劃 2)更新后的用戶手冊

3)更新后的項目進(jìn)度計劃* 4)更新后的十大風(fēng)險列表* 5)更新后的軟件項目日志* 6)測試產(chǎn)品清單

7)當(dāng)前問題列表（BUGLIST）8)BUG修復(fù)報告 5.7.4 補充說明

5.7.4.1 QA部門將測試清單中缺少的文檔也列入BUGLIST 5.7.4.2 對于測試中重現(xiàn)與未重現(xiàn)的BUG均要有說明 5.7.5 審批

所有文檔完成后須提交給項目經(jīng)理審核確認(rèn)。

5.8發(fā)布 5.8.1過程

5.8.1.1 經(jīng)測試合格的產(chǎn)品QA填寫發(fā)布申請表連同發(fā)布文檔一起提交給QA經(jīng)理、項目經(jīng)理、CTO 5.8.1.2 QA經(jīng)理、項目經(jīng)理、CTO審核發(fā)布申請

5.8.1.3 QA人員將發(fā)布產(chǎn)品（包括源程序、執(zhí)行文件及相關(guān)文檔）放入發(fā)布中產(chǎn)品目錄并生成安裝程序 5.8.2 文檔

1)當(dāng)前版本說明 2)發(fā)布文檔 3)用戶手冊 4)安裝手冊

5)發(fā)布產(chǎn)品檢查清單CHECKLIST 6)發(fā)布產(chǎn)品審批文檔 7)更新后的軟件日志* 5.8.3 審核

所有發(fā)布文檔須經(jīng)QA部、項目經(jīng)理、CTO審核確認(rèn)。

5.9 交接

參見交接流程。

注：帶*號文檔可根據(jù)項目大小、時間要求適當(dāng)增減

6.附錄1：項目文檔清單

文檔名稱 編寫 閱讀 審批 項目跟蹤文檔

軟件項目日志 項目經(jīng)理 CTO 十大風(fēng)險列表 項目經(jīng)理 CTO 項目進(jìn)度列表 項目經(jīng)理 CTO 當(dāng)前問題列表 測試 項目經(jīng)理，QA，開發(fā) 技術(shù)工作文檔

可行性研究報告 分析 項目經(jīng)理，開發(fā)，QA，測試，維護項目經(jīng)理，CTO 軟件需求說明書 開發(fā) 項目經(jīng)理，開發(fā)，QA，測試，維護項目經(jīng)理，CTO 用戶手冊 QA 項目經(jīng)理，QA，測試，維護，用戶項目經(jīng)理，QA經(jīng)理，CTO 概要設(shè)計說明書 開發(fā) 項目經(jīng)理，開發(fā)，QA，測試，維護項目經(jīng)理，CTO 數(shù)據(jù)庫設(shè)計說明書 開發(fā) 項目經(jīng)理，開發(fā)，QA，測試，維護 項目經(jīng)理，CTO 詳細(xì)設(shè)計說明書 開發(fā) 項目經(jīng)理，開發(fā)，QA，測試，維護項目經(jīng)理，CTO BUG修復(fù)報告 開發(fā) 項目經(jīng)理，開發(fā)，QA，測試，維護 項目經(jīng)理 測試分析報告 測試 項目經(jīng)理，開發(fā)，QA，測試，維護 項目經(jīng)理 項目計劃

軟件開發(fā)計劃 項目經(jīng)理 CTO 質(zhì)量控制計劃 QA 項目經(jīng)理，開發(fā)，QA，測試，維護 項目經(jīng)理，QA經(jīng)理 測試計劃 開發(fā)，測試 項目經(jīng)理，開發(fā)，測試，維護 項目經(jīng)理

配置管理計劃 項目經(jīng)理 項目經(jīng)理，開發(fā)，QA，測試，維護項目經(jīng)理，CTO 項目交付文檔

當(dāng)前版本說明 QA 項目經(jīng)理，QA，CTO，用戶 項目經(jīng)理，QA經(jīng)理，CTO 發(fā)布文檔 QA 項目經(jīng)理，QA，CTO，用戶 項目經(jīng)理，QA經(jīng)理，CTO 安裝手冊 QA 項目經(jīng)理，QA，CTO，維護 項目經(jīng)理，QA經(jīng)理，CTO 發(fā)布產(chǎn)品檢查清單 QA 項目經(jīng)理，QA，CTO 項目經(jīng)理，QA經(jīng)理，CTO 發(fā)布審批文檔 QA 項目經(jīng)理，QA，CTO 項目經(jīng)理，QA經(jīng)理，CTO

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

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

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

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

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

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

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

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

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

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

這次實訓(xùn)讓我學(xué)到的東西太多，使我受益非淺，它讓我知道了工作上的辛

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

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

本人自XX年9月份參加工作至今, 六個月的實習(xí)時間已經(jīng)結(jié)束。在這段時間里, 在領(lǐng)導(dǎo)和同事們的悉心關(guān)懷和指導(dǎo)下, 通過自己的不懈努力, 在各方面都取得了進(jìn)步。

實踐讓我的技能不斷增長, 工作能力不斷加強。剛開始工作的時候, 發(fā)現(xiàn)自己以前在學(xué)校學(xué)習(xí)的知識很死, 知識

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

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

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

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

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

中去不斷深入地理解。

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

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

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

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

首先，我的自我能力得到了加強。在實習(xí)的前幾天主要進(jìn)行的是與JAVA有關(guān)知識的學(xué)習(xí)及預(yù)備知識的普及。在這之前由于種種原因我沒有學(xué)習(xí)過JAVA，所以對于J我?guī)缀跻粺o所知。但我曾經(jīng)學(xué)習(xí)過C++，所以對語言的理解和接受能力還不算太慢，盡管老師講解

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.面向?qū)ο蟮拇a

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3 盡可能多的考慮異常和錯誤的情況。

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