即便在一些有著穩(wěn)健和安康的文檔編寫文化的組織中，應(yīng)用的進(jìn)化和修正速度也會遠(yuǎn)遠(yuǎn)快于文檔編寫速度。理想狀況是軟件變化速度遠(yuǎn)遠(yuǎn)快于文檔編寫速度，即便有自動化文檔系統(tǒng)，有時分我們依然需求人工編寫一些文檔。這種文檔需求經(jīng)過一定的技術(shù)轉(zhuǎn)換，方能提供應(yīng)在特殊閱讀環(huán)境中的讀者閱讀，因而無法經(jīng)過自動化辦法維護(hù)。
API參考文檔以及其他高度技術(shù)化的文檔，則很可能經(jīng)過編程言語平臺的自動化文檔編寫機(jī)制完成（如Java的 Javadoc、Ruby的RDoc Python的 Pydoc等）。但是，有些需求人類表達(dá)（這是最珍貴的交流方式）的文檔，則不像技術(shù)文檔一樣與應(yīng)用程序和根底架構(gòu)有嚴(yán)密關(guān)系。為此，技術(shù)文檔可能在一個月內(nèi)（或更短的時間內(nèi)）就會過時，而有一些文檔可能幾年時間都不曾更新過逐個不過，這種狀況實踐上比沒有技術(shù)文檔還要槽，由于會進(jìn)上程帥以為不需求從別處獲取信息，而誤以為這些過時文檔就是正確的信息。
除此之外，當(dāng)文檔創(chuàng)立后，許多工程師就不會再更新文檔了。定期檢查文檔才干讓文檔堅持最新狀態(tài)。
處理辦法：通知工程師更新文檔
在整個組織范圍內(nèi)，人們不太可能細(xì)致閱讀文檔管理系統(tǒng)（如Wi） 中的一切文檔，但在一個部門級別上，卻可能會呈現(xiàn)一些文檔修正和編輯。但是，運(yùn)用隨機(jī)辦法的效率是遠(yuǎn)遠(yuǎn)不夠的，我們必需經(jīng)過某種機(jī)制，讓文檔管理系統(tǒng)可以通知文檔一切人或管理員，讓他們在一段時間后更新文檔。開源Wiki系統(tǒng) Twiki提出了一種處理計劃，它的頁面像報紙一樣在時間長了之后會變黃。而且，在系統(tǒng)以為文檔可能需求更新時，它會向文檔一切人發(fā)送一封通知郵件。
但只要工具還不夠，運(yùn)維與開發(fā)團(tuán)隊還必需轉(zhuǎn)變認(rèn)識，他們必需將運(yùn)用文檔視為一種軟件改良手腕。例如，需求更新的頁面會變成黃色但這并不意味著有人會去更新它。必需有人去響應(yīng)這個通知，假如接納者不了解創(chuàng)立及維護(hù)文檔關(guān)于代碼和系統(tǒng)的價值，那么這個響應(yīng)可能就不會呈現(xiàn)。假如技術(shù)人員曉得當(dāng)文檔需求更新時，系統(tǒng)才會通知他們，那么當(dāng)他們接納到一個通知時，他們就很可能會跟進(jìn)處置這個通知。這似乎有一些瑣碎，但是對技術(shù)人員予以告知能夠鼓舞他們認(rèn)真看待文檔。
益處：將文檔整合到常規(guī)活動中
當(dāng)網(wǎng)站設(shè)計開發(fā)人員習(xí)氣了接納更新通知并響應(yīng)這些通知之后，他們就會看到文檔在改良軟件方面的價值，這樣將進(jìn)一步鼓勵他們及時響應(yīng)通知。構(gòu)成大型網(wǎng)站根底架構(gòu)的軟硬件通常由一定數(shù)量的位于數(shù)據(jù)中心內(nèi)的效勞器組成。目前，這些根底架構(gòu)的裝置及維護(hù)在一定水平上依然經(jīng)過人工方式完成。我們將引見隨著計算范疇內(nèi)的打破性停頓，虛擬化根底架構(gòu)是如何減少人工需求的，以及如何完成其中一些流程的自動化。不過，在思索施行自動化之前，最好先理解一下當(dāng)前的工作流程。
更多精彩請關(guān)注：http://www.jukabz.cn
