本篇文章給大家談?wù)勡浖_(kāi)發(fā)過(guò)程中面臨的問(wèn)題，以及軟件開(kāi)發(fā)過(guò)程中面臨的問(wèn)題及對(duì)策對(duì)應(yīng)的知識(shí)點(diǎn)，希望對(duì)各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、IT培訓(xùn)分享軟件開(kāi)發(fā)項(xiàng)目中會(huì)遇到的問(wèn)題
• 2、軟件開(kāi)發(fā)過(guò)程中的常見(jiàn)問(wèn)題有哪些？
• 3、軟件開(kāi)發(fā)過(guò)程中會(huì)遇到哪些問(wèn)題
• 4、關(guān)于軟件開(kāi)發(fā)會(huì)遇到什么問(wèn)題及對(duì)策

IT培訓(xùn)分享軟件開(kāi)發(fā)項(xiàng)目中會(huì)遇到的問(wèn)題

軟件開(kāi)發(fā)項(xiàng)目中會(huì)遇到哪些問(wèn)題呢?參加軟件學(xué)習(xí)不得不了解在以后工作中會(huì)出現(xiàn)的狀況，IT培訓(xùn)為你提前解析。

1)新手。任何項(xiàng)目組成員都不可避免地出現(xiàn)新手，他們往往是剛剛從大學(xué)畢業(yè)的學(xué)生。這些新手由于軟件開(kāi)發(fā)時(shí)間太短，往往技術(shù)不成熟，沒(méi)有形成良好的開(kāi)發(fā)習(xí)慣，所以編寫(xiě)代碼質(zhì)量較差，問(wèn)題很多。他們常常成為項(xiàng)目組的“雞肋”，用多了項(xiàng)目質(zhì)量無(wú)法得到保證，不用則又人手不夠。當(dāng)然北大青鳥(niǎo)校區(qū)的學(xué)子畢業(yè)就已經(jīng)有一年多的工作經(jīng)驗(yàn)，已經(jīng)是熟手了。

2)人員變動(dòng)。一個(gè)維護(hù)時(shí)間稍長(zhǎng)一點(diǎn)兒的軟件項(xiàng)目，人員變動(dòng)是在所難免的。老員工被調(diào)動(dòng)到其它項(xiàng)目去了，由新員工來(lái)接替他們的工作。北大青鳥(niǎo)校區(qū)軟件講師在一次軟件培訓(xùn)課堂上就說(shuō)到，在我的項(xiàng)目組中，人員調(diào)動(dòng)達(dá)到了90%，沒(méi)有調(diào)走的就是我自己。新員工在接替老員工進(jìn)行代碼維護(hù)，甚至繼續(xù)進(jìn)行新的開(kāi)發(fā)的時(shí)，由于對(duì)原有代碼以及設(shè)計(jì)思路理解的偏差，也會(huì)出現(xiàn)大量的低劣代碼。

3)不規(guī)范的代碼編寫(xiě)。即使除去以上兩個(gè)問(wèn)題的影響，項(xiàng)目組成員編寫(xiě)的代碼同樣會(huì)出現(xiàn)問(wèn)題。在項(xiàng)目開(kāi)發(fā)之初，我們往往會(huì)制定一個(gè)代碼編寫(xiě)的規(guī)范，但在項(xiàng)目開(kāi)發(fā)過(guò)程中，許多成員往往會(huì)忽視這些代碼規(guī)范而進(jìn)行隨意的編寫(xiě)。隨意地代碼編寫(xiě)會(huì)降低代碼的可讀性、可維護(hù)性和易變更性。那么，我們應(yīng)當(dāng)采用什么樣的管理措施，保證代碼的規(guī)范，提高代碼的質(zhì)量呢?

軟件開(kāi)發(fā)過(guò)程中的常見(jiàn)問(wèn)題有哪些？

