軟件工程的心得體會(huì)范文

1、PAGE PAGE 16 軟件工程的心得體會(huì)范文篇一：軟件工程心得體會(huì)讀軟件工程案例教程有感對(duì)于學(xué)習(xí)軟件工程這門(mén)課程，我認(rèn)為有許多東西要學(xué)習(xí)。其實(shí)在我看來(lái)學(xué)習(xí)這門(mén)課程的精髓是學(xué)習(xí)一種方法。是一個(gè)如何去分析和處理問(wèn)題的過(guò)程，應(yīng)該說(shuō)其范疇已經(jīng)遠(yuǎn)遠(yuǎn)不止局限于該門(mén)課程，成為了一個(gè)綜合的一個(gè)能夠解決問(wèn)題的思想集合。讀完軟件工程案例教程這本書(shū)，我覺(jué)得自己受益匪淺。整本書(shū)的內(nèi)容邏輯很清晰明了，由淺入深循序漸進(jìn)，首先我就大概描述下我們所學(xué)的內(nèi)容，第一章是從整體分析軟件工程這門(mén)學(xué)科的發(fā)展和所處的社會(huì)環(huán)境，接著后面的幾章深入分析了軟件開(kāi)放過(guò)程和模式、軟件項(xiàng)目管理、計(jì)算機(jī)工程、需求分析、結(jié)構(gòu)化分析建模以及基于UML

2、面向?qū)ο蠓治鼋：蜏y(cè)試等。 對(duì)于這本書(shū)我主要對(duì)需求分析和測(cè)試比較感興趣，在這我要著重的談一些自己的心得體會(huì)以及自己的看法。一需求分析1.1需求分析的重要性一款成功的軟件是建立在成功的需求分析之上的，而高質(zhì)量的需求來(lái)源于用戶與開(kāi)發(fā)人員之間有效的溝通與合作。當(dāng)用戶有一個(gè)問(wèn)題可以用計(jì)算機(jī)系統(tǒng)來(lái)解決，而開(kāi)發(fā)人員開(kāi)始幫助用戶解決這個(gè)問(wèn)題，溝通就開(kāi)始了。由此我們可以看出需求分析的重要性。需求獲取可能是最困難、最關(guān)鍵、最易出錯(cuò)及最需要溝通交流的活動(dòng)。對(duì)需求的獲取往往有錯(cuò)誤的認(rèn)識(shí)：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問(wèn)用戶系統(tǒng)的目標(biāo)特征，什么是要完成的，什么樣的系統(tǒng)能適合商業(yè)

3、需要就可以了，但是實(shí)際上需求獲取并不是想象的這樣簡(jiǎn)單，這條溝通之路布滿了荊棘。首先需求獲取要定義問(wèn)題范圍，系統(tǒng)的邊界往往是很難明確的，用戶不了解技術(shù)實(shí)現(xiàn)的細(xì)節(jié)，這樣造成了系統(tǒng)目標(biāo)的混淆。其次是對(duì)問(wèn)題的理解，用戶對(duì)計(jì)算機(jī)系統(tǒng)的能力和限制缺乏了解，任何一個(gè)系統(tǒng)都會(huì)有很多的用戶或者不同類(lèi)型的用戶，每個(gè)用戶只知道自己需要的系統(tǒng)，而不知道系統(tǒng)的整體情況，他們不知道系統(tǒng)作為一個(gè)整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說(shuō)如何以一種精確的方式來(lái)描述需求，他們需要開(kāi)發(fā)人員的協(xié)助和指導(dǎo)，但是用戶與開(kāi)發(fā)人員之間的交流很容易出現(xiàn)障礙，忽略了那些被認(rèn)為是很明顯的信息。最后是

4、需求的確認(rèn)，因?yàn)樾枨蟮牟环€(wěn)定性往往隨著時(shí)間的推移產(chǎn)生變動(dòng)，使之難以確認(rèn)。為了克服以上的問(wèn)題，必須有組織的執(zhí)行需求的獲取活動(dòng)。1.2需求分析的原則（1）需求分析必須能夠表達(dá)和理解問(wèn)題的數(shù)據(jù)域和功能域。數(shù)據(jù)域包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)，而功能域反映上述 3 方面的控制信息。（2）需求分析要把一個(gè)復(fù)雜問(wèn)題按功能進(jìn)行分解并逐層細(xì)化。通常，軟件系統(tǒng)要處理的問(wèn)題如果太大、太復(fù)雜就很難理解，若劃分成幾部分，并確定各部分間的接口，就可完成整體的功能。在需求分析過(guò)程中，軟件系統(tǒng)的用戶需求中的數(shù)據(jù)、功能和行為都應(yīng)細(xì)化。（3）需求建模。模型可以幫助系統(tǒng)分析人員更好地理解軟件系統(tǒng)的數(shù)據(jù)、功能和行為，這些模型是軟件

