軟件開發(fā)專業(yè)實(shí)習(xí)心得

1、軟件開發(fā)專業(yè)實(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ì)在

2、這不到一個(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ì)精神和良好的

3、協(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ò) 誤讓我們花了很大的工夫去改代碼，改頁面。很慶幸的是，這是一個(gè) 小項(xiàng)目，要是大項(xiàng)目，這種問題可能就會(huì)導(dǎo)致大量的代碼修改，可見 文檔在一個(gè)項(xiàng)目中起者巨大的做用。此外，良好的代碼編寫習(xí)慣，不但有助于代碼的移植和糾錯(cuò)，也 有助于不同技術(shù)人員之間的協(xié)作。 作為一個(gè)程序員， 對(duì)需求的理解能 力也是很重要的， 只有真正理解了一個(gè)模塊的

4、作用， 才會(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é)，找到自己的不足，這樣逐步提高，才能讓自己 很快的成長起來。建站俠客 發(fā)表于 2008-4-28 10:19對(duì)軟件開發(fā)的一點(diǎn)

5、心得體會(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)真， 不夠完

6、善，將產(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)部的交流， 更多需

7、要協(xié)調(diào)好團(tuán)隊(duì)之間的交流。 可 能有時(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)分析員和核心開

8、發(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ā)小組組 長（程序經(jīng)理 ）。2 各開發(fā)組長書寫各自模塊的詳細(xì)設(shè)計(jì)文檔， 開發(fā)成員需要協(xié) 助，配合。3 在指定提交日，開發(fā)組長提交文檔給系統(tǒng)分析員。由系統(tǒng)分 析員審批。4 系統(tǒng)分析員組織召開一個(gè)詳細(xì)設(shè)計(jì)文檔確認(rèn)

9、的會(huì)議。5 然后開發(fā)組長分發(fā)各自模塊的詳細(xì)設(shè)計(jì)文檔給程序員， 程序 員在指定時(shí)間內(nèi)完成。6 程序員做內(nèi)部測(cè)試。開發(fā)組長協(xié)調(diào)并配合。7 確認(rèn)無 bug 提交給開發(fā)組組長8 所有模塊整合工作，由整個(gè)開發(fā)組成員參與完成。由所有開 發(fā)組長和系統(tǒng)分析員負(fù)責(zé)主要部分工作。程序員協(xié)助和配合。9 對(duì)整合后工程做詳細(xì)測(cè)試。10 確認(rèn)測(cè)試通過后，開發(fā)組長根據(jù)開發(fā)成員表現(xiàn)以及提交成 果填寫績效考核表。然后提交給項(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è)簡單的開發(fā)流程， 一定是

10、有很多不足的地方。 希望能起到拋磚引玉的作用。大家都明白，流程和制度是死的，但人 是活的，所以如何按流程做得好，關(guān)鍵還是在人本身了。沒有一個(gè)流 程和制度，一個(gè)團(tuán)隊(duì)也必將是一盤散沙。 正所謂“無規(guī)矩?zé)o以成方圓” 。 這句話說得很有道理。四、具體編碼：開發(fā)幾個(gè)項(xiàng)目之后，對(duì)編寫程序有了更進(jìn)一步的了解好的程序應(yīng)該具有 : 易讀性，易擴(kuò)展性，容錯(cuò)性。易讀性 : 所有變量和函數(shù)以及類名用簡單易懂易記憶的命名方 式。所有類和函數(shù)甚至變量都有關(guān)鍵的注釋說明。這點(diǎn)很重要，也是 最基礎(chǔ)的。如果代碼書寫不夠美觀和易懂， 我想自己以后也不想再看。 就更別談功能的擴(kuò)展和新版本開發(fā)了。易擴(kuò)展性 : 整體系統(tǒng)架構(gòu)邏輯簡單清

11、晰。模塊與模塊之間盡量做 到互不影響， 也就是盡可能的獨(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è)試， 特