人月神話裡有些經驗不能一味地套入現行情況, 但不代表這些經驗已不適用,
要思考作者的處境和背後的理由, 我認為思索這些,
並與現在的環境分析比較, 會有不錯的體悟



ch5
2nd-system effect
第一個設計總是慎重而簡單的, 第二個系統卻很糟, 容易overdesign

可能犯的錯誤:
    和現有系統基本假設不符, 卻想延用經驗
    當時的技術已過時, 在第二個系統裡應該引進新的技術

	[NOTE]
	我在寫php時, 很喜歡套用過去經驗(因為我不熟php, 想省工),
	犯了許多次2nd-system effect,
	最後我把討論區刪了, 在php裡減少一些include(),
	以避免我犯更大的錯誤
	(那個討論區用了3次, 但它卻是我一次寫php硬趕弄出來的劣質品)

ch6
1.
手冊由架構設計師寫, 架構設計師要提供一種實作方式,
而不是特定的實作方式

	[NOTE]
	雖然沒有明說, 這表示架構設計師也要懂得實作

	手冊的用途是詳細告知規範和未規範的內容
	( ex: 傳遞C的函式參數, 在執行上的順序是未定義的, 不可依懶它 )

2.
正式定義並帶有散文定義的解釋文件是最理想的, 兩者要並存,
並且以其中一者為主, 以免解釋衝突造成混亂

	[NOTE]
	原本我覺得有個正式定義, 再加解釋實在很蠢, 為何不一次解釋清楚,
	搞一堆專有名詞自找麻煩

	而作者的意思是, 兩者都有存在的必要,
	並舉出正式定義的優點, 精確, 具週延性, 但不易看懂

3.
要有獨立測試的小組

ch7
人力配置和專業分工是減少溝通的方法,
權力和責任造成樹狀組織, 但溝通是網狀的, 兩者衝突

視人力調配組織, 而非由人去配合純屬理論的組織

ch8
討論和評估程式產值的數據
( 沒有概念, 這種評估有準確度嗎? )

ch9
省空間的一些技巧 (現在沒有必要了)
各小組的開發往往造就局部最佳化, 忽略整體最佳化 ( 惡性競爭 )

	[NOTE]
	早期MicroSoft內部就是如此? Windows 3.1跨到NT是很艱辛浪費資源的過程, 
	而Office強調Word和Excel的互通原件則是正面的例子

ch10
管理員要把目標和其它重大事項寫下, 別預期講過一次後,
大家都會懂, 即是你認為那是非常簡單的事

ch11
丟掉重作是必然的, 不用擔心是否要作試作品,
設個底限, 坦然面對改變, 愈接近完成, 底限愈嚴格, 否則不可能完成

	[NOTE]
	我和別人合作時, 總是為了要不要先作個prototype(試作品),
	再重作而爭論許久, 因為prototype會占時間, 若可以一次作好最省事

	作者以他豐富的經驗點破這簡單的道理, 其實大家都知道,
	就作吧, 不成功就當它是試作品, 再重來吧

ch12
每個團隊都應該有個工具專家,
個人專用工具會阻礙溝通, 軟體工具統一開發和維護較有效率,
個人特殊需求可以向工具專家請教

如同觀察星象要在晚上, 天亮前進行除錯是最好的,
雖然沒有理論站得住腳, 但作者的經驗顯示, 一大早起來除錯是很有效率的
( ????????????????????????????????????????????????????????????）

ch13
top-down design is good.
一次整合一個組件
版本控管很重要

反對非常少而頻繁的改版, 這會造成混亂

	[NOTE]
	版本的演進意謂整體測試, 測試的成本很高,
	在制定時程時, 要把改版的整體重測列入

	在XP的前提下, 測試的成本很小, 簡言之

	    +>  最小需求 -> 實作 -> 自動化測試 -> 重整 -+
	    |                                           |
	    +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+

	換句話說, 當測試成本不能最小化時, XP的作法可能不適用,
	比方目標平台不是PC, 團隊只能拿到少數幾台,
	或是測試動作極為費時, 可能編譯和執行都要很多時間, 
	雖然這在現今不太可能發生

ch14
milestone是具體100%完成的事件 (非80%完成, 90% no bug這類模稜兩可的描述)
靠經驗事先評估加入時程

不是每個誕誤都要緊張地處理, 如何找出該關心的延誤?
PERT chart, critical-path schedule是無可取代的工具
( 它們是什麼啊...??????????? )

2個該讓老闆知道的訊息, 別動不動就煩他
    意外狀況
    計畫執行現況

大型專案最好設立一個 1~3 人的計畫監控小組, 這樣老闆才能完全專心在決策

ch15
流程圖是不必要的, 若需要, 一頁已足夠
( 指程式邏輯細部的flowchar, 整體架構用適當的圖表會易於討論 )

文件盡可能放在同一份, 寫在程式裡最理想, 稱為self-document
( javadoc is good!! )

另外寫文件配上流程圖很蠢
    軟體文件通常寫得很爛
    維護麻煩, 程式的修改往往不會立反應在文件裡

[ to be continued ]