管理員組

文章數量:

人月神話讀后感

首先人月神話中有許多內容，有些可能只有參與過大項目的人員才能真實感受到，因此我主要根據人月神話、沒有銀彈等幾個小部分談談自己的看法

人月神話：

1、程序員不應該樂觀主義

本章解釋了為什么進度落后的項目通過增加人手也不能加快進度，總結就是不可避免的培訓時間，且會打亂原有人員的進度（用于與新進人員進行溝通）。

但小型團隊在減少溝通上的高效性在開發大的項目時無法套用（因此考慮該因素的影響在大型項目開發中無法回避）。

提出了外科手術式的模式：主刀醫生實際操作，剩余團隊為其提供支撐。一個人負責一件完整的事情，減小了交流的損耗，其他人為其提供支撐。個人理解：有一個最高級的編程人員負責所有代碼的整合，他對需求及架構最了解，由他向所有其它人員發布任務并要求對應的接口，由他將所有的模塊代碼整合起來，其它人的水平不需要太高，能根據需求完成對應代碼的編寫即可。

總結就是：之所以人月不能等乘積交換，是存在新增人手的培訓，即使一開始定許多人參與工作，溝通上又會存在損耗。有意思的問題是在這種情況下人月的定義是怎么來的？有點馬后炮的感覺，因為沒法估計準，除非有先驗的經驗，而且經驗還只對工作量接近，參與人員數量接近的情況下有效。

沒有銀彈：

書中指出：解決管理災難的第一步是將大塊的“巨無霸理論”替換成“微生物理論”，不要指望有一個體系或者語言的誕生能解決所有的問題，這與軟件的內在屬性相違背。

硬件的發展過快，能實現流水線作業大大提高生產效率，個人觀點：目前軟件開源利用率還不夠。還不能規模化根據需求產生代碼，是需求不夠細化還是？感覺這里的硬件是拿芯片舉例，這樣的話軟件不應該由不同軟件作為代表，而是更為基礎的操作系統、開發環境作為代表，即其它軟件產品的開發基于這個基礎的軟件，這樣看，基礎的軟件也具有較高的生產效率。

個人疑問：復雜度為什么是軟件的固有屬性？如果封裝庫足夠多，也都經過了測試，僅僅是這些庫的組合所帶來的問題也會很復雜嗎？還是說沒有專門的學科研究這樣帶來的問題及難點，因此像所謂軟件工程史前時期一樣，軟件開發像小作坊一樣問題重重。

“由于復雜度，列舉和理解所有可能的狀態十分困難，影響了產品的可靠性”，感覺類似機器學習中分類的問題？人能對學習過的事例舉一反三，即使只滿足部分屬性，但這也導致人的判斷并非一定是正確的，說明所謂“知識就是忘掉所有在學校學的東西剩下的”，人類擅長記憶的不是具體的例子以及規范，而是將其抽象、模糊后的屬性，從而具有拓展性和易錯性。讓人從事編程并企圖讓完成代碼沒有錯誤，這與人模糊的認識世界的本質也相違背（用魔法打敗魔法）。

從這個角度我反而認為不是軟件本身的復雜性而是編程人員對實際世界的理解不夠，當他不能想到有某種可能的時候，當然無法在初始編程的時候想到對其的處理。但不悲觀的看，人都有試錯成長的過程，一些所謂的不能提前預料到的狀況能否根據以及發生的錯誤估計的事故案例引申出可能的問題呢？畢竟引申創新才是人優于機器的地方。