1.靜態軟硬體劃分
關於軟體與硬體的"官方"標準定義是:
軟體是一系列按照特定順序組織的電腦資料和指令的集合。
硬體包括電腦中所有物理的零件,以此來區分它所包括或執行的資料和為硬體提供指令以完成任務的軟體。
這是"狹義"的定義,實際上對於"廣義"的系統,在一個特定的條件下,硬體是不能改變的部分;軟體是可以改變的部分。
比如餘世維經常舉的酒店管理的例子中,在"酒店系統"中,在"特定成本"的約束下,硬體指酒店的基礎設施,軟體指酒店的管理。
現在是時候對應用開發領域中的軟硬體重新劃分了!
對於我們開發的應用系統(Application),軟體是我們自己寫的代碼;硬體是什麼呢?相對於我們寫的代碼,下列的東西是不能改變的,它們都是"硬體":
主機:這個本來就是硬體
作業系統:通常的應用不會去改寫作業系統;
資料庫:我們可以在資料庫上寫具體的資料庫應用,但是對於代碼來說,資料庫和資料庫應用都是硬體;
應用伺服器:通常的應用也不會去改寫應用伺服器;
架構:架構一旦設計好了,就不能輕易改變了;
程式碼程式庫:一般來說我們只是調用。
別人的代碼:在團隊開發中,不同的人負責不同的模組/層。這個其實不是絕對的"硬",通過溝通還是可以修改的,但肯定比修改自己的代碼要困難。
這樣劃分下來,其實在一個應用系統中,真正屬於"軟體"(即我們可以改變)的部分,其實是很少的。
2.動態軟硬體劃分
為什麼要強調軟體與硬體的劃分呢?因為一個普遍存在的錯誤認識,不僅僅是客戶,也包括相當多的開發人員,認為系統可以隨意修改。其實這個觀點是有問題的。正確的觀點是"系統可以任意設計"。
對這個問題還可以從軟硬體劃分的角度來看。即代碼在不同的階段分屬於軟體和硬體。比如我們經過分析,設計,開發,測試等過程,產生了一組代碼,滿足了特定的需求;那麼在需求變更的時候,這組代碼就變成了不可改變的硬體,因為我們原有的功能還是需要的。
3.需求變更與醜陋的代碼
其實在系統維護時看到的大部分"醜陋"的代碼,都是在需求變更時產生的。這和看問題的角度不同有關係。需求變更時,我們是基於"已有代碼"這個"硬體"環境來考慮問題,在這種特定的情況下,代碼並不是那麼醜陋;而系統維護時,我們是基於全部已有需求,從全域的角度看問題,這時所有的代碼都被視為"軟體",有些代碼就顯得醜陋了。
4.解決之道
關於解決之道,沒有列入摘要中,因為我也沒有好辦法。只能想到兩點要注意的事情:
一是反覆式開發法,有時可能只是增加一個"小功能",但是要充分考慮對整個系統的影響。反覆式開發法可以走完分析、設計、開發、測試的完整過程,盡量從全域考慮新功能,避免"局部最佳化"帶來的影響。
二是重構,這個需要時間,在制訂計劃時增加1-2個重構的迭代步驟,進行"全域最佳化"。
更多更好的辦法還希望大家交流討論。