5、工程中下一階段進(jìn)行系統(tǒng)設(shè)計(jì)的基礎(chǔ)。1.3需求分析的注意事項(xiàng)（1）確定詳細(xì)的需求，否則經(jīng)費(fèi)就算不準(zhǔn)。經(jīng)費(fèi)估計(jì)錯(cuò)誤的原因多為：用戶需求頻繁變動(dòng)、遺漏重要需求、與用戶交流不夠、需求規(guī)格說(shuō)明書(shū)質(zhì)量低劣、需求分析不充分等。（2）在編寫(xiě)需求規(guī)格說(shuō)明書(shū)之前，應(yīng)明確要解決的問(wèn)題。在試圖解決問(wèn)題之前，要保證已考察了全部可替代的方案。要搞清哪地方有問(wèn)題，真正的問(wèn)題出在哪里。這樣，在編寫(xiě)需求規(guī)格說(shuō)明書(shū)時(shí)做到有的放矢，把存在的問(wèn)題暴露出來(lái)。（3）立即確定需求，并記錄下該需求的背景。沒(méi)有明確問(wèn)題，就進(jìn)行下一步的設(shè)計(jì)，想回避矛盾，可能會(huì)帶來(lái)更大的問(wèn)題。用戶不確定需求，軟件設(shè)計(jì)人員自己決定需求，將會(huì)帶來(lái)嚴(yán)重的問(wèn)題。為了避免

6、將來(lái)可能出現(xiàn)的問(wèn)題和軟件工程項(xiàng)目能夠盡快地進(jìn)入到下一個(gè)階段的系統(tǒng)設(shè)計(jì)中，要盡可能迅速地把用戶需求確定下來(lái)。任何決定總比沒(méi)有決定要好。（4）一旦在需求規(guī)格說(shuō)明書(shū)中發(fā)現(xiàn)問(wèn)題，立即改正。如果把存在的問(wèn)題拖延到系統(tǒng)設(shè)計(jì)階段去改正，就可能要花數(shù)倍的時(shí)間和精力才能糾正同一錯(cuò)誤。（5）在眾多用戶需求中確定各個(gè)需求的優(yōu)先順序，并確定可能存在的子集，以便為軟件設(shè)計(jì)、實(shí)施和項(xiàng)目管理等后續(xù)階段提供有利條件。（6）需求分析時(shí)，不要進(jìn)行系統(tǒng)設(shè)計(jì)的工作。需求分析的主要目的是確定軟件系統(tǒng)的外部特征，充分反映軟件系統(tǒng)應(yīng)有的面貌，便于讓軟件設(shè)計(jì)人員根據(jù)用戶需求，去全面地考慮軟件系統(tǒng)的體系結(jié)構(gòu)、算法等。在需求分析階段要集中精力解

7、決用戶需求存在的問(wèn)題，盡可能避免產(chǎn)生遺留問(wèn)題。（7）對(duì)于復(fù)雜的軟件系統(tǒng)，要從多種視角進(jìn)行需求分析。根據(jù)軟件系統(tǒng)的本質(zhì)，切合實(shí)際地組織多種視角的需求。例如，可從根據(jù)用戶的類(lèi)型，或根據(jù)響應(yīng)的類(lèi)型，或根據(jù)對(duì)象的軟件工程案例教程類(lèi)型，或根據(jù)系統(tǒng)的模式等視角來(lái)組織用戶需求。通過(guò)多個(gè)視角來(lái)研究用戶需求問(wèn)題，把可得到的不同的“投影”組合起來(lái)形成完整系統(tǒng)的描述。當(dāng)試圖從整體觀點(diǎn)來(lái)描述軟件系統(tǒng)發(fā)生困難，或者有可能發(fā)生錯(cuò)誤，或者很有可能遺失軟件系統(tǒng)的某些特性。而從不同的視角來(lái) 描述軟件系統(tǒng)，因?yàn)槊總€(gè)視角限制了研究的范圍并能夠?qū)⒆⒁饬杏诖?，所以很容易保證所研究的問(wèn)題是真正完整的。（8）重視形式化方法，但不放棄自

