? ? ? ? （注：這個東西是2007年寫的，算是個緬懷，或是個吐槽。所有注都是本次發(fā)布新加的。）

簡介

????????本文講述完全沒有軟件工程經(jīng)驗(yàn)的軟件小組如何借助VS VSS等工具為UNIX開發(fā)C++程序，實(shí)現(xiàn)在小組規(guī)模的初級開發(fā)過程。這不是TSPi或者CMM，這比CMM1級（初始級）還要低，可稱之為CMM0。

目錄

1 概述

2 責(zé)任和責(zé)任感

3 概念

3.1 配置和配置項(xiàng)

3.2 軟件配置管理

3.3 基線

4 開發(fā)過程

5 松散開發(fā)的問題

6 測試和發(fā)布

7 基本開發(fā)結(jié)構(gòu)

7.1 結(jié)構(gòu)圖

7.2 服務(wù)器

7.3 開發(fā)者環(huán)境

8 技術(shù)細(xì)節(jié)

8.1 版本控制VSS

8.2?開發(fā)工具VS（visual studio）

8.3?數(shù)據(jù)庫工具TOAD

8.4?數(shù)據(jù)庫結(jié)構(gòu)檢查

8.5?UNIX SHELL 腳本

8.6?維持單一版本

8.7?避免絕對依賴關(guān)系

8.8?記錄變更歷史

8.9?自動版本升級

8.10?版本標(biāo)識和檢測

1 概述

????????CMM對于內(nèi)地大多數(shù)軟件公司來說，僅僅是老板用紅包（當(dāng)然少不了吃飯和旅游）兌換的一塊牌子，而項(xiàng)目負(fù)責(zé)人和程序員仍然在無序開發(fā)的泥沼中掙扎、應(yīng)付永遠(yuǎn)做不完的需求和BUG。
????????我聽過很多的言論，表達(dá)“軟件文檔是毫無意義的”這樣的觀點(diǎn)。我相信大多數(shù)程序員都對此心有戚戚焉，我個人的經(jīng)驗(yàn)也同樣在部分層面支持這個觀點(diǎn)。
????????軟件工程錯了嗎？
????????是的，軟件工程錯了，如果你只是想得到軟件的好處。
????????軟件工程是一套標(biāo)準(zhǔn)和方法，標(biāo)準(zhǔn)和方法本身并不能帶來任何利益，每個標(biāo)準(zhǔn)和方法都有適用的基礎(chǔ)條件和成本付出，只有正確地實(shí)施才會獲得好處。
????????很多程序員都喜歡玩CS，有兩款典型自動步槍（不能區(qū)分沖鋒槍和自動步槍的請保持沉默），AK47（AK74）和M4（M16），這兩種步槍孰優(yōu)孰劣？簡單地說，M4(M16)是高精尖武器（僅其塑料材質(zhì)就可以嚇退大多數(shù)仿制者），低后坐力、高精度，昂貴、復(fù)雜、精密、易損壞，只能由受過專業(yè)訓(xùn)練的士兵使用，并且需要后勤支持（看到美軍在伊拉克把安全套套在槍口上以避免沙子進(jìn)入導(dǎo)致卡殼嗎？），AK47(AK74)則是簡單武器，精度很差，廉價、耐用、無需維護(hù)，風(fēng)沙海水都不怕，最適合沙漠、山區(qū)的恐怖分子使用。對恐怖分子而言，M16是毫無用處的塑料垃圾。
????????好了，恐怖分子們，拿起AK，準(zhǔn)備戰(zhàn)斗。

2 責(zé)任和責(zé)任感

