如果有人問您: 您認為影響一個軟體品質的因素有哪些? 您腦子裡可能會閃出一堆: 功能, 介面, 運行速度, 安全性, 擴充性, 可維護性, 操作性……人者見人, 智者見智, 每個人對軟體理解不一樣, 答案自然也不盡相同, 也正是由於對軟體理解的這種不同, 使得我們在實現過程中有所偏重的部分, 也有所淡化的部分. 偏重那些我們認為對軟體品質影響較大因素,而淡化那些他認為較為次要的因素, 並且被淡化的那些因素不是作者認為它對於軟體沒有影響, 而是有限的人月不可能照顧到軟體的方方面面, 既然有所保留, 自然會有所放棄.
答案的不同會因人因物而不同. 一個對安全性特別嗜好的產品經理可能會使手下所有的員工都重視軟體安全, 一個對介面有特別興趣的專案經理可能讓員工用更多的精力在軟體的首頁(主介面)上;另一方面一個銀行系統可能對安全性要求特別高, 而一個點歌系統可能對易操作性或者介面要求比較高.
但是如果大家仔細觀察會發現一個有趣的現象: 無論任何系統對於運行速度的要求都是只增不減的. 而且有一種跡象: 隨著生活節奏加快, 各個行業對於軟體的運行速度的要求只會更高. 有一個很有趣的現象可以作為這種說法的佐證: 網頁上一個連結如果開啟超過2秒會有人抱怨它很慢, 如果超過5秒則會直接取消連結操作;但是那個網頁如果是必須要開啟的, 超過5秒還沒有進入時很多時候會我們會強制重新整理, 重新整理後如果又超過5秒則會直接關閉瀏覽器然後重啟. 我們可以允許自己等女朋友2個小時, 但絕不允許一個網頁使自己等待5秒.
其實這是一種極普遍的現象, 現代社會生活節奏加快, 人們對於速度的要求越來苛刻, 有人統計過: 一般中午我們在餐館等菜超過5分鐘時便會提醒服務員快點, 而如果超過10分鐘會起身催促老闆, 時間再長會出現提高嗓門叫喊的, 有不吃罵著髒話閃人的…
你可以想象這樣一些情境會有多麼折磨人: 火車票售票系統對於售票員的每一個操作反應超過0.5秒; 作業系統對於每一個檔案夾的開啟超過1秒; 開啟一個網頁超過2秒; 登入一個系統超過10秒; 串連資料庫超過45秒; 載入一張地圖超過1分種……當然如果您每次啟動您的愛機超過2分種您肯定會先抽根煙一邊解解心中的鬱悶一邊看著那個進度條在那不停地無限迴圈著轉.
如果你瞭解Oracle 的體繫結構, 會發現它始終圍繞著一條主線在開發 : 那就是 處理資料的速度. 速度就是Oracle 體繫結構的一根筋. 無論從儲存結構上分析還是從軟體結構上分析, Oracle幾乎一直在達到一個目的: 提高處理資料的速度! 以軟體結構中的記憶體結構為例說明 Oracle是如何把它當作命根的, 我們知道一個軟體程式, 必須先要在記憶體中為其指令代碼和快取資料申請, 劃分出一個地區, 再將其從磁碟上讀入, 放置到記憶體, 然後才能執行. 對此, Oracle 的作法是 : 將記憶體分為二個區, 一個SGA (System Global Area, 系統全域區), 一個 PGA (Program Global Area, 程式全域區). 其中SGA為所有使用者共用, 然後他的做法是 當訪問的資料只在資料檔案中時, Oracle 將讀取磁碟上的資料檔案, 然後將其放入資料快取中, 再對資料進行處理, 如果被訪問的資料已經位於資料快取中時, Oracle 將直接使用資料快取中的資料, 而不必再讀取磁碟中的資料檔案了, 由於讀取記憶體的速度比讀取磁碟快很多倍, 所以這種機制能提高資料庫的整體效率. 同樣的道理, Oracle 在寫日誌時並不將重做記錄資訊直接寫入磁碟的重做記錄檔中, 而是首先被寫入重做日誌快取, 當重做日誌快取中的重做記錄達到一定數量後, 再由日誌寫進程將其寫入重做記錄檔中.
這隻是 Oracle 提高處理資料速度而使用的技術中的冰山一角, 其實 Oracle 的每一步操作總是 “先記憶體後磁碟” 的, 這樣設計的原由可能大家現在都已心知肚明.
……
而在我們平時的編程中, 有很多並不合理的現象存在. 有人總喜歡把所有的 SQL都寫在前台, 寧願把伺服器累死也不寫一個預存程序;一堆一堆的網站開發人員開發了大半輩子的網站卻從沒用過任何緩衝技術;總有一些人藉著實現 ajax 技術而將所有的功能代碼都用 javascript實現. 我見過最厲害的程式員可以一次性把表中所有的資料全部讀取然後只用其中一條…
…….
影響軟體品質的各種因素的要求都在慢慢發生著變化: 介面要求簡單而大方, 功能要求精簡而強大, 操作要求簡易而不繁瑣…唯獨對於運行速度的要求, 沒有最高, 只有更高! 可以說影響軟體品質的因素的重要性正在 “內化”, 客戶都希望自己拿到的軟體使用起來 “很舒服”, 至少不能折磨人! 使用者不希望自己被軟體的速度超慢而氣的得肺炎, 不願意因為軟體速度的原因砸他的滑鼠, 敲他的桌子, 摔他的書;使用者可以允許軟體稍微難看一點, 但絕不允許它慢一丁點, 所有的使用者這個時候都是 “急性子”, 容不得半點鐘等待. Google 懂這個道理, Oracle 懂這個道理, 微軟也早就明白這個道理……俗話話的好, 長的難看不是你的錯, 但出來折磨人就是你的不對了!
每個人都有自己對軟體的理解, 當他需要實現一個軟體時在他便會在心裡告訴自己首先應該解決什麼問題. 這裡並沒有否認其他因素重要性的意思, 只是認為運行速度要求對於軟體開發來講已經上升到主要位置, 已經成為影響軟體品質的最重要的因素. 同時也提醒大家在軟體開發需要更多的考慮速度問題, 考慮使用者的感受, 做到真正的 “人性化服務”. 如果您還不明白這個道理: 您可以稍微回想一下每當您自己碰到一個運行速度十分不理想的操作時您當時的感受是什麼? 您當時是不是有說髒話的衝動?
如果筋斷了, 再漂亮的肌肉也會很快成為一堆爛肉--因為它不可用.