1.前言應(yīng)用軟件系統(tǒng)是事件驅(qū)動(dòng)的軟件系統(tǒng)，系統(tǒng)通過(guò)接口接受事件后，交由系統(tǒng)業(yè)務(wù)層處理，業(yè)務(wù)層處理完事件后將需要的信息存入數(shù)據(jù)庫(kù)，整個(gè)應(yīng)用軟件系統(tǒng)分為三個(gè)子系統(tǒng)：接口子系統(tǒng)，業(yè)務(wù)子系統(tǒng)，數(shù)據(jù)庫(kù)子系統(tǒng)，業(yè)務(wù)子系統(tǒng)進(jìn)一步分為三個(gè)子系統(tǒng)：表示層，業(yè)務(wù)層，數(shù)據(jù)接入層。其中業(yè)務(wù)層是整個(gè)系統(tǒng)的核心，表示層負(fù)責(zé)通過(guò)接口子系統(tǒng)接收系統(tǒng)事件交給業(yè)務(wù)層處理，數(shù)據(jù)接入層供業(yè)務(wù)層使用完成數(shù)據(jù)的持久化。每個(gè)層對(duì)編程人員的技術(shù)要求是不同的，表示層需要了解的技術(shù)根據(jù)接口子系統(tǒng)選擇的不同而不同：如windows界面，需要對(duì)MFC有比較深入的了解，web界面則要求對(duì)asp，asp.net，或jsp有比較深入的了解。數(shù)據(jù)訪問(wèn)層需要的技術(shù)則由數(shù)據(jù)庫(kù)子系統(tǒng)的選擇決定，另外還需要了解：ODBC，JDBC等。接口子系統(tǒng)的選擇：windows界面，java界面，web界面，命令行接口，CTI， API等 數(shù)據(jù)庫(kù)子系統(tǒng)的選擇：關(guān)系數(shù)據(jù)庫(kù)，普通文件等基于以上對(duì)應(yīng)用軟件系統(tǒng)的理解，軟件開(kāi)發(fā)流程的輸入是用戶的業(yè)務(wù)需求，輸出就是系統(tǒng)的業(yè)務(wù)層、表示層、數(shù)據(jù)接入層的代碼，以及接口和數(shù)據(jù)庫(kù),以及各種文檔。因此得到比較理想化的軟件開(kāi)發(fā)流程圖，該圖使用uml中的活動(dòng)圖描述。2.需求分析階段需求分析階段的常見(jiàn)問(wèn)題是：需求分析不夠深入，對(duì)問(wèn)題域沒(méi)有仔細(xì)研究，急于進(jìn)入設(shè)計(jì)階段。造成這種問(wèn)題一方面是因?yàn)轫?xiàng)目管目趕進(jìn)度以及存在于管理人員頭腦中的根深蒂固的想法：任何時(shí)候不能讓任何人員閑著，另外很大的原因是很多人不知道如何進(jìn)一步深入研究問(wèn)題域。需求分析階段不僅要列出系統(tǒng)的use case，更重要的是要列出use case的輸入輸出和例外情況等，以及問(wèn)題域中的對(duì)象之間的靜態(tài)關(guān)系和動(dòng)態(tài)關(guān)系，如對(duì)象間的包含關(guān)系，繼承關(guān)系，調(diào)用關(guān)系等。需求分析階段另外一個(gè)常見(jiàn)的問(wèn)題是常常將需求分析等同于數(shù)據(jù)庫(kù)設(shè)計(jì)，需求分析階段定義的是系統(tǒng)作什么，而不是怎么做，需求分析的結(jié)果應(yīng)該與具體的技術(shù)實(shí)現(xiàn)無(wú)關(guān)。數(shù)據(jù)庫(kù)設(shè)計(jì)是技術(shù)實(shí)現(xiàn)的細(xì)節(jié)，應(yīng)該盡可能的推遲技術(shù)細(xì)節(jié)的決策，不應(yīng)該使技術(shù)細(xì)節(jié)束縛了我們對(duì)系統(tǒng)需求的理解。需求分析階段應(yīng)該從用戶的角度對(duì)系統(tǒng)建模，不應(yīng)將大量的技術(shù)細(xì)節(jié)暴露給用戶，導(dǎo)致系統(tǒng)易用性差。需求分析階段可以進(jìn)一步細(xì)分為業(yè)務(wù)需求分析階段和系統(tǒng)功能需求分析階段。在很多研發(fā)性質(zhì)的系統(tǒng)中，不注重業(yè)務(wù)需求分析，只有系統(tǒng)功能需求分析，導(dǎo)致開(kāi)發(fā)人員知其然不知其所以然。系統(tǒng)功能規(guī)范文檔與業(yè)務(wù)需求文檔的重要區(qū)別有以下幾點(diǎn)：內(nèi)容不同：系統(tǒng)需求分為功能需求和非功能需求，功能需求進(jìn)一步分為業(yè)務(wù)功能需求和非業(yè)務(wù)功能需求。系統(tǒng)需求規(guī)范文檔除了包括業(yè)務(wù)需求文檔中的業(yè)務(wù)功能需求，功能規(guī)范文檔需要增加以下內(nèi)容：系統(tǒng)的非業(yè)務(wù)功能需求，由于業(yè)務(wù)需求由計(jì)算機(jī)系統(tǒng)實(shí)現(xiàn)而產(chǎn)生的功能需求，如系統(tǒng)需要系統(tǒng)管理員管理，系統(tǒng)管理員的角度產(chǎn)生一些非業(yè)務(wù)功能需求，另外需要描述系統(tǒng)非功能需求：數(shù)據(jù)量，性能要求，響應(yīng)速度，可用性要求，可靠性要求，界面語(yǔ)言要求等等。 閱讀的對(duì)象不同：業(yè)務(wù)需求文檔是用來(lái)與業(yè)務(wù)人員交流，功能規(guī)范文檔是開(kāi)發(fā)人員開(kāi)發(fā)的依據(jù) 使用的語(yǔ)言不同：業(yè)務(wù)需求文檔使用自然語(yǔ)言書(shū)寫(xiě)，而功能規(guī)范文檔使用比較嚴(yán)謹(jǐn)?shù)恼Z(yǔ)言，如：uml書(shū)寫(xiě) 對(duì)編寫(xiě)人的要求不一樣：業(yè)務(wù)需求編寫(xiě)人員只需要對(duì)業(yè)務(wù)系統(tǒng)熟悉，系統(tǒng)規(guī)范由系統(tǒng)架構(gòu)師完成 體現(xiàn)系統(tǒng)架構(gòu)師價(jià)值的地方是編寫(xiě)系統(tǒng)規(guī)范文檔和業(yè)務(wù)層設(shè)計(jì), 系統(tǒng)規(guī)范文檔是下一步界面設(shè)計(jì)，業(yè)務(wù)層設(shè)計(jì)和數(shù)據(jù)庫(kù)設(shè)計(jì)的依據(jù)，表示層，業(yè)務(wù)層，數(shù)據(jù)訪問(wèn)層之間是相互聯(lián)系的，它們之間的關(guān)系應(yīng)該在系統(tǒng)規(guī)范文檔中找到。3.架構(gòu)設(shè)計(jì)階段架構(gòu)設(shè)計(jì)階段的常見(jiàn)問(wèn)題是將架構(gòu)設(shè)計(jì)理解為技術(shù)架構(gòu)設(shè)計(jì)，實(shí)際上架構(gòu)設(shè)計(jì)分為技術(shù)架構(gòu)設(shè)計(jì)和業(yè)務(wù)架構(gòu)設(shè)計(jì)。技術(shù)架構(gòu)一般由系統(tǒng)軟件商提供，可以在不同的應(yīng)用軟件系統(tǒng)中使用，例如：微軟的MFC， SUN的J2EE等。對(duì)于一個(gè)應(yīng)用軟件系統(tǒng)，更重要的是業(yè)務(wù)架構(gòu)的設(shè)計(jì)，也就是將需求分析階段中得到的各種關(guān)系，根據(jù)系統(tǒng)的非功能需求將需求分析轉(zhuǎn)變?yōu)榇a。其實(shí)沒(méi)有業(yè)務(wù)架構(gòu)的設(shè)計(jì)也是可以的，很多項(xiàng)目中直接將對(duì)象之間的各種關(guān)系以數(shù)據(jù)庫(kù)的方式實(shí)現(xiàn)，這樣的系統(tǒng)不是面向?qū)ο蟮模虼嗣嫦驅(qū)ο笤O(shè)計(jì)的很多好處不能體現(xiàn)。由于在架構(gòu)設(shè)計(jì)階段中沒(méi)有進(jìn)一步細(xì)分，通常會(huì)導(dǎo)致不能準(zhǔn)確估計(jì)任務(wù)量，造成項(xiàng)目計(jì)劃變成擺設(shè)。4.詳細(xì)設(shè)計(jì)階段詳細(xì)設(shè)計(jì)階段一個(gè)重要的任務(wù)是系統(tǒng)持久化設(shè)計(jì)。對(duì)應(yīng)用系統(tǒng)而言，持久化設(shè)計(jì)只是管理存儲(chǔ)的機(jī)制，有多種技術(shù)手段可以選擇：可以是面向?qū)ο髷?shù)據(jù)庫(kù)管理系統(tǒng)，簡(jiǎn)單的文件，或者是關(guān)系數(shù)據(jù)庫(kù)，也可以是使用ORM工具等。總之應(yīng)該把它留到最后作為細(xì)節(jié)處理。我們不應(yīng)該將我們的系統(tǒng)和任何特定的技術(shù)綁定在一起。我們可以根據(jù)需求自由選擇需要的持久化技術(shù)，并且保留在將來(lái)需要時(shí)更改持久化技術(shù)的自由。5.編碼階段編碼階段還處于小農(nóng)經(jīng)濟(jì)，自給自足，沒(méi)有分工合作。編碼階段以u(píng)se case為粒度安排工作，這樣的安排方式要求每一個(gè)開(kāi)發(fā)人員必須對(duì)表示層，業(yè)務(wù)層，數(shù)據(jù)接入層的所有技術(shù)都要有比較深入的了解，由于每個(gè)開(kāi)發(fā)人員各自只對(duì)自己的use case負(fù)責(zé)，對(duì)別人的use case不了解，但是每一個(gè)use case會(huì)有功能重復(fù)的地方，導(dǎo)致大量的重復(fù)工作。編碼階段工作安排的粒度應(yīng)該是類，編碼階段工作的安排原則是先分層，再分割，按照表示層，業(yè)務(wù)層，數(shù)據(jù)訪問(wèn)層分開(kāi)后，每一層內(nèi)可以進(jìn)一步分為不同類，使用測(cè)試驅(qū)動(dòng)的編程方法，每個(gè)編程人員單獨(dú)編寫(xiě)代碼，并進(jìn)行單元測(cè)試。每個(gè)層次的編程人員只需要對(duì)某一種技術(shù)有比較深入的了解。6.測(cè)試階段很多人分不清什么是單元測(cè)試，什么是集成測(cè)試，什么是系統(tǒng)測(cè)試？測(cè)試的順序是先單元測(cè)試，然后是集成測(cè)試，最后是系統(tǒng)測(cè)試。單元測(cè)試是源代碼級(jí)的測(cè)試，一般由編程人員自己使用各種unit工具測(cè)試，是白盒測(cè)試。集成測(cè)試是在單元測(cè)試結(jié)束后，將一個(gè)或若干個(gè)單元作為一個(gè)子系統(tǒng)的黑盒測(cè)試，測(cè)試子系統(tǒng)內(nèi)的所有組件可以正確的交互，集成測(cè)試通過(guò)對(duì)子系統(tǒng)不斷增加新的單元最后完成整個(gè)系統(tǒng)的測(cè)試，集成測(cè)試不應(yīng)由開(kāi)發(fā)人員完成。7.結(jié)束軟件開(kāi)發(fā)過(guò)程中，各種輔助工具以及process很重要，但是使用工具和process的最終目的是為了更高效的在開(kāi)發(fā)人員之間溝通交流，記錄存在開(kāi)發(fā)人員腦子里的想法，不要為了process而process。不能以為會(huì)使用MS word，就認(rèn)為可以成為作家。最后引用Robert Martin的《敏捷軟件開(kāi)發(fā)：原則、模式與實(shí)踐》中的一句話作為本文的結(jié)束：過(guò)渡信賴工具和過(guò)程以及低估智力和經(jīng)驗(yàn)都是軟件開(kāi)發(fā)災(zāi)難的源泉。 注： 本文摘自網(wǎng)絡(luò) 臺(tái)州極速網(wǎng)絡(luò)有限公司愿以雄厚的技術(shù)實(shí)力基礎(chǔ)

