讀《人月神話》

2022-06-29 03:57:07 字數 1245 閱讀 5403

人月神話的英文是 《man-month mythical》,人月其實是軟體工程管理工程量的單位,乙個人每月的工作量,其實是想說明是使用人月的方式來估算大型專案是不靠譜的,只是乙個神話的方式。而作者frederick p.brooks,brooks被認為是「ibm 360系統之父」,他擔任了360系統的專案經理,以及360作業系統專案設計階段的經理。憑藉在上述專案的傑出貢獻,他、bob evans和erich bloch在2023年榮獲了美國國家技術獎。早期,brooks曾擔任ibm stretch和harvest計算機的體系結構師。

開篇以焦油坑引出,焦油坑,讓陷入其中的猛獸越掙扎越是難以掙脫束縛,陷入坑底。而大型的系統開發就是這樣的焦油坑,各種問題糾結在一起,讓人越陷越深,沒有辦法看清事情的本質。在其中,不要做乙個純粹的樂觀者。《人月神話》中什麼是人月?是使用的在估計和進度安排中的工作量單位。作者認為用人月作為 衡量一項工作的規模是乙個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互 替換的。 人數和時間的互換僅僅適用於以下情況:某個任務可以分解給參與人員,並且他們之 間不需要相互的交流。

「孕育乙個生命需要十月懷胎,所以不管有多少個母親,時間都是一樣的」,闡明增加人手來彌補專案被拖延的進度,有時候是不現實的。從這裡開始慢慢透漏出,人月是神話的韻味。

保持設計的概念完整。無論對小軟體還是大軟體,都必須由乙個設計師主導,最多兩個人討論來共同完成軟體的整體設計。作為乙個軟體,乙個系統,必須有乙個清晰明確的概念模型。具體的實現人員可以細化概念,

很少有人類的活動要力求完美,程式卻像是神的咒語,以乙個個音節、乙個個停頓層層構建出前所未有或已經存在的事物。

但只有總設計者才有否定與發展基本概念的權力。需要注意的一點是,即使是總設計師一直是同乙個人,他腦海中所認為理所當然的規則或者概念,很可能由於沒有明確的文件化,而沒有成為所有開發者共同的概念。在其他開發者編碼的時候,就可能會生成與概念相牴觸的東西,導致整體結構的惡化。這個時候總設計師一定要即時發現,做出更正。這就是外科手術式的開發隊伍。

團隊不是一擁而上,而是以外科手術方式來操刀。

打個比方就像乙個主治醫師操刀對問題進行分解,而其他成員提供各種支援。主導手術的碼農就這樣成長為傳奇中的人物。

想想此書成熟的年代,那些靠敲組合語言,在狹小的螢幕,紙帶儲存,小的可憐的記憶體完成複雜工作的前輩。

想想那些動輒就是議論重新設計語言,實現編譯器的前輩。而如今有了各種各樣的工具,如今的我們站在前輩們的肩膀上。

作者風淡雲輕的寫此書。堪稱舉重若輕。

現代程式設計師的軟硬體工具更加強大,有更多的樂趣,比以前更少的苦惱和麻煩。

實在應該珍惜。

讀《人月神話》

翻開扉頁,購書日期 2003.2.10。實在汗顏,且此類書,我的案頭還有許多。在兩周中抽出時間,翻看完了這本傳說中的經典。總的感覺,收穫並不多,雖說有些東西並未能完全理解,但大多在作者看來是未來的東西,已早成為現實。大致看來,沒有什麼新的概念。於是,也談不上讀後感,只是把看的過程中的筆記重新寫一遍,...

讀《人月神話》

為什麼中國的程式設計師總是在不斷學習新的開發工具 鑽研程式 而不能逐步提公升自己的視野 思維和經驗?摘自序 所謂人月 man month 是軟體開發中工作量的度量,然而它卻不是線性的,10個人10個月可以完成的工作,很多情況下100個人並不能在1個月完成。以下是我的理解與摘抄 斜體是摘抄 當人數增多...

2015 4 25 讀人月神話筆記

趁著這段時間還能抽出些時間,我對前一段時間在專案裡的經歷做了很大程度的思考,不得不說前端時間在專案組裡的猶如噩夢一般,詭異的後端架構 不穩定的 實現 緊張的專案進度以及不斷的需求變更都將開發推導了噩夢的邊緣。對比這些專案經歷,我重讀了人與神話這部描寫360os系統的建造者的經驗輯錄。比較令我震驚的一...