The Introduction of Ten Pounds in a Five-Pound Sack



這是人月神話:軟體專案管理之道(20週年紀念版)的第九章:,『』在簡體文版本裡反而被翻作『削足適履』,但是如果你查一下成語辭典,這是比喻勉強遷就,拘泥舊例而不知變通。這可跟地盡其利,物盡其用的感覺差很多了,這一篇有幾個主題,空間就是金錢、程式大小的控制、節省空間的技術、資料的呈現方式是程式設計的本質等主題,端看這些主題,ㄚ琪私以為翻成削足適履並不怎麼恰當,所以還是覺得繁體版的翻譯較佳!

第一個主題,我引用一下最後一段的結論:『由於軟體系統的大小對使用者的成本負擔影響非常大,軟體開發人員必須設定空間大小的目標(size target),進而控制程式大小、發展節省空間的技術,這跟硬體開發人員設定元件數量的目標、控制元件數量、發展減少元件數量的技術是一樣的道理。就像花錢一樣,程式大小本身並沒有錯,但是不必要的空間浪費就不好了。』這段敘述來自35年前,想當然爾似乎不怎麼有用,因為隨著硬體技術的發展,我們發現很多的軟體專案對於程式大小,似乎已不再那麼地強求,因為開發時間似乎已經比開發的空間還要重要了!有時候我們得想想「以空間換時間」的持久戰策略,還有時間本來就是金錢,時間是錢,空間也是錢,反正都是錢,就看哪個成本較低來排優先順序了,況且要空間就跟技術有關係,如果技術夠的話,我會同意盡量節省空間吧!

在假設我們的技術夠的話,我們還需要一些管理的工作,在程式大小的控制這節,還是以OS/360的經驗教訓來解釋,我不想引用太多的文字,只簡述這裡所得到的3個教訓,一『必須做好整體空間規劃(total size budget),這不單包括了常駐空間規劃(resident-space budget),背後跟這些有連帶關係的存取動作也應該一併納入考量』,二『在規定某個模組的大小之前,你得先精確定義出這個模組該做的事』,三『由於我們的專案夠大,在管理溝通方面也夠糟,使得團隊中的許多成員都非常本位地謀取自身的績效,並視彼此為競爭對手,每個人未達自己的目標,只求局部上的最佳化,很少人會停下來思考最終呈現給客戶的整體效果,這種惡質的想法和溝通是大型計畫裡的主要風險。』說到這裡,又是牽扯到溝通的問題,所以溝通的學問真的是很大。溝通表達訓練這種技巧已經可以成為一個課程來討論了!

在節省空間的技術上,ㄚ琪只提兩件管理者要做的事,一『確保大家的本事是真正透過程式設計的技術訓練而來,而不是僅憑個人的天賦或過去的經驗。』,二『認知到寫程式有它專業的技術,組件是要去創造才有的。』看了第一點之後,ㄚ琪會更加地退縮,因為竊以為,看起來這種本事很多還是憑天賦來的,當然過去的經驗也是不可少,就因為這樣,所以才能變為本事,所以對此ㄚ琪有不同的意見。

資料的呈現方式是程式設計的本質(Representation is theessence of programming),將是這篇的結論,有時我們都會鑽牛角尖在一個地方上,我習慣稱之為局部最佳化的瓶頸,但是如果有辦法跳出這個局部的話,你可能可以看到全部最佳話的可能性,有時我們稱不能,在神永遠都能,試著用你的靈感想想,會讓我們收穫很多!

Print Friendly, PDF & Email

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料