軟件開(kāi)發(fā)過(guò)程中會(huì)遇到哪些問(wèn)題

手機(jī)app開(kāi)發(fā)過(guò)程中所遇到的9大注意事項(xiàng)：

一、沒(méi)有規(guī)劃的開(kāi)始

很多App項(xiàng)目在開(kāi)發(fā)之前，都沒(méi)有規(guī)劃好，這就比如，寫(xiě)作文沒(méi)有大綱，做房子沒(méi)有建筑圖，到最后做出來(lái)的app和客戶需要的效果大相庭徑。所以在開(kāi)始 之前就要做好一份書(shū)面規(guī)劃，包括app開(kāi)發(fā)的目的、需要實(shí)現(xiàn)的功能，以及預(yù)期每個(gè)階段需要完善哪些功能等等，然后根據(jù)規(guī)劃，設(shè)計(jì)出用戶需求的流程圖。

二、盲目的創(chuàng)建跨平臺(tái)app

跨平臺(tái)app在一定程度上，能從用戶的實(shí)際使用中獲得反饋，有利于改善在其他平臺(tái)發(fā)布的版本。然而跨平臺(tái)app一般情況下沒(méi)有全面的功能，對(duì)于多個(gè)獨(dú) 立的平臺(tái)來(lái)說(shuō)，則需要更多的編碼。所以在設(shè)計(jì)app之前，要展開(kāi)用戶調(diào)查，包括不同的年齡、生活方式、教育環(huán)境等等，再判斷使用安卓和ios的比例，確定 好開(kāi)發(fā)平臺(tái)。

