圖為紐約灣的tacoma橋由於空氣動力學上的錯誤設計而坍塌的新聞**。2023年11月7日中午時分，建成僅僅數月的tacoma橋坍塌，這是橋梁工程史上著名的悲劇。在做專案設計和規劃時，一定要考慮到各種不確定的變化因素，靈活適應多變的環境，否則很可能釀成悲劇後果。
不變只是願望，變化才是永恆。
對於大多數專案，第乙個開發的系統並不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之；
系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟；
為捨棄而計畫，無論如何，你一定要這樣做；
變化是與生俱來的，不是不合時宜和令人生厭的異常情況；
開發人員交付的是使用者滿意程度，而不僅僅是有形的產品；
使用者的實際需要和使用者感覺會隨著程式的構建、測試和使用而變化；
軟體產品易於掌握的特性和不可見性，導致它的構建人員面臨永恆的需求變更；
目標上的一些變化無可避免，事先為它們做準備總比假設它們不會出現要好得多；
最重要的措施是使用高階語言和自文件技術，以減少變更引起的錯誤；
變更的階段化是一種必要的技術。每個產品應該有數字版本號，每個版本都應該有自己的日程表和凍結日期，在此之後的變更屬於下乙個版本的範疇；
現在軟體程式設計小組失敗的主要原因是管理控制的太少，而不是太多；
不願意為設計書寫文件的原因，不僅僅是由於惰性或時間壓力。相反，設計人員通常不願意提交嘗試性的設計決策，再為它們進行辯解；
為變更組建團隊比為變更進行設計更加困難；
只要管理人員和技術人才的天賦允許，老闆必須對他們的能力培養給予極大的關注，使管理人員和技術人才具有互換性；
專案目標、進展和管理問題必須在高階人員整體中得到共享；
在程式發布給顧客使用之後，並不會停止變化。發布後的變更被稱為「程式維護」；
軟體維護主要包含對設計缺陷的修復，通常包含了更多的新增功能，它通常是使用者能察覺的；
對於乙個廣泛使用的程式，其維護總成本通常是開發成本的40%或更多；
缺陷修復總會以固定（20%—50%）的機率引入新的bug。所以，整個過程是前進兩步，後退一步；
每次修復之後，必須重新執行先前所有的測試用例；
使用能消除或至少能指明***的程式設計方法，會在維護成本上有很大的回報；
設計實現的人員越少、介面越少，產生的錯誤也就越少；
模組總數量隨版本號的增加呈線性增長，但是受到影響的模組數量隨版本號的增加呈指數增長；
系統軟體開發是減少混亂度的過程，所以它本身是處於亞穩態的。軟體維護是提高混亂度的過程；
人月神話（11）未雨綢繆
思維導圖 試驗性工廠和增大規模 唯一不變的就是變化本身 為變更設計系統 如何設計變更系統 變更的階段化是一種必要的技術，每個產品都是應該有數字版本號，每個版本都應該有自己的日程表和凍結時間，在此以後的變更屬於下乙個版本的範疇 為變更計畫組織架構 設計人員不願意為設計書寫文件化的原因 如何設計變更計畫...
《人月神話》筆記 未雨綢繆
本章談及 軟體的變更 維護 開始，作者寫道 對於大多數專案，第乙個開發的系統並不好用。要解決所有的問題，除了重新開始之外，沒有其他的辦法 即開發乙個更靈巧或者更好的系統。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟。而且，新的系統概念或新技術會不...
《人月神話》讀書筆記
p8,程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。p19,用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。因為它暗示人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況 某個任務可以分解參與人員，並且他們之間不需要相互交流。p23,...