殺不死的人狼 我讀《人月神話》(一)

2021-04-13 14:25:52 字數 2873 閱讀 5761

2023年03月12日 03:08:00

=====

前言

=====

marktsen

這樣的速食者,試圖幾句話就打發了自己或者讀者那漉漉的飢腸。

閱讀這些文字給我帶來的收穫是:面對《人月神話》,除了表示五體投地的誠服,你既不能做正面言論(那是多餘),也不能做負面言論(那是找事)。

這是一本可怕的書。

我大概花了三周的時間來細讀這本書--也許很多人會說我應該花更多的時候或者讀更多遍--不過,這不是重點。我在書中印證和找尋思想,並為這本書寫下了數百個注釋。最終我很遺憾我讀了電子版本,因而注釋被寫在了文件中而不是書頁上。如果不是這樣,我將沒有任何方法扼制自己購買這本書的衝動。

下面的文字分成兩個主要的部分。一部分是如何讀這本書,如果你已經讀得很好,那可以跳過去,這是留給別人的。另一部分,則是討論那個著名的命題:沒有銀彈--似乎,不討論這個命題的話,連感想都不成其為感想,淪為空談了。

=====

一、《人月神話》的結構及其與組織

=====

我對《人月神話》的內容結構做了一些分析,大概如下:

內容說明

問題域

1

說明"程式

(program)

"不是"產品

(prodouct)

",更不是"專案

(project)"。

說明程式設計師的心理與情緒因素--這是很重要的乙個話題。

2

專案的發起、評審與預估(錯誤的設定專案週期是最大的錯誤)。

"人月問題":週期不因為人力投入而變短,事實上它可能更糟糕。

專案定義

3

十個人與幾百人面臨的問題是不同的。

團隊建設

4~5

從設計階段開始,即致力於獲得和維護概念的完整性。

團隊管理

- 方向與決策

6

專案過程中的一般性方法。

團隊管理

- 一般性方法

7

專案組織過程中的溝通問題。

團隊管理

- 溝通問題

8~10

編碼過程中的關鍵問題:

-專案複雜程度與需要編碼的資料呈指數級關係,反過來,減少編碼可降低系統複雜性

-資料的表現形式是程式設計的根本

-文件是必須且重要的,但往往不被關注(主要強調重要性) 編碼

11

承認變更,承認從需求和設計期就開始的變化。

為應付變化而實現的原型系統。

專案定義

- 需求不確定

12

工具帶來效能。

13

強調測試,以提公升品質和保障專案目標。

專案管理

- 檢測/回顧

14

專案控制:進度與里程碑

專案管理

- 控制

15

文件:專案過程文件,包括定義、設計與實現(主要強調方法)

專案管理

- 文件化

16,17

沒有銀彈、再論沒有銀彈

18,19

前十五章的回顧(不包括"銀彈"的話題)

20

二十年後對上述命題的回顧(包括對銀彈現象的進一步解釋) 正如

brooks

說到的,在幾十年之後的今天,這本書裡的現象或者觀點已經為整個行業所認知--無論是從實踐中的感受,還是從類似《人月神話》這樣的書籍中去獲知。其中大多數命題與結論,都在這幾十年的開發實施中被印證過,所以它們(我指的是這些命題與結論)備受關注。

我只重述

brooks

所講述到的兩點。我重述它們的原因,是認為它們還被關注得不夠:通過設計來獲得系統的一致性,以及更好的文件。 在

brooks

的討論中,不但要"獲得"系統的一致性,還是盡力去保障它。

brooks

認為"獲得和保障"它的角色是並不是同乙個人:前者是結構師(第3~

4章所論),後者是專案經理(第

5章所論)。對於這兩個角色(或相似的角色),在第

7章"大型程式設計專案的組織架構"中,

brooks

提出:要麼產品負責人任總指揮,技術主管充當其左右手;或者反之。

brooks

認為前者更適於大型專案,後者更適於(相對)小型的專案。

在人月神話中對這兩個角色的用詞與我們現在(至少是翻譯過來的)用詞略有點不一致。事實上書中的產品負責人相當於現在的專案經理,而技術主管相當於技術經理(至少參與系統設計或直接由架構師擔任)。

brooks

並沒有低估(或錯誤認識)系統一致性和文件的重要性。但除了這兩點未被足夠重視之外,我想前十五章的內容不必再複述了。如果你不能理解我為什麼不再複述,那可能你需要更多的工程經驗或者理論基礎。除非你決心認為大師的一切都必須被象聖經一樣地重述,但那只是你個人的信仰,或者喜好。

下一節==<<

殺不死的人狼 我讀《人月神話》

marktsen 這樣的速食者,試圖幾句話就打發了自己或者讀者那漉漉的飢腸。閱讀這些文字給我帶來的收穫是 面對 人月神話 除了表示五體投地的誠服,你既不能做正面言論 那是多餘 也不能做負面言論 那是找事 這是一本可怕的書。我大概花了三周的時間來細讀這本書 也許很多人會說我應該花更多的時候或者讀更多遍...

讀《人月神話》

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

讀《人月神話》

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