三、不重視開(kāi)發(fā)人員建議

通常產(chǎn)品設(shè)計(jì)師在得到一些靈感的時(shí)候，就會(huì)在產(chǎn)品中加入一些其他元素，然而站在開(kāi)發(fā)者的角度去考慮問(wèn)題，有時(shí)候會(huì)覺(jué)得加進(jìn)來(lái)的這個(gè)東西比較多余，而且 和移動(dòng)設(shè)備的操作體驗(yàn)也不匹配，或者這些元素會(huì)產(chǎn)生一些不必要的數(shù)據(jù)。藍(lán)海匯app開(kāi)發(fā)技術(shù)人員介紹：這時(shí)如果產(chǎn)品設(shè)計(jì)師一意孤行的話，很可能會(huì)導(dǎo)致產(chǎn)品 變殘，或者因此而讓用戶在使用過(guò)程中產(chǎn)生了多余的數(shù)據(jù)，而放棄此應(yīng)用。所以比較好的辦法就是，在技術(shù)可行，并不影響用戶體驗(yàn)的情況下，可以實(shí)施這種想法。

四、將app設(shè)計(jì)成網(wǎng)站模式

用戶愿意用你的App，主要原因有兩種，一是有用;二是精簡(jiǎn)、快速，兩者缺一不可。如果將app設(shè)置成網(wǎng)站形式，不僅打開(kāi)緩慢，容易閃退，花了大量時(shí)間還找不到想要的重點(diǎn)在哪里。另外，如果用戶想要打開(kāi)網(wǎng)頁(yè)版，他們還會(huì)用手機(jī)嗎，只有在特別需要的情況下才會(huì)使用吧。

