《人月神話》讀後感(三)

2022-08-12 04:30:20 字數 1924 閱讀 4979

一讀這一章,就讓我感觸頗深,特別是這句話"bell實驗室監控系統專案的提出,'關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方',細緻的功能定義,詳細的規格說明,規範話的功能描述說明以及這些方法的實施,大大減少了系統中必須查詢的bug數量"。雖然這句話的意思只是說明精確定義產品將減少bug的數量,但我看到了系統分析的最重要的工作——產品定義。現在,許多開發人員嘴裡口口聲聲說也做過需求調研、系統分析、系統設計,但大多數沒有涉及到產品定義的深度,嚴格意義上不能叫做系統分析。這句話對我的以後想從事系統分析工作有很大的幫助。

這章節說明使專案進度拖後的最大原因不是重要的事件,如新技術、重組等,而是一些瑣碎的小事,每件小事只耽誤半天或一天時間,但這種小事多以後,將使專案的進度嚴重拖後。

專案對於公司就如程式對測試工程師一樣,如果不了解它,它就是乙個黑盒子,如果不開啟這個黑盒子,你可能永遠不知道盒子裡面有什麼。這部分描寫專案經理以及小組主管的一些心理,值得一看。

本章說明程式的另一面——文件。

不了解,就無法真正擁有——歌德,作者引用的歌德的話來描述文件對客戶的重要性,提出客戶需要什麼樣的文件以及文件的格式和包含的內容,指出當時存在的大多數文件只描述了樹木,形容了樹葉,但沒有整個森林的圖案。

自文件化(self-documenting)的程式:提出文件與程式合為一體,能很好的解決文件與程式分開造成的文件過時的問題,並說明了在程式中加入文件的一些方法和技巧。xx年,我看到一位網友關於文件與程式合一的文章,當時就覺得是個好方法,沒想到70年代,老美已經提出來了。

這是一篇**,發表於2023年,我自認為我的理論水平沒有上公升到可以對他的論點和論據做出懷疑或質疑的結論,我只是說說我的感想。

人狼是傳說中的妖怪,只有銀彈才能殺死他。作者認為軟體專案具有人狼的特性,因為軟體專案也可能變成乙個怪物,乙個落後進度、超出預 算、存在大量缺陷的怪物。作者通過軟體系統的內在特性複雜性、一致性、可變性和不可見性來分析說明了軟體天生就沒有銀彈。

作者試圖通過分析軟體問題的本質和很多侯選銀彈的特徵來**其中的原因。他行動的第一步是將大塊的「巨無霸理論」替換成「微生物理論」。這個變化的過程告訴你,進步是逐步取得的,伴隨著辛勤的勞動,對規範化過程應

進行持續不懈的努力,而這個努力的過程相應的就誕生了軟體工程。作者對軟體工程誕生的原因做出這樣的解釋,我覺得符合外國思維的特點,這正是國人所缺乏。記得有一位朋友說過,中國媽媽與德國媽媽的區別,他說,如果手裡拿的針掉到地上了,中國媽媽的第一反應是估計針掉下去的範圍,然後在這個範圍裡面找,可能很快就找到了,也可能一直都找不到;但德國媽媽不同,她會拿一根粉筆來,把整個屋子畫成乙個大圈,接著把大圈分成許許多多的小圈,然後再到每個小圈裡找,雖然比較慢,但最終肯定可以找到。仔細想象,大多數情況下,中國媽媽都會找到得比較快,這確實符合大多數中國媽媽的思維習慣,每個中國媽媽都這樣找,這好象是與生俱來的本事,但為什麼德國媽媽沒有這個本事呢?是德國媽媽笨嗎?為什麼中國媽媽也有找不到的情況?而德國媽媽,雖然速度慢了點,卻始終能夠找得到?如果把這件故事推而廣之,多年以後,德國媽媽建立了找針工程,她通過多次找針的實驗資料,分析出針掉到整個房間中各個小圈的概率,總結出針在哪個小圈的概率最大,很快就可以找到針,找針速度早已高過中國媽媽,而中國媽媽還在依循與生俱來的本事。你能說德國媽媽笨嗎?為什麼中國媽媽和德國媽媽會有這麼大的區別?是德國媽媽把大塊的「巨無霸理論」替換成「微生物理論」嗎?我覺得是是,你說呢?作者在後面的論述中用數學和物理的發展為例子也說明了,這種思想的成立。

餘下的作者把軟體工程按「巨無霸理論」替換成「微生物理論」的過程詳細的說明,值得看,我關注的不是具體的內容,具體內容可能有些不合適宜,我關注的是作者的思考方式以及處理方法,這是非常重要的。

在「以往解決次要困難的一些突破」和「銀彈的希望」章節,從概念上講述了軟體的發展,其中講到「專家系統」時,使我想起一部科幻電影,忘了電影名字了,有個情節大致是這樣的,一位非常有經驗的主管死後,有一名較優秀的下屬接任,但這時出現了一位非常厲害的敵人,這位新主管無論如何也戰勝不了敵人,這時想起了以前的主管,心想前主管一定有辦法對付這個敵人,而前主管的大腦就存放在系統裡,  

人月神話讀後感(三)

軟體產品易於掌握的特性和不可見性,導致了它的構建人員 特別容易 面臨著永恆的需求變更 正如書中所說,做開發的人員必須要有面對任何變化的心理準備,要隨時有未雨綢繆的準備。提前預想到可能發生的變化才能在變化發生時更加從容的應對。做一些事總比期盼這件事是完美的不變化的要好得多。而且開發人員在後期的系統維護...

《人月神話》讀後感三

使用者的實際需要和使用者的感覺會隨著程式的構建 測試和使用發生變化。維護成本受使用者數目的嚴重影響,使用者越多,發現的錯誤也越多。使專案進度拖後的最大原因不是重要的事件,如新技術 重組等,而是一些瑣碎的小事,每件小事只耽誤半天或一天時間,但這種小事多以後,將使專案的進度嚴重拖後。專案對於公司就如程式...

《人月神話》讀後感

不同的社會經驗,不同的思想狀態,對讀本書的心得也不一樣,我在此說說我的讀後感,書中有許多非常好的觀點,但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書,每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...