- 相關推薦
人月神話讀后感
人月神話讀后感
當我捧起《人月神話》，馬上就被深深的吸引了。書中很多細微之處都對我的思維造成了沖擊。上一本給我類似感覺的書是那本四人幫的《設計模式》，已經很久沒有看到這么好的書了，鄭重推薦。
把感觸比較深的幾點記下來，順便整理一下自己的思路，與大家分享。
1，保持設計的概念完整。無論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。作為一個軟件，一個系統(tǒng)，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創(chuàng)新發(fā)展都必須與基本的概念相吻合。具體的實現(xiàn)人員可以細化概念，但只有總設計者才有否定與發(fā)展基本概念的權力。需要注意的一點是，即使是總設計師一直是同一個人，他腦海中所認為理所當然的規(guī)則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。在其他開發(fā)者編碼的時候，就可能會生成與概念相抵觸的東東（模塊，功能，算法），導致整體結構的惡化。這個時候總設計師一定要即時發(fā)現(xiàn)，做出更正。
概念的完整性，對于很多小規(guī)模軟件，由于開發(fā)人員不多，開發(fā)經理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以后的Bug修改，功能擴展的時候，也要時刻留意與最初的設計是否概念上相容。對于大規(guī)模的軟件系統(tǒng)，則必須通過樹狀組織結構，層層控制，總設計師還是一到兩人，每一層都有對下層的絕對把握能力。我以前參加過一個15人左右的項目組，就是分為兩層。感覺整體概念完整性的控制效果還不錯。我沒有更多人數(shù)項目的具體實踐經驗，希望以后能有機會參與比較大的項目。
2，“一個拿2倍工資的人，生產率可能是其他人的10倍。”我和我的同學，一個小公司的技術總監(jiān)聊起這個，他也是十分的認同。不知道其他公司的程序員們如何看。我的同事中有一個牛人，做出的貢獻特別大，應該相當于我們公司普通的十個程序員，不過工資最多也就是普通程序員的二倍。是不是有些不公平呢？我也說不清楚。因為那些普通程序員也十分的努力。不過，我覺得，作為公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。
組建一個團隊，最好的就是那種精英團隊，大家都是牛人，效率會特別高。微軟就是這種思路吧，把最聰明的人集中在一起，想不成功都難亞。
3，進度落后與增加人力。記得當年看《C＋＋編程思想》，Bruce說“十個婦女不能在一個月內生下小孩”（大意），于我心有戚戚焉。而本書作者Brooks得出的結論是對我是震撼性的：“向進度落后的項目中增加人手，只會使進度更加落后”。(m.clearvueentertainment.com)
以前，增加人手基本是挽救進度落后項目的主要辦法。這個辦法行不通的話，難道只有“加班”一條路了？但長期加班是對個人的摧殘，我更愿意利用業(yè)余時間去看書，例如看這本“人月神話”。）
如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么……唯一的方法還是只有…加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設計有不同意見（特別是加入的人中有比較強大的設計者）。那么，就當作，新組建了一個團隊吧。交流，培訓新人，就設計達成一致，繼續(xù)向者目標前進。
感觸還有很多，以后如果有機會再寫。不過，我決定去買本英文版回來，收藏，以后再多看幾次。
【人月神話讀后感】相關文章：
仙山的神話故事08-24
讀懂學生總裁的神話08-07
炎帝的神話故事06-27
杞人憂天的神話故事10-25
神話故事：寶蓮燈07-21
神話傳說故事07-29
道教神話故事09-29
童話神話寓言的區(qū)別09-01
孟姜女的神話故事07-24
《神話少年》讀后感10-25