8、然語(yǔ)言。為了用戶需求表達(dá)的精確性和方便用戶的可理解性，一個(gè)好方法是把自然語(yǔ)言的表達(dá)與形式化規(guī)格說(shuō)明并立，互相對(duì)照，而且在一般情況下，先用自然語(yǔ)言寫(xiě)出，再給出它的形式模型。（9）用戶需求中不應(yīng)存在“待確定”的條款。如若有這種需要，應(yīng)同時(shí)說(shuō)明：何時(shí)由誰(shuí)來(lái)解決該問(wèn)題。1.4用戶需求的類(lèi)型需求分析是從用戶最初的非形式化需求到滿足用戶要求的軟件產(chǎn)品的映射過(guò)程。它實(shí)際上是一個(gè)對(duì)用戶意圖不斷進(jìn)行揭示和判斷的過(guò)程，其目的在于細(xì)化、精化軟件的作用范圍，確定擬開(kāi)發(fā)軟件的功能和性能、約束、環(huán)境等?？蓪⒂脩舻男枨蠓譃閮纱箢?lèi)：功能性需求和非功能性需求。（1）功能性需求。功能性需求主要說(shuō)明了系統(tǒng)各功能部件與環(huán)境之間的相互

9、作用的本質(zhì)，即擬開(kāi)發(fā)軟件在職能上實(shí)際應(yīng)做到什么。一般來(lái)說(shuō)，它是用戶最主要的需求，通常包括系統(tǒng)的輸入、系統(tǒng)能完成的功能、系統(tǒng)的輸出以及其他反應(yīng)。在功能性需求中還應(yīng)包括備選功能的定義識(shí)別。（2）非功能性需求。非功能性要求主要從各個(gè)角度對(duì)所考慮的可能的解決方案起約束和限制作用。1.5需求分析的方法在軟件工程中，常用的需求分析方法有面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（簡(jiǎn)稱(chēng) SA）和面向?qū)ο蟮姆治龇椒ǎê?jiǎn)稱(chēng) OOA）。此外，還有以用戶為中心的需求分析方法。這些方法都采用圖文結(jié)合的方式，可以直觀地描述軟件的邏輯模型。這里僅介紹結(jié)構(gòu)化分析方法和以用戶為中心的需求分析方法。2.軟件測(cè)試2.1軟件測(cè)試概述軟件本身無(wú)形態(tài)

10、，它是復(fù)雜的知識(shí)高度密集的邏輯產(chǎn)品，其中不可能沒(méi)有錯(cuò)誤。軟件實(shí)施工程過(guò)程中必須伴隨著軟件質(zhì)量保證的活動(dòng)，而軟件測(cè)試是主要活動(dòng)之一。在開(kāi)發(fā)軟件的過(guò)程中，人們使用了許多保證軟件質(zhì)量的方法分析、設(shè)計(jì)和實(shí)現(xiàn)軟件，但難免還會(huì)在工作中犯錯(cuò)誤。這樣，在軟件產(chǎn)品中就會(huì)隱藏許多錯(cuò)誤和缺陷。對(duì)于規(guī)模大、復(fù)雜性高的軟件更是如此。在這些錯(cuò)誤中，有些是致命的錯(cuò)誤，如果不排除，就會(huì)導(dǎo)致生命與財(cái)產(chǎn)的重大損失。2.2軟件測(cè)試的目的測(cè)試的目的是“說(shuō)明程序能正確地執(zhí)行應(yīng)有的功能”，還是“表明程序沒(méi)有錯(cuò)誤”？基于不同的立場(chǎng)，存在著兩種完全不同的測(cè)試目的。從用戶的角度出發(fā)，普遍希望通過(guò)軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可

11、以接受該產(chǎn)品。而從軟件開(kāi)發(fā)者的角度出發(fā)，則希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過(guò)程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對(duì)軟件質(zhì)量的信心。因此，他們會(huì)選擇那些導(dǎo)致程效概率小的測(cè)試用例，回避那些易于暴露程序錯(cuò)誤的測(cè)試用例。同時(shí)，也不會(huì)刻意去檢測(cè)、排除程序中可能包含的副作用。顯然，這樣的測(cè)試對(duì)完善和提高軟件質(zhì)量毫無(wú)價(jià)值。因?yàn)樵诔绦蛑型嬖谥S多預(yù)料不到的問(wèn)題，可能會(huì)被疏漏，許多隱藏的錯(cuò)誤只有在特定的環(huán)境下才可能暴露出來(lái)。如果不把著眼點(diǎn)放在盡可能查找錯(cuò)誤這樣一個(gè)基礎(chǔ)上，這些隱藏的錯(cuò)誤和缺陷就查不出來(lái)，會(huì)遺留到運(yùn)行階段中去。如果站在用戶的角度，替他們?cè)O(shè)想，就應(yīng)當(dāng)把測(cè)試活動(dòng)的目標(biāo)對(duì)準(zhǔn)揭露程序