????????每個人都有責(zé)任就是每個人都沒有責(zé)任。
????????管理者是承擔(dān)管理責(zé)任的人，小組負(fù)責(zé)人是管理者，帶徒弟的師傅也是管理者。
????????甚至于，每個人都要管理自己的程序、文檔、mp3和游戲，每個人都是管理者。當(dāng)然，我們不會把希望寄托在每個人身上，因?yàn)椤總€人都有責(zé)任就是每個人都沒有責(zé)任。
????????任何把希望寄托在人的自覺性上的人都不能成為合格的管理者。
????????作為小組負(fù)責(zé)人，必須對全組負(fù)責(zé)。作為從零起步的開發(fā)小組，項(xiàng)目能否順利進(jìn)行完全取決于小組負(fù)責(zé)人的能力。
????????下面列出對小組負(fù)責(zé)人的要求，其中有些要求對個人能力是一個巨大的考驗(yàn)。
????????要掌握每個成員的技術(shù)能力，正確地分配任務(wù)。要能夠估計(jì)成員完成任務(wù)的所需的時間。
????????要了解完成任務(wù)所需的技術(shù)，知道從何處取得相關(guān)技術(shù)的資料。高級管理者并不需要成為每項(xiàng)技術(shù)的專家，越是低級管理者則越是要精通技術(shù)。
????????要在心里正確估計(jì)進(jìn)度，正確地估計(jì)代碼質(zhì)量。要估計(jì)測試和返工所需的時間。
????????要把握總體設(shè)計(jì)，檢查任何影響其它模塊、其他人的設(shè)計(jì)和變更。
????????要查看所有人的代碼，要求代碼風(fēng)格盡量符合小組負(fù)責(zé)人的習(xí)慣。
????????要有安全意識，主動發(fā)現(xiàn)并預(yù)防可能發(fā)生的意外事件。
????????要了解下面章節(jié)所提到的概念和技術(shù)。

3 概念

3.1 配置和配置項(xiàng)

????????“配置”是在技術(shù)文檔中明確說明并最終組成軟件產(chǎn)品的功能或物理屬性。因此“配置”包括了即將受控的所有產(chǎn)品特性，其內(nèi)容及相關(guān)文檔，軟件版本，變更文檔，軟件運(yùn)行的支持?jǐn)?shù)據(jù)，以及其他一切保證軟件一致性的組成要素，相對與硬件類配置，軟件產(chǎn)品的“配置”包括更多的內(nèi)容并具有易變性。
????????受控軟件經(jīng)常被劃分為各類配置項(xiàng)（Configuraion items, CIs），這類劃分是進(jìn)行軟件配置管理的基礎(chǔ)和前提，CIs是邏輯上組成軟件系統(tǒng)的各組成部分。比如一個軟件產(chǎn)品包括幾個程序模塊，每個程序模塊及其相關(guān)文檔和支撐數(shù)據(jù)可能被命名為一個CI。一個系統(tǒng)包括的CIs的數(shù)目是一個與設(shè)計(jì)密切相關(guān)的問題。一個純軟件的CI通常也稱之為軟件配置項(xiàng)（CSCI）。
????????現(xiàn)在所有的配置管理工具均提供對配置項(xiàng)的管理工具，包括(Check in和Check out機(jī)制的 )版本管理和版本標(biāo)號功能。由于版本和標(biāo)號管理比較繁瑣，一般推薦使用配置管理工具，減少事務(wù)性工作。

3.2 軟件配置管理

????????軟件配置管理是貫穿于整個軟件過程中的保護(hù)性活動，它被設(shè)計(jì)來（1）標(biāo)識變化，（2）控制變化，（3）保證變化被適當(dāng)?shù)陌l(fā)現(xiàn)，以及（4）向其他可能有興趣的人員報(bào)告變化。

3.3 基線

????????基線（baseline）是配置項(xiàng)的穩(wěn)定版本，是進(jìn)一步開發(fā)的基礎(chǔ)。一般一條基線包含一組配置項(xiàng)，在所有包含的配置項(xiàng)確認(rèn)通過后（測試或評審?fù)ㄟ^）基線形成，基線一般采用更高級別的變更保護(hù)。
????????基線概念反過來解釋就是一項(xiàng)工作所依賴的所有配置項(xiàng)。比如，一個新模塊的開發(fā)依賴公共組件并需要與特定模塊交互，那么新模塊所依賴的基線至少要包括公共組件的特定版本、與特定模塊交互的接口協(xié)議的特定版本（或者特定模塊的特定版本）。
????????一般開發(fā)過程中我們通過打標(biāo)簽的方式標(biāo)識基線，并盡量避免復(fù)雜的的基線劃分。

4 開發(fā)過程

