Humdrum Moli...

寒假終於把這本書看完了一遍... 
不能說是精讀

但在過程中仍是盡量保持頭腦能思考的情況下去看XD

所以其實看完對書中許多內容有很清楚的印象

這篇應該不能叫心得

應該比較像是我看完這本書的一些感覺跟想法～
---------------------------------------------
從進資工系以來 系上有需要寫程式作業的課程

都是要求我們要自己完成  抄襲他人的程式碼是大忌

主要是希望訓練我們獨立思考問題  在從無到有的實現出解決方法

也因為這樣的方式  我們很少有機會去與他人合作程式的撰寫（除了專題之外)

雖然說互相討論是非常好的方式  但大部分時候大家都考慮時間  面子等雜七雜八問題

大部分還是都是一個人悶著頭去寫

我在大二時還天真的認為程式設計師應該要具有一個人就要有製作出XP,office的能力...囧

後來才慢慢體會到這真是荒謬...軟體業需要的團隊合作 英雄照理來說是不存在的

就算再厲害的程式天才  製造的東西仍是有限  不是說製造出來的東西不好  而是很難能夠因應真正的實際情況

人月神話這本書主要是一位之前在IBM負責開發工作很猛的爺爺～XD

把他實際從事系統設計許多年所觀察到的現象和經驗整理成章節

來介紹說在軟體工程中常見的錯誤及理論

裡面提到的一些理論跟看法    有時讀來會讓我有

"啊～就是這樣～我也遇過" 之感

好比說在寫一個程式作業時

若能先將整體架構建立清楚

實際上coding的時間是占其中的一小部份

絕大多數時間是在debug上....囧

寧願在確定其中一部分的模組（函式）功能正確後

在繼續整合其他部份  而不要等全部模組都寫好後再作驗證除錯的部份

我們寫作業其實就是所謂大型軟體專案的縮影  步驟跟想法是一致的

而為什麼要有軟體工程？

這星期軟體工程的課堂上 教科書上的許多論點

其實比較偏向技術性  也就是以工程師的角度去看

好像說如何設計一個專案的model？ 有哪些方法？  這樣有什麼好處？

但其實在做這些事情    最重要的就是人

要完成一個大型的軟體專案或產品  一定需要人力來作設計,實現,驗證等工作

但許多擁有著不同想法  行為  思考模式的程式設計師 ,今天要合作一個專案或計畫

許多問題就會產生  最大的問題就是在溝通  俗話說"人多嘴雜"

n個人就會需要n(n-1)/2個溝通管道...要每個人達成共識（所謂共識還不一定是統一的)所花的時間成本

在加上整合所需的功夫   其實是非常難以估計的

所謂"人月"就是一般在做軟體專案時所用的人力單位    也就是一個人在一個月所付出的生產量

在一般的想法裡   越多人去作同一件事    所花時間應該越少

但在開發軟體的角度來說  其實反而會拖慢整個進度

因為還要考慮到菜鳥新手的訓練  人數增加後的工作分配重新規劃等等預料之外的事

這本書其實就是以"人"為出發點  考慮人對整個專案的影響因素

其中提出了不少方法  比如說進度文件的製作    開發方式的改變等等

我想這本書的骨幹精神就是在這裡   人多不代表事情做得快

其中有一個論點很吸引我

軟體發展不像物理  化學

因為這些大自然所發展出來的學問  都有一定的規律(書上是說  上帝的完美創作  阿們...)

所以人們能建立起一個穩定的基底模組  然後在這樣的基礎上去作發展    以簡御繁

但軟體是由人所發展出來  也就是說  沒有一個確定且規律的基礎模型 

所以其變異性及複雜度都是無法估計的   人類在軟體工程發展上

仍是現在一個艱難的情況（我想應該說是瓶頸）

其他一些比較零碎的觀念就不特別寫出來  但都非常實用

至於之前學長說要找好自己在一個system design中所扮演的角色

我目前其實還沒有一定的想法  能還要在磨練一段時間才能有所體會

這本書其實不錯    難怪是熱賣了20年的好書    資訊人都很適合看看^^