12、中存在的錯(cuò)誤。在選取測(cè)試用例時(shí)，考慮那些易于發(fā)現(xiàn)程序錯(cuò)誤的數(shù)據(jù)。2.3軟件測(cè)試的原則（1）應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件開(kāi)發(fā)者的座右銘。由于原始問(wèn)題的復(fù)雜性、軟件的復(fù)雜性和抽象性、軟件開(kāi)發(fā)各個(gè)階段工作的多樣性，以及參加開(kāi)發(fā)各種層次人員之間工作的配合關(guān)系等因素，使得開(kāi)發(fā)的每個(gè)環(huán)節(jié)都可能產(chǎn)生錯(cuò)誤。所以不應(yīng)把軟件測(cè)試僅僅看成是軟件開(kāi)發(fā)的一個(gè)獨(dú)立階段，而應(yīng)當(dāng)把它貫穿到軟件開(kāi)發(fā)的各個(gè)階段中。在需求分析階段就應(yīng)該制訂測(cè)試計(jì)劃，以保證每個(gè)需求，每個(gè)設(shè)計(jì)單元都是可測(cè)試的，便于測(cè)試。堅(jiān)持在軟件開(kāi)發(fā)的各個(gè)階段的技術(shù)評(píng)審，這樣才能在開(kāi)發(fā)過(guò)程中盡早發(fā)現(xiàn)和預(yù)防錯(cuò)誤，把出現(xiàn)的錯(cuò)誤克服在早期，杜絕某些隱患，提

13、高軟件質(zhì)量。（2）測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)和與之對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。測(cè)試以前應(yīng)當(dāng)根據(jù)測(cè)試的要求，選擇在測(cè)試過(guò)程中使用的測(cè)試用例（Test Case）。測(cè)試用例主要用來(lái)檢驗(yàn)程序員編制的程序，因此不但需要測(cè)試的輸入數(shù)據(jù)，而且需要針對(duì)這些輸入數(shù)據(jù)的預(yù)期輸出結(jié)果。如果對(duì)測(cè)試輸入數(shù)據(jù)沒(méi)有給出預(yù)期的程序輸出結(jié)果，那么就缺少了檢驗(yàn)實(shí)測(cè)結(jié)果的基準(zhǔn)，就有可能把一個(gè)似是而非的錯(cuò)誤結(jié)果當(dāng)成正確結(jié)果。（3）程序員應(yīng)避免檢查自己的程序。測(cè)試工作需要嚴(yán)格的作風(fēng)、客觀的態(tài)度和冷靜的情緒。自己測(cè)試自己的軟件不容易發(fā)現(xiàn)錯(cuò)誤，程序員應(yīng)避免測(cè)試自己的程序。測(cè)試是一種“挑剔性”的行為，人們常常由于各種原因具有一種不愿否定

14、自己工作的心理，認(rèn)為揭露自己程序中的問(wèn)題總不是一件愉快的事，這一心理狀態(tài)就成為測(cè)試自己程序的障礙。心理狀態(tài)和思維定式是測(cè)試自己程序的兩大障礙，應(yīng)由別人或另外的機(jī)構(gòu)來(lái)測(cè)試程序員編寫(xiě)的程序。另外，程序員對(duì)軟件規(guī)格說(shuō)明理解錯(cuò)誤而引入的錯(cuò)誤則更難發(fā)現(xiàn)。如果由別人來(lái)測(cè)試程序員編寫(xiě)的程序，可能會(huì)更客觀、更有效，并更容易取得成功。要注意的是，這點(diǎn)不能與程序的調(diào)試（Debugging）互相混淆，調(diào)試由程序員自己來(lái)做可能更有效。（4）在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗(yàn)證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問(wèn)題變異的輸入條件。在測(cè)試程序