????????基本的開發(fā)過程分為設(shè)計(jì)、開發(fā)、測試、發(fā)布。發(fā)布是把軟件和文檔打包提供給客戶的過程，該過程較簡單，技術(shù)性不強(qiáng)，不多討論。設(shè)計(jì)是難度最高的過程，通常只是在頭腦里模擬完成，不會有成文的輸出（我們偷懶省去了設(shè)計(jì)過程，至于更無法掌握的需求根本不必提及）。剩下的開發(fā)和測試是實(shí)際看得到的環(huán)節(jié)，通常我們制定項(xiàng)目計(jì)劃只考慮開發(fā)和測試。
更現(xiàn)實(shí)一點(diǎn)說，多數(shù)的項(xiàng)目開發(fā)過程的開發(fā)和測試是混在一起的，開發(fā)人員在開發(fā)時自行測試自己的程序，沒有獨(dú)立的測試過程。
????????作為項(xiàng)目開發(fā)過程化的第一步，要形成版本概念（與基線概念相關(guān)）。版本是妥善保存的，成為追溯的依據(jù)。經(jīng)常發(fā)生這樣的情況：新版本測試發(fā)現(xiàn)問題，需要用舊版本檢查以確定問題是新版產(chǎn)生還是舊版原有的，然后需要對比版本以尋找問題所在。
????????項(xiàng)目過程化的第二步，是要有獨(dú)立的測試過程。獨(dú)立的測試過程不一定要求專職的測試人員，開發(fā)人員可以互相測試。一定要在版本上測試，不能邊改邊測。發(fā)布的版本必須是測試通過的完整版本，不能是發(fā)現(xiàn)錯誤修改后只測試了出錯點(diǎn)的版本（BUG修改經(jīng)常在其他地方產(chǎn)生意想不到的錯誤）。
????????以上兩步是最基本的，是小組范圍內(nèi)能夠自行掌握的。形成版本使過程控制成為可能，獨(dú)立測試則顯著提高產(chǎn)品質(zhì)量。
????????版本化原則上并不需要任何額外工具，在有版本控制工具以前可以做手工的存檔。版本控制工具可以提供較好的版本管理，但不能偷懶把發(fā)布版本放在開發(fā)庫里（盡管發(fā)布版本總是對應(yīng)一個開發(fā)版，但管理上要求發(fā)布版本與開發(fā)版本脫離）。版本控制工具可以提供較好的過程管理，能夠明確產(chǎn)品包含的有效源代碼、文檔，能夠控制同一個文件的修改沖突，能夠檢查項(xiàng)目、文件所發(fā)生的變化，給小組負(fù)責(zé)人控制項(xiàng)目提供有力的支持。
????????獨(dú)立的測試過程給軟件質(zhì)量提供一個可信賴的過程保障，開發(fā)者自測的局限性非常大（這是心理學(xué)原因，不是靠工作態(tài)度可以解決），通常交換測試就可以發(fā)現(xiàn)大量簡單錯誤。在有獨(dú)立測試部門的情況下，一般開發(fā)組提交給測試組的代碼已經(jīng)是經(jīng)過開發(fā)組內(nèi)部測試的版本（否則BUG太多面子上不好受并且會影響?yīng)劷穑?/p>

5 松散開發(fā)的問題

