01人月神話閱讀筆記之一
1.我之前在編寫程式的時候，通常都是把**全部寫完再執行自己的程式，看自己設計的程式有哪些功能，但是這樣特別枯燥，寫著寫著就不知道自己寫到**了，而且容易疲倦，就是寫了很久發現自己並沒有多大成就，有好幾次就不想敲**了。1.這一年多吧，說實話，我的大部分程式的設計和**的完成都是走一步看一步，從來沒有說是提前規劃好的，然後就經常懵圈，不知道自己的程式能完成到什麼地步。
2.然後我看到了書中的增量式開發，這種開發最大的好處就是讓程式設計師能夠在每個階段都有個可以執行的程式，這樣開發人員每個階段都有成就感，不會感到枯燥，而且每段程式都可以使用，這樣方便對特定的一段程式或者功能進行修改。而且《人月神話》這本書中說到了保持設計的概念完整，無論是小軟體還是大軟體，參與設計的人數不能太多，作為乙個軟體乙個系統，必須有乙個清晰明確的概念模型，大家都在這個框架下工作，所有的創新發展都必須與基本的概念相吻合，具體的實現人員可以細化，像第一條所說大家都是一盤散沙的進行，終究很難達到自己團隊想要的目標。
3.我覺得這種方法是好的，也就是每次把自己的程式**，具體到某乙個功能，完成它，然後執行出來，可以增加自己的成就感，而且不會感到枯燥，還有利於提高**完成的進度。我寫簡單四則運算的時候就是這樣寫的，很大程度上讓我不再感到敲**無聊了。還有就是不論是個人還是團隊設計軟體的時候，都需要首先由乙個清晰明確的概念模型，大家按照者這個既定方向去完成自己的程式，或者說總設計師是乙個人，然後下面的小功能具體分工，層層控制，共同完成軟體的實現。
人月神話閱讀筆記之一
程式，它本身是完整的，可以由作者在所開發的系統平台上執行。它通常是車庫中產出的產品，以及作為單個程式設計師生產率的評估標準。有兩種途徑可以使程式轉變成更有用的，但是成本更高的東西，它們表現為圖中的邊界。水平邊界以下，程式變成程式設計產品 programming product 這是可以被任何人執行 ...
人月神話閱讀筆記之一
原來我以為在做工作的時候，存在一些技術可以解決任何問題，所以當遇到問題時，總是期望可以找到這樣的方法。在軟體開發的過程中，只有適度改進，沒有包治百病的銀彈。為了對付恐怖傳說中月圓變形的人狼，只有銀彈才能夠消滅它，而軟體專案具有人狼的某些特性，看似簡單明瞭的東西，卻可能變成乙個落後進度 超出預算 存在...
人月神話閱讀筆記之一
課堂上老師讓選書的時候，人月神話 這個獨特的名字還是吸引到我了，所以我選擇了這本書。人月神話 這本書的評價還是很高的，畢竟是一本經過了40多年仍然經久不衰的書。和構建之法不同的是，人月神話 沒有對那些軟體開發的過程和方法做過多的介紹，而是將重點放在了軟體工程的管理問題。人月神話 的第一章講的是焦油坑...