15、時(shí)，人們常常傾向于過(guò)多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應(yīng)該做的事情，而忽視了不合法的和預(yù)想不到的輸入條件。事實(shí)上，軟件在投入運(yùn)行以后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶軟件工程案例教程 在鍵盤(pán)上按錯(cuò)了鍵或打入了非法的命令。如果開(kāi)發(fā)的軟件遇到這種情況時(shí)不能做出適當(dāng)?shù)姆磻?yīng)，給出相應(yīng)的信息，那么就容易產(chǎn)生故障，輕則給出錯(cuò)誤的結(jié)果，重則導(dǎo)致軟件失效。因此，軟件系統(tǒng)處理非法命令的能力也必須在測(cè)試時(shí)受到檢驗(yàn)。用不合理的輸件測(cè)試程序時(shí)，往往比用合理的輸入條件進(jìn)行測(cè)試能發(fā)現(xiàn)更多篇二：軟件開(kāi)發(fā)心得總結(jié)有感于網(wǎng)盤(pán)開(kāi)發(fā)過(guò)程有感于網(wǎng)盤(pán)開(kāi)發(fā)過(guò)程 1一、軟件開(kāi)發(fā)個(gè)人體會(huì)： 2二

16、、做軟件開(kāi)發(fā)我覺(jué)得要明白： 2三、在開(kāi)發(fā)中遇到問(wèn)題應(yīng)該怎么去解決？ 2四、怎么樣才能提高自身的能力？ 2五、怎么樣才能做好軟件開(kāi)發(fā)？ 2六、文檔的重要性 3七、我的收獲 3八、網(wǎng)盤(pán)項(xiàng)目開(kāi)發(fā)的最大體會(huì) 4九、軟件測(cè)試（單體測(cè)試和連接測(cè)試） 4一、軟件開(kāi)發(fā)個(gè)人體會(huì)：1. 軟件領(lǐng)域中的知識(shí)在于積累。2. 做軟件開(kāi)發(fā)，就類(lèi)似算數(shù)學(xué)題和世界杯足球賽一樣：重在結(jié)果，而不在乎過(guò)程。3. 軟件服務(wù)于人類(lèi)，軟件是在解決一些生活中的問(wèn)題和錯(cuò)誤，問(wèn)題決定解決方案。二、做軟件開(kāi)發(fā)我覺(jué)得要明白：1. 職業(yè)的樂(lè)趣：(A) 用自己的智慧去創(chuàng)建新事物的快樂(lè)(B) 開(kāi)發(fā)對(duì)別人有用的東西(C) 不斷學(xué)習(xí)來(lái)充實(shí)自己2. 職業(yè)的苦惱

17、:(A) 總是追求完美(B) 所有要實(shí)現(xiàn)的功能由他人而定(C) 概念設(shè)計(jì)計(jì)是有趣的，但找Bug總是很苦惱的三、在開(kāi)發(fā)中遇到問(wèn)題應(yīng)該怎么去解決？1.2.3.4. 不明白就多問(wèn)，不要自已一直去琢磨。 一個(gè)問(wèn)題如果30分鐘還沒(méi)有解決就應(yīng)該考慮是不是問(wèn)問(wèn)別人。 一個(gè)問(wèn)題在沒(méi)有用過(guò)3種以上的方法解決過(guò)就不要去問(wèn)別人。 解決問(wèn)題思路是關(guān)鍵：相信問(wèn)題總歸有解決的辦法，就算連技術(shù)上都沒(méi)法實(shí)現(xiàn)的問(wèn)題，相信通過(guò)良好的溝通終究也會(huì)有解決的方法。5. 解決問(wèn)題的前提是：理解別人的意思，理解別人的需求，多溝通，及時(shí)給客戶反饋信息。四、怎么樣才能提高自身的能力？1. 程序員怎么樣進(jìn)步最快？ 理論結(jié)合實(shí)踐2. 不要怕出錯(cuò)，

18、不怕遇到錯(cuò)誤，有錯(cuò)誤就有挑戰(zhàn)，這樣才可以進(jìn)步，但不要讓同一個(gè)石頭把你絆倒2次。五、怎么樣才能做好軟件開(kāi)發(fā)？1. 首先要明白解決的問(wèn)題是什么，理解問(wèn)題，其次再?zèng)Q定怎么解決這個(gè)問(wèn)題2. 碰到很復(fù)雜的問(wèn)題，我們就簡(jiǎn)單想，把問(wèn)題簡(jiǎn)單化，細(xì)化到能夠?qū)崿F(xiàn)為止3. 出了問(wèn)題，我們要先分析問(wèn)題，然后知道引起問(wèn)題的原因，最后并想出問(wèn)題的解決辦法4. 我們應(yīng)該從2個(gè)方面去把握一個(gè)項(xiàng)目：從業(yè)務(wù)角度和項(xiàng)目的關(guān)鍵問(wèn)題上去把握一個(gè)項(xiàng)目(A) 從不同的系統(tǒng)場(chǎng)景(B) 從不同的用戶角色（充當(dāng)什么角色）(C) 從不同的系統(tǒng)使用角度（擁有那些權(quán)限）5. 其實(shí)我覺(jué)得開(kāi)發(fā)人員說(shuō)實(shí)在應(yīng)該要比使用系統(tǒng)的人更了解系統(tǒng)需求，只有真正徹底的了