????????松散系統(tǒng)是由大量非緊密相關(guān)的部分組成的系統(tǒng)，各模塊在大多數(shù)時候可以互不干擾地獨(dú)立開發(fā)，但少數(shù)情況下需要修改公共部分。
????????由于多數(shù)情況下各自開發(fā)不需要交互，長時間以后導(dǎo)致每個人對公共基礎(chǔ)（一般主要是數(shù)據(jù)庫）的掌握不足。每個開發(fā)者都可能根據(jù)自己的需要增加了一些表，不同的開發(fā)者可能重復(fù)開發(fā)了相似的功能，不同的開發(fā)者可能對同一個數(shù)據(jù)做出了不同的假定。
????????在維護(hù)期對生產(chǎn)系統(tǒng)的BUG修復(fù)或特殊需求經(jīng)常直接在生產(chǎn)系統(tǒng)上進(jìn)行，因?yàn)閱栴}經(jīng)常與特定的環(huán)境和數(shù)據(jù)有關(guān)，很顯然在生產(chǎn)系統(tǒng)上直接修改、測試是最快速的、最方便的方式。這種現(xiàn)象導(dǎo)致不兼容的特殊版本，對后續(xù)維護(hù)造成致命的障礙。管理者應(yīng)該意識到這個問題。
????????松散開發(fā)和維護(hù)方式實(shí)際上不是一種開發(fā)模式，而是一種混亂。
????????在Windows環(huán)境下開發(fā)時很少所有人共享同一個數(shù)據(jù)庫和同一套代碼，然而在UNIX上卻相當(dāng)普遍。究其原因可能是因?yàn)閁NIX上多數(shù)都是大系統(tǒng)，為每個人構(gòu)建一套開發(fā)環(huán)境可能資源不允許，開發(fā)時經(jīng)常麻煩管理員也不是很方便。
????????短期內(nèi)解決這個問題所投入的成本與帶來的長遠(yuǎn)好處相比是否值得？從現(xiàn)實(shí)看多數(shù)人的答案是“否”。
????????解決的辦法有沒有？當(dāng)然有。但的確不是很省力的，一方面需要掌握多方面的技術(shù)，另一方面要投入人力資源進(jìn)行控制。技術(shù)面和技術(shù)深度對內(nèi)地從業(yè)者來說都是薄弱環(huán)節(jié)。若要加強(qiáng)控制就必須存在一個人對所有變更進(jìn)行審查，確保所有變更都被統(tǒng)一記錄以便其他人能夠知曉。小組負(fù)責(zé)人應(yīng)該親自進(jìn)行控制，小組負(fù)責(zé)人是唯一可能同時具有足夠技術(shù)、權(quán)力、職責(zé)和責(zé)任心的人。
????????本文所提及的技術(shù)細(xì)節(jié)都是在數(shù)年里逐漸解決的，解決之前覺得很麻煩，解決之后覺得不過如此（技術(shù)問題從來如此）。多數(shù)技術(shù)要求對管理都有很大的作用，是因?yàn)橛泄芾硇枰乓脒@些技術(shù)。
????????應(yīng)付同一個模塊每天三次的緊急修改需求是不可能的，如果這樣的事情發(fā)生，我們只能說質(zhì)量已經(jīng)失控。
????????對于突發(fā)的故障的維護(hù)，可以采用緊急處理策略，直接生成一個特殊版本解決問題（畢竟生產(chǎn)系統(tǒng)的故障必須盡快解決），然后再將特殊版本的修改并入正式版本。在生產(chǎn)系統(tǒng)直接修改不并入正式版本會導(dǎo)致最后產(chǎn)品不可維護(hù)，這是要通過制度才能解決的問題。

6 測試和發(fā)布

????????軟件發(fā)布的版本必須是測試過的版本，中間不能有開發(fā)人員介入。作為管理者，不能信賴過程上不可靠的東西。
????????軟件發(fā)布應(yīng)盡量完整發(fā)布，不得不頻繁發(fā)布小模塊的時候必須謹(jǐn)慎小心，避免差錯。
????????必須嚴(yán)格按照測試通過的順序發(fā)布，必須嚴(yán)格按照發(fā)布順序?qū)嵤└隆?br> ????????小模塊發(fā)布時小組負(fù)責(zé)人必須仔細(xì)檢查變更細(xì)節(jié)以確保不會產(chǎn)生模塊沖突。
????????若與其他小組有關(guān)聯(lián)則必須聯(lián)合發(fā)布并且在代碼中檢查其它小組的模塊的版本。
????????每個小模塊的開發(fā)者無權(quán)發(fā)布模塊。發(fā)布必須經(jīng)過小組負(fù)責(zé)人的認(rèn)可。
????????公共模塊的修改必須在小組主要開發(fā)人員認(rèn)可后進(jìn)行，不可隨意修改。

7 基本開發(fā)結(jié)構(gòu)

（注：由于年代關(guān)系，后續(xù)提及的軟件可能已經(jīng)過時，用同等功能的替代即可）

7.1 結(jié)構(gòu)圖

7.2 服務(wù)器

????????服務(wù)器是核心。這個服務(wù)器不是開發(fā)用的主機(jī)，是用來共享資源和版本管理的服務(wù)器。
????????共享資源包括開發(fā)用的各種軟件的副本、各種技術(shù)資料以及其他對團(tuán)隊(duì)有意義的東西。
????????版本管理一般都采用VSS，需要把VSS數(shù)據(jù)庫目錄放在服務(wù)器上共享。使用CVS可能無法順利完成所有需要的工作。
????????需要一再強(qiáng)調(diào)的就是，只有入庫的東西才被承認(rèn)。聲稱代碼寫完了但是忘了入庫的人一律扣發(fā)當(dāng)月獎金并全組通報(bào)批評。

7.3 開發(fā)者環(huán)境

