Java課程寒假之《人月神話》有感之二
一.外科手術隊伍
即建立一個合理的團隊，按照書上的說法就是，在開發一個大的系統的時候，原本精英的團隊就可能無法在較短的時間內完成一個大型的程序，在這樣的條件下，必須擴大團隊的規模，即使這個精英程序員的效率要比這些平庸的要高一個數量級，但是依舊扛不住系統規模的龐大。即使能夠完成，時間成本會相當的大，設計好了之後也會因為時間的原因導致系統不再先進流行，最終導致的還是失敗。
Mills 的建議：大型項目的每一個部分由一個團隊解決，但是該隊伍以類似外科手術的方式組建，的確對於系統的完成，分工必不可免，就像機器生產的流水線，但是對於程序員之間又不像流水線之間的那樣簡單的關系，需要不停的溝通協調，每個團隊相當於開發隊伍的一個成員，在團隊中對其職能在進行一個分配。
Java課程寒假之《人月神話》有感之二
相關推薦
Java課程寒假之《人月神話》有感之一
下意識 情況 直線 當我 無法 ava 使用 理解 需要 一.焦油坑 以前上課的時候，老師講過早期的程序由於工作量不大，大多只需要幾個人完成，隨著軟件規模的不斷擴大，代碼量直線上升，僅僅一兩個人可能沒有辦法完成這樣的任務，多以開始形成了團隊的規模，焦油坑說的是在完成代碼
Java課程寒假之《人月神話》有感之二
ima 大型項目 alt 解決 每一個 系統 協調 也會 流行 一.外科手術隊伍 即建立一個合理的團隊，按照書上的說法就是，在開發一個大的系統的時候，原本精英的團隊就可能無法在較短的時間內完成一個大型的程序，在這樣的條件下，必須擴大團隊的規模，即使這個精英程序員的效率要
人月神話之閱讀筆記01
工作內容 正在 pos 分析 功能 電子書 技能 感覺 最大的 今天應老師的要求看了電子書《人月神話》，感覺《人月神話》這本書真的很不錯，它並不是像《構建之法》那樣具體講有關軟件工程方面的知識，但它可以解惑作為一個程序員的煩惱和疑問。 這本書在序中講了我們
《人月神話》讀書筆記之四
未雨綢繆 預警 維護 align 規範 ont class 繼續 宋體 本周繼續閱讀《人月神話》，本周度過的部分是第十章和第十一章（“提綱挈領”和“未雨綢繆”），以下是對該兩章的感想。 一、提綱挈領 提綱挈領一章描述的是經理與文件的關系。作者一開始便給文件做了定性：文檔的某
經歷一次方知書中千百蘊意 ——讀《人月神話》有感
個人 不必要 困難 純粹 滿足 我想 毫無 解決 實踐 “讀萬卷書，不如行萬裏路”，每一本書都凝結了作者或者前人的心血與智慧的結晶，當我們作為一名後輩去欣賞與學習的時候，我們是否能真正的體會到前輩在當時的那種心情與想法？我們是否可以真正的理解書中的每一個字與詞語所
讀《人月神話》有感
由於有一些重要的事情，我最近好久沒在CSDN上面寫博文了。最近，終於忙完了那個重要的事情，中間抓住了幾天的空閒時間，得以靜下心來認認真真的讀了Frederick P.Brooks. Jr.的《人月神話》，封面如下： 這是一本很經典的書，在我9年前讀碩士研究生的時候即已知道。3,4
人月神話之閱讀筆記三
認同 改變 成本 我們 它的 成功 科學技術 發展 無需 人月到底有多少神話色彩？很多年來，人們對軟件生產率和影響他的因素進行了大量的量化研究，特別是在項目人員配備和進度之間的平衡方面。 結果：第一次發布的成本最優進度時間，T=2.5（MM）^1/3。即，月單位的最優時間是
人月神話之閱讀筆記二
需要 隱藏 設計缺陷 足夠 更多 用例 內容 問題 使用 以後我們做項目，一個純粹完整的項目的先決條件？他們是否有1、清晰的目標 2、人力 3、材料 4、足夠的時間 5、足夠的技術 那麽，既然已經具備了所有的這些條件，為什麽項目還會失敗呢？他們還缺乏些什麽？兩個方面
Java課程寒假之開發記賬本軟件（網頁版）之一
進行 功能 簡潔 info 技術 基礎功 網絡 查詢 導航 一.制定網頁版記賬本的基礎功能 首先是下載了幾個記賬本APP，大致地看了一下記賬本的功能：添加記錄（支出，收入，自定義模板），查詢流水（分類查詢），賬戶。 二.開始做出框架 鑒於記賬本有上面的功能，所以在網
寒假讀書筆記1（人月神話）
平臺 十分 技術 轉換 ont 並不是 計算機 人的 最好 書中給出了一些概念與現下創造性的軟件及項目都由小組織完成，並且解釋了一些程序員的脾性。程序是追求完美的工作，而這種技術活需要多與藝術才能夠達至工程完美之上的精致。 1、所有的編程人員都是樂觀主義者。可能是這種現代魔
Java課程寒假之開發記賬本軟件（網頁版）之四
會有 誤刪 其他 消費 這不 這一 問題 網頁版 新建 一.實現基礎功能之一（刪除） 在刪除的功能實現之前，要明白刪除的條件是什麽，一開始我是以去向和時間作為條件刪除，但是刪除的語句好像有問題，好像是因為出現了非法字符（應該是中文吧，不太清楚，因為這不是我最後的方向），
人月神話第一章焦油坑
介質 alt 系統 mage ima wid 人的 -1 其他 職業的樂趣： 不斷學習的樂趣 創建事物的樂趣 開發對他人有用的東西 在易於駕馭的介質上，進行開發 職業的苦惱： 將做事的方式往完美的方向調整。 往小的說：1.依賴其他人的代碼 2. 當產品終於出來時，已經
《人月神話》閱讀筆記02
習慣 方式 人月神話 開發 挫折 單位 吸引 神話 依賴 第二章 人月神話 這一章主要講述了樂觀主義、人月、系統測試、空泛的估算、重復產生的進度災難。 所有的編程人員都是樂觀主義者。可能是這種現代魔術特別吸引那些相信美滿結局的人；也可能是成百上千瑣
《人月神話》閱讀筆記06
使用 測試 理由 修改 技術 大會 以及 例子 傳遞參數 第六章 貫徹執行 這一章主要講述了文檔化的規格說明——手冊、形式化定義、直接整合、會議和大會、多重實現、電話日誌、產品測試。 手冊、或者書面規格說明，是一個非常必要的工具，盡管光有文檔是不夠
《人月神話》閱讀筆記04
計算機 存在 時代 改變 筆記 易用性 編程開發 不同 用戶 第四章 貴族專制、民主政治和系統設計 這一章主要講述了概念一致性、獲得概念的完整性、貴族專治統治和民主政治、在等待時實現人員應該做什麽。 絕大多數歐洲的大教堂中，由不同時代、不同建築師所
《人月神話》閱讀筆記05
後者 估計 建議 str 準備 裝飾 好的 似的 結構 第五章 畫蛇添足 這一章主要講述了結構師的交互準則和機制、自律——開發第二個系統所帶來的後果。 建築行業的結構設計師使用估算技術來編制預算，該估算技術會由後續的承包商報價來驗證和修正。承包商的報
人月神話閱讀筆記3
學習編程 進行 調整 提高 快樂 方向 防止 來源 困難 我需要逐漸培養自己的編程興趣，還有就是需要增強自己的自控力，防止編程時候貪玩。 編程的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且喚醒了每個人內心的情感。我始終喜歡著我們這個行業。 學習編程最困
人月神話-13章整體部分
設計 集成 實施 系統 系統集成 單元 量子 數量 一次 剔除Bug的設計 細致的功能定義、仔細的規格說明、規範化的功能描述說明以及這些方法的實施，大大減少了系統中必須查找的bug數量。 測試規格說明 自上而下的設計。 結構化編程 構件單元調試 系統集成調試
人月神話--摘點
項目 混淆 內容 又是 關於 完成 決定 漸進 目的 核心：概念的完整性 1、缺乏合理的時間進度是造成項目滯後的最主要原因，他比其他的所有因素的綜總和影響都大 2、關於進度安排，作者的建議：1/3計劃、1/6 編碼、1/4構件測試以及1/4系統測試 3、小型、精幹的隊伍是最
《人月神話》代序篇感想-客戶需求滿足
可能 笑話 使用 昨天 人的 對象 道路 修改 要花 《人月神話》這本書入手已有些時日了，說來慚愧，一直沒有認真的閱讀過。近些時間晚上割接頻繁，等待操作窗口期翻了一下，感覺大有裨益。想認真讀完，又怕瑣事太多，故將每次的感想記錄：一來好記性不如爛筆頭，二來也是督促自己； 由本