人月神話讀後感三
人月神話閱讀筆記之三
之前從來沒有註重過文檔的重要性，想起啥就寫啥，從來沒有整理過思緒和想法就是想寫啥寫啥，不會在乎太多的問題。
但是看完這本書以後就明白了很多，這樣的做法是很錯誤的一種行為，作者強調文檔的重要性，他曾經很勤奮的向軟件工程師們講述文檔的必要性以及優秀文檔所具有的特點方面的講座。但是效果都非常的的不好，他們知道如何來寫出優秀的文檔，但是他們缺乏熱情。所以作者采用向馬車搬收銀機的方法向他們展示如何來完成這項工作。結果顯示這種方法的效果還是挺好的。
以後寫程序一定要先寫好文檔，要不自己就會在思緒煩亂的時候一頭霧水啥也不清楚，也是要用即時貼時刻的提醒自己
人月神話讀後感三
相關推薦
人月神話讀後感三
文檔 好的 重要 工程師 gpo 整理 pos div clas 人月神話閱讀筆記之三 之前從來沒有註重過文檔的重要性，想起啥就寫啥，從來沒有整理過思緒和想法就是想寫啥寫啥，不會在乎太多的問題。 但是看完這本書以後就明白了很多，這樣的做法是很錯誤的
《人月神話》讀後感
很難 軟件維護 樂趣 新的 標準 進一步 當我 模式 魔術 一開始聽到《人月神話》這個書名的時候，受到“神話”二字的影響，我以為這裏的“人月”是超乎正常認識的名詞，沒有想到，這裏的“人”還是那個人，這裏的“月”也還是那個月，而這本書，則是剝去神話外衣後對軟件工程更深刻的
《The Mythical Man-Month（人月神話）》讀後感（1）
臨近考試周，這裡我通過平時閱讀的《人月神話》十九個章節和知乎、簡書等網頁中網友們對《人月神話》的讀後感，對書中各個章節進行簡單的總結，以下均為個人手打觀點的思考與整合，僅供大家參考。 乍一看書名，人月
《The Mythical Man-Month（人月神話）》讀後感（2）
第10章 未雨綢繆 在化學領域中，在實驗室可以進行的反應過程，並不能在工廠中一步實現。一個被稱為“ 實驗性工廠（pilot planet）”的中間步驟是非常必要的，它會為提高產量和在缺乏保護的環境下運作提供寶貴經驗。軟體系統設計中也同樣有這方面的問題，若
人月神話之閱讀筆記三
認同 改變 成本 我們 它的 成功 科學技術 發展 無需 人月到底有多少神話色彩？很多年來，人們對軟件生產率和影響他的因素進行了大量的量化研究，特別是在項目人員配備和進度之間的平衡方面。 結果：第一次發布的成本最優進度時間，T=2.5（MM）^1/3。即，月單位的最優時間是
《人月神話》閱讀筆記（三）
現在 等待 不足 創建 我們 興趣 一句話 事物 般的 今天我閱讀了一部分《人月神話》，也是有一些感觸。 當閱讀到職業的樂趣這一節時有一句話：如果我們想解決問題，就必須試圖先去理解它職業的樂趣。而編程又何嘗不是呢，在編程中我們會遇到各種各樣的錯誤，越調試錯誤會越多
《人月神話》讀書筆記三
混淆 挑戰 重要 發的 必須 整體 認識 過程 設計 “概念完整性是系統設計中最重要的考慮因素”，但是如果設計團隊中的人很多，就很難統一。因此獲得設計概念的完整性，設計必須由一個人或者具有共識的小型團隊來完成，能夠更好地推進項目的時間進度。 采用“貴族專治”
《人月神話》讀後感其三——第二個系統問題
app 自身 總結 方式 das 開發者 位置 興趣 空間 ——難以控制的腦洞 在android編程的學習過程中，我一直在構思我的最終目標——記賬APP。 每學一部分我就會做一個練習用的App，功能簡單，重在練習，在此過程
人月神話第一章焦油坑
介質 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、小型、精幹的隊伍是最
《人月神話》代序篇感想-客戶需求滿足
可能 笑話 使用 昨天 人的 對象 道路 修改 要花 《人月神話》這本書入手已有些時日了，說來慚愧，一直沒有認真的閱讀過。近些時間晚上割接頻繁，等待操作窗口期翻了一下，感覺大有裨益。想認真讀完，又怕瑣事太多，故將每次的感想記錄：一來好記性不如爛筆頭，二來也是督促自己； 由本
人月神話之閱讀筆記01
工作內容 正在 pos 分析 功能 電子書 技能 感覺 最大的 今天應老師的要求看了電子書《人月神話》，感覺《人月神話》這本書真的很不錯，它並不是像《構建之法》那樣具體講有關軟件工程方面的知識，但它可以解惑作為一個程序員的煩惱和疑問。 這本書在序中講了我們
人月神話閱讀筆記05
一致性 世紀 計算 nbsp 不同 選擇 做的 規模 過去 概念一致性。 對於計算機系統而言，盡管沒有沒有花費幾個世紀的世紀來構建，但絕大多數系統體現出來的概念差異和不一致性非常大。這通常不是因為它由不同設計師門開發， 而是由於設計師被分成了由若幹人完成的若幹任務。概念完整
人月神話閱讀筆記01
做什麽 神話 時間 解決問題 做的 什麽事 解決 讓我 尋找 1.我過去是怎麽做的 在之前學習的時候，總是希望有較少較輕松方法去解決問題，懶得去尋找更有效的方法。而且學習時沒有合理的時間安排。在學習的過程中，而且缺少有效的溝通，合作不密切。 2.結合書中所講，說明為什麽不好