????????每個開發(fā)者擁有自己的開發(fā)環(huán)境，以避免開發(fā)干擾，因此需要在UNIX主機(jī)和數(shù)據(jù)庫建立獨(dú)立的用戶。如果不能做到，至少保證兩個用戶，一個用來開發(fā)一個用來測試。
????????推薦開發(fā)者使用VS或其他集成開發(fā)環(huán)境。集成開發(fā)環(huán)境提供的輔助功能會極大地提高開發(fā)速度和代碼質(zhì)量。
????????可以統(tǒng)一使用VS作為開發(fā)環(huán)境，配合FTP工具上傳。如果全部統(tǒng)一用VS則還可以使用VS直接訪問VSS。用VS直接訪問VSS與手工訪問VSS相比較少犯VSS操作錯誤。
????????每個開發(fā)者使用獨(dú)立的開發(fā)環(huán)境有助于使開發(fā)者明確認(rèn)識到完成的代碼必須入庫。獨(dú)立的測試環(huán)境也有助于開發(fā)者養(yǎng)成詳細(xì)記錄數(shù)據(jù)庫變更的習(xí)慣。

8 技術(shù)細(xì)節(jié)

8.1 版本控制VSS

????????版本控制通常使用VSS或者CVS。使用版本控制的目的在于限制代碼的隨意修改、追溯代碼的修改過程。就概念而言，VSS更符合版本控制概念，使用者能夠形成正確的版本控制觀念。
????????版本控制軟件維護(hù)一個庫存放代碼，每個開發(fā)者將代碼取回作本地開發(fā)，然后將代碼放回，代碼放回后其他開發(fā)者才能看到。
????????每個人都必須正確掌握VSS的使用，培訓(xùn)是必要的。
????????VSS默認(rèn)配置為不允許多人簽出，這正是我們需要的。每個人都需要設(shè)置對項(xiàng)目操作的遞歸選項(xiàng)，這樣可以連同子目錄一起操作。簽入文件后應(yīng)查看歷史或比較文件以確認(rèn)簽入正確。
????????熟練掌握目錄比較和查看歷史對每個人都很重要。

8.2?開發(fā)工具VS（visual studio）

????????建立C++ Win32控制臺項(xiàng)目，空項(xiàng)目。
????????將項(xiàng)目文件添加到項(xiàng)目中，建立與實(shí)際目錄結(jié)構(gòu)一致的VS文件組織結(jié)構(gòu)。
????????如果有頭文件需要配置搜索路徑才能訪問，則設(shè)置項(xiàng)目的“附加包含目錄”。否則無法解析頭文件，不能提供類型幫助。
????????如果不使用VS整合的VSS訪問則每個開發(fā)者都要重復(fù)這些工作。如果把項(xiàng)目文件放在VS的項(xiàng)目文件之下的子目錄（此時VS項(xiàng)目文件存儲代碼文件的相對路徑）則可以直接復(fù)制VS項(xiàng)目文件給別人用。
????????如果使用VS整合的VSS訪問則使用VS的添加到版本控制的功能將項(xiàng)目添加到VSS，其他人用VS的從版本控制打開項(xiàng)目即可。
????????VS不提供FTP功能，需要同時打開一個FTP軟件來上傳源代碼。如果愿意，可以對VS做二次開發(fā)來簡化操作。
????????VS提供的最大幫助是即時解析源代碼提供變量、函數(shù)說明、類成員的信息等。VS提供的查找、替換、格式化功能也是很強(qiáng)大的。有經(jīng)驗(yàn)的使用者可以寫出一次編譯通過的代碼（呵呵，絕不是無BUG）。

8.3?數(shù)據(jù)庫工具TOAD

????????TOAD能提供數(shù)據(jù)庫的腳本、數(shù)據(jù)腳本、數(shù)據(jù)庫變更腳本，能做全用戶的導(dǎo)入導(dǎo)出。
????????導(dǎo)出的數(shù)據(jù)庫結(jié)構(gòu)腳本可以入庫進(jìn)行版本控制?？梢杂脭?shù)據(jù)庫腳本或數(shù)據(jù)庫備份重建開發(fā)者環(huán)境。
????????對數(shù)據(jù)庫的變化應(yīng)該提供變更腳本。
????????所有用戶共享一個庫的風(fēng)險是很大的，一個人的誤操作就可能毀了一切。

8.4?數(shù)據(jù)庫結(jié)構(gòu)檢查