五、手機(jī)屏幕尺寸不兼容

其實(shí)這種情況很常見(jiàn)，同一個(gè)app在不同手機(jī)上排版不同、格式不同，比如說(shuō)在某些小屏幕的手機(jī)上，看到的內(nèi)容就比較凌亂，給人非常不專業(yè)的感覺(jué)。所以開(kāi)發(fā)者需要注意手機(jī)屏幕尺寸的兼容性。

六、觸發(fā)后臺(tái)程序

使用app時(shí)，移動(dòng)設(shè)備上也會(huì)運(yùn)行其他后臺(tái)服務(wù)，過(guò)多的系統(tǒng)需求會(huì)導(dǎo)致設(shè)備崩潰，這是常見(jiàn)的大忌。

七、忽視操作系統(tǒng)集成

Android和iOS風(fēng)格、布局和導(dǎo)航都大不相同，這需要匹配創(chuàng)建項(xiàng)目的每一個(gè)操作系統(tǒng)來(lái)滿足用戶。同時(shí)，對(duì)蘋(píng)果app而言，它需要專為操作系統(tǒng)而設(shè)計(jì)的應(yīng)用。

八、節(jié)省測(cè)試

一個(gè)人的思維引導(dǎo)他做的事情，是一個(gè)自然過(guò)程，所以開(kāi)發(fā)者或設(shè)計(jì)程序人員對(duì)自己開(kāi)發(fā)的或者設(shè)計(jì)的產(chǎn)品是沒(méi)法公正判斷的，因?yàn)樗麄冮_(kāi)發(fā)出來(lái)的產(chǎn)品正是他 們了解到的樣子。那么就不能由開(kāi)發(fā)者或設(shè)計(jì)程序人員自己來(lái)測(cè)試。作為測(cè)試人群，他們應(yīng)該是目標(biāo)用戶，或者是沒(méi)有參與開(kāi)發(fā)的人員，但最好不要是家人，因?yàn)楸?較不客觀。