19、解了項(xiàng)目的業(yè)務(wù)需求，我們才能做真的做好這個(gè)項(xiàng)目六、文檔的重要性記得我當(dāng)初剛開(kāi)發(fā)項(xiàng)目的時(shí)候都是寫(xiě)個(gè)大致的需求說(shuō)明書(shū)，做一個(gè)E-R圖，畫(huà)幾個(gè)大致的數(shù)據(jù)流程圖，然后建立數(shù)據(jù)字典和表結(jié)構(gòu)關(guān)系。 再接著搭建一個(gè)開(kāi)發(fā)環(huán)境，配置幾臺(tái)服務(wù)器，劃分一下模塊，分工，我們就可以Coding了，一直到項(xiàng)目結(jié)束了，也沒(méi)有完整的設(shè)計(jì)文檔，更沒(méi)有完整的測(cè)試文檔，雖然這樣的確是很快的完成了Coding工作，感覺(jué)上好像節(jié)省了好多成本和開(kāi)發(fā)時(shí)間，但后期的維護(hù)和Bug 就是經(jīng)常出現(xiàn)的事。小項(xiàng)目沒(méi)有文檔關(guān)系不大，但如果遇到一個(gè)大項(xiàng)目的時(shí)候，那這樣的開(kāi)發(fā)方式就很有問(wèn)題很危險(xiǎn)的。大項(xiàng)目沒(méi)有文檔： 首先維護(hù)就很麻煩，也很亂，寫(xiě)的代碼，過(guò)幾

20、天都不知道它是完成什么功能的了，其次系統(tǒng)的穩(wěn)定性和可靠性也讓人懷疑，擴(kuò)展性就不用說(shuō)了。七、我的收獲A.程序員大多都不喜歡寫(xiě)文檔,我們以前也是特討厭,記得以前都是系統(tǒng)開(kāi)發(fā)完了，為了應(yīng)付項(xiàng)目驗(yàn)收，就匆匆忙忙的一組人在那里補(bǔ)文檔。在我們的思想里,所謂的文檔就是一些廢話,一句話硬是用十句話來(lái)代替的無(wú)聊透頂。B.代碼風(fēng)格要規(guī)范以前做項(xiàng)目，我們都是不怎么去注意代碼風(fēng)格和寫(xiě)代碼的規(guī)范，都是稍微想一下就直接開(kāi)始寫(xiě)代碼了。注釋也很少用，總感覺(jué)我們自己寫(xiě)的代碼，我們?cè)趺磿?huì)不知道它做了些什么事呢 ？總覺(jué)得我們自己寫(xiě)的代碼我們?cè)趺磿?huì)不知道它是用來(lái)做什么的呢。一直都不相信這是個(gè)事實(shí)，但事實(shí)上，項(xiàng)目驗(yàn)收后，系統(tǒng)剛開(kāi)始使用的人少，也就不會(huì)出現(xiàn)潛在的錯(cuò)誤，隨著時(shí)間的增加，久而久之，當(dāng)大量用戶并發(fā)訪問(wèn)的時(shí)候，系統(tǒng)的Bug 就暴漏出來(lái)了，那時(shí)你再用熟悉的Eclipse打開(kāi)整個(gè)項(xiàng)目的源碼時(shí)，再去看自己寫(xiě)的代碼的時(shí)候，真的發(fā)現(xiàn)，我們定義的這個(gè)變量名是什么意思啊 ？ 我們的這個(gè)Flag 是用來(lái)判斷什么的啊 ？我們的if（）中條件不知道是判斷什么？ Function （） 也忘記是什么功能了？ 想想好可怕啊。 難道真的都忘記了嗎 ？回答是肯定的： 真的忘了。C.心得體會(huì):通過(guò)做該網(wǎng)盤(pán)項(xiàng)