????????標(biāo)準(zhǔn)的數(shù)據(jù)庫結(jié)構(gòu)檢查是查詢數(shù)據(jù)庫數(shù)據(jù)字典。數(shù)據(jù)庫數(shù)據(jù)字典是一組視圖，可以查詢所有的表、列、約束、同名詞、序列、過程等的詳細(xì)信息。
????????復(fù)雜的程序可能需要查詢數(shù)據(jù)庫結(jié)構(gòu)來確定操作如何進(jìn)行，這是完成一些自動維護(hù)任務(wù)所需要的。

8.5?UNIX SHELL 腳本

????????編寫復(fù)雜的腳本可以執(zhí)行很多復(fù)雜任務(wù)。比如自動檢測機(jī)型、判斷主機(jī)資源狀況、執(zhí)行數(shù)據(jù)庫腳本（可以配合復(fù)雜的sqlplus腳本）檢查數(shù)據(jù)庫結(jié)構(gòu)、根據(jù)實(shí)際情況執(zhí)行不同的編譯過程或其它程序等等。
????????整個項(xiàng)目保持為同一個軟件包，用單一方式編譯執(zhí)行是很有價值的。腳本至少可以做到根據(jù)機(jī)型使用不同的配置文件、根據(jù)參數(shù)自動選擇合適的優(yōu)化開關(guān)、自動處理特殊的預(yù)編譯宏、自動執(zhí)行數(shù)據(jù)庫檢查腳本。
????????Shell編程的關(guān)鍵是掌握返回碼的處理和條件邏輯，這樣就可以有機(jī)地把命令組織起來像個像樣的程序。

8.6?維持單一版本

????????不同廠商的UNIX環(huán)境有很多差異，盡可能選擇通用的語法，避免編譯問題。無法避免的可以用宏開關(guān)來處理。對宏開關(guān)要能用編譯腳本自動處理，手工處理容易出錯。
????????有時不同用戶會提出沖突的需求，優(yōu)先選擇通過配置實(shí)現(xiàn)，實(shí)在不方便的可以用開關(guān)實(shí)現(xiàn)，但最好不要用宏開關(guān)，用全局變量開關(guān)比較好。
????????可以建立一個系統(tǒng)表記錄用戶信息，程序啟動時初始化全局變量，程序根據(jù)全局變量決定特殊處理。

8.7?避免絕對依賴關(guān)系

????????任何一個系統(tǒng)都應(yīng)該避免對環(huán)境做過多的假定，不依賴特定的用戶、目錄、端口、系統(tǒng)Key之類的東西。當(dāng)系統(tǒng)發(fā)生問題需要調(diào)試的時候，很可能需要在正在運(yùn)行的系統(tǒng)的“旁邊”建立測試系統(tǒng)，比如在另一個目錄用不同版本的代碼編譯執(zhí)行，或者希望程序?qū)⑤敵鲚敵龅揭粋€臨時位置。設(shè)計(jì)時考慮調(diào)試需要可以方便后期的工作。

8.8?記錄變更歷史

????????項(xiàng)目必須有一個文件記錄變更歷史，由每個變更實(shí)施者填寫。該文件可放置在項(xiàng)目根目錄下。記錄每個變更的時間、人員、原因、方案、變更的項(xiàng)目、相關(guān)影響等，特別是數(shù)據(jù)庫的結(jié)構(gòu)變化。每個變更順序編號。
????????小組負(fù)責(zé)人將隨時檢查變更歷史。

8.9?自動版本升級

????????軟件升級應(yīng)當(dāng)簡單，執(zhí)行一個程序或腳本即可，不要讓用戶去執(zhí)行瑣碎的修改。
????????對開發(fā)而言同步不同的開發(fā)環(huán)境也需要這樣做。

8.10?版本標(biāo)識和檢測

????????軟件應(yīng)標(biāo)識自身，程序執(zhí)行首先應(yīng)顯示版本信息。每個模塊都有自己的標(biāo)識。
????????應(yīng)檢查數(shù)據(jù)庫結(jié)構(gòu)和軟件的預(yù)期是否一致。不一致時程序必須拒絕執(zhí)行。
????????對相關(guān)模塊版本也應(yīng)同樣檢查。

（這里是結(jié)束）文章來源地址http://www.zghlxwxcb.cn/news/detail-734435.html

到了這里，關(guān)于軟件工程：小組開發(fā)過程技術(shù)(VS VSS UNIX C++)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！