九、迷失最終目的

在規(guī)劃好app開(kāi)發(fā)項(xiàng)目流程以后，不要輕易改變，如果在開(kāi)發(fā)過(guò)程中，不斷加入新的需求，就會(huì)逐漸遠(yuǎn)離最初的開(kāi)發(fā)目的，這是不能讓客戶滿意的。那么在有新的 需求或者想法時(shí)，要及時(shí)在產(chǎn)品開(kāi)發(fā)前，與客戶開(kāi)會(huì)討論并確認(rèn)，盡量確保開(kāi)發(fā)出來(lái)的產(chǎn)品與最初規(guī)劃的樣子相符合。

關(guān)于軟件開(kāi)發(fā)會(huì)遇到什么問(wèn)題及對(duì)策

調(diào)研：當(dāng)確定做之后，我們就要與客戶交流，進(jìn)行需求分析，但由于客戶表達(dá)不清、需求自身經(jīng)常變動(dòng)或分析人員理解有誤，都會(huì)導(dǎo)致需求分析困難。所以，前期的調(diào)研及 開(kāi)發(fā)過(guò)程中的及時(shí)溝通及匯報(bào)時(shí)很有必要的；但這是可能就會(huì)遇到一些問(wèn)題，比如：前期我是想這樣實(shí)現(xiàn)的，但我又想以另一種形式實(shí)現(xiàn)，這時(shí)。就會(huì)涉及到已經(jīng)開(kāi) 發(fā)完成的模塊進(jìn)行修改，造成工作量的增大，所以，要注意的是，提前考慮好或需要變動(dòng)要及時(shí)與工程師溝通，看是否可以進(jìn)行修改，若沒(méi)問(wèn)題則工程師修改，若工 程量很大，甚至涉及到整個(gè)架構(gòu)了，則盡量不修改以其他形式實(shí)現(xiàn)。偉創(chuàng)軟件在開(kāi)發(fā)過(guò)程中經(jīng)常遇到這樣的問(wèn)題，所以建議大家多溝通。

2

開(kāi)發(fā)過(guò)程中：每個(gè)工程師都希望能再前期就能將功能梳理完畢，但是這種事情基本是不可能的，在開(kāi)發(fā)過(guò)程中會(huì)出現(xiàn)這樣那樣的變動(dòng)，偉創(chuàng)OA就經(jīng)常出現(xiàn)這樣的情況，但這并不是不可控的，只要軟件還沒(méi)有開(kāi)發(fā)完成，與工程師協(xié)商是沒(méi)有問(wèn)題的，若是已經(jīng)開(kāi)發(fā)完了，要改動(dòng)，就有可能會(huì)涉及整個(gè)底層架構(gòu)，加大周期及工作量。

3

測(cè)試：測(cè)試的目的在于發(fā)現(xiàn)盡可能多的錯(cuò)誤，而不是為了說(shuō)明程序中沒(méi)有錯(cuò)誤。公司內(nèi)部人員進(jìn)行的測(cè)試，就是已知各模塊的結(jié)構(gòu)進(jìn)行單步調(diào)試，主要是看模塊接口是否正確，輸出結(jié)果是否正確，請(qǐng)用戶過(guò)來(lái)試用，發(fā)現(xiàn)在試用中出現(xiàn)的一些問(wèn)題，提交測(cè)試報(bào)告。

軟件開(kāi)發(fā)過(guò)程中會(huì)遇到哪些問(wèn)題

4

需求分析很重要，要先明確需求，然后要在設(shè)計(jì)的時(shí)候一邊編程一邊根據(jù)需求的改變而改變，越早修改，代價(jià)越小。

軟件開(kāi)發(fā)過(guò)程中會(huì)遇到哪些問(wèn)題

END

注意事項(xiàng)

以完全定制為例列舉，若是通用模板型的就沒(méi)有此種問(wèn)題了

軟件開(kāi)發(fā)過(guò)程中面臨的問(wèn)題的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于軟件開(kāi)發(fā)過(guò)程中面臨的問(wèn)題及對(duì)策、軟件開(kāi)發(fā)過(guò)程中面臨的問(wèn)題的信息別忘了在本站進(jìn)行查找喔。