敏捷開發修煉之道讀書筆記1

2022-09-18 13:00:14 字數 2531 閱讀 4570

1做事放在第一位,不是指責犯錯誤的人。不抱怨,承認錯誤,團隊合作,學習進步。懂得丟棄,

2欲速則不達,不能孤立,**審核,單元測試,

3持續學習,跟蹤變化,增量學習,了解動向,建設學習型團隊,小步進步持續才是敏捷,丟棄原有知識和存量,用建議的開發環境開發一門語言的專案,多問為什麼且問在點子上,問前問自己;有計畫不隨意,有節奏的碼**,一天幾個時間段的提交,不要讓天打斷在進行中的事情。有節奏的開會,提前暴露問題,且像遊戲一樣一點點的成功激勵。

4客戶做決定,設計指導而不操縱開發,提早和頻繁的整合**,保持可發布。自動化部署,頻繁演示反饋,增量部署,設計不要太詳細,

crc類,職責,協作,——要用簡單的工具盡快做類關係圖的設計。

技術引入:為解決什麼問題,可取消性,成本。

技術是工具而不是工作。

保持可發布:資料庫,介面等提供多版本控制,實在不行就做分枝。

自動化部署,簡單可靠的可重複。檢查環境依賴,不能隨意刪除原有使用者配置,帶解除安裝,

演示和反饋的週期一周到兩周,但也要尊重客戶時間。讓客戶感覺到他們能在一定程度上控制專案的方向。演示的目的是反饋,不是故意暴露專案的缺陷

迭代是短期迅速的,使用者更希望現在有乙個能工作的不完美軟體,而不是一年後的完美軟體。短迭代帶來專注和效率。

估價,短迭代,第乙個週期後**,此時你把握難易,客戶可控方向。

5,敏捷反饋 編寫能產生反饋的**,自動化單元測試,每次編譯執行測試,測試不通過,等同編譯不通過,測試可重複,測試邊界。

tdd測試驅動開發,先用再實現,以使用者角度開發,考慮怎麼用,注重實效。有具體理由再編碼,專注於介面。

成功的實現特定功能的最低版本。

構建乙個持續整合的自動化部署系統,**每次提交都自動部署測試,這樣立即就會發郵件通知提交者是否通過。

自動驗收測試,平面化的資料檔案,

度量剩下的工作量,用時間做單位。

傾聽使用者,分析他們的問題,改系統。

6敏捷編碼,**盡量簡潔,自說明,清晰不討巧,**被閱讀次數遠高於編寫修改次數。

dry原則,不重複自己,

注釋,說明方法行為 意圖 期待結果 要注意的地方。

類的方法的注釋:目的(為啥需要),需求(前置條件,要輸入和當時物件狀態),承諾(輸出和物件狀態),異常。

重寫方法時要保留原有的意圖和約束。

動態評估取捨: 效能,便利,成本,上市時間,平衡考慮,沒有最優方案

增量的開發,更產生小方法和內聚的類,持續測試開發。簡單**簡單設計,以簡潔為榮。以內聚為榮,功能職責單一,可修改的因素單一,

告知,不詢問: 命令與查詢相分離模式,內聚。封裝 錢包的故事。

告訴物件或元件你要做什麼,然後等待他給你結果。訊息傳遞概念,而不是呼叫函式。查詢絕不能改狀態。

is a使用繼承,has a和 uses a 使用委託。 使用繼承時考慮能否替換,不能則該使用聚合,類中包括乙個其他類的例項物件,將責任(工作)委託給該物件完成。並且以後可方便替換該物件,因為它對外不可見,靈活擴充套件。

警告 就是錯誤,乙個變數未使用時可能是其他變數被錯誤使用了。警告是定時炸彈,讓**不可**,質量下降。可修改編譯器報警級別,把警告作為錯誤提示,有全域性設定。 也應平衡時間,不行就先記錄警告留待處理。

放棄的方法不再使用,系統或自己的。新增放棄提示和應對提示,表明放棄版本和時間。

對問題各個擊破:使用mock模擬物件,對單元測試過的**隔離。用原型還原問題請專家,原型隔離幫分析。二分查詢,分析服務執行日誌。

報告所有異常

8 敏捷協作

立會 每天進行,昨天收穫,今天計畫,會有什麼問題,到公司一小時後進行,每人倆分鐘。不深入討論(可會後單獨深入),豬參與雞不,預約1小時會議室,進行15-30分鐘合適。小團隊2天一次或一周2次。團隊意識

架構師碼**,移除軟體不可逆部分,去除所謂架構概念。實際情況設計。

**公有,任務輪換,讓大家接觸不同部分的**,接觸彼此的**。但並不是隨意修改,必須的注釋,必要的修改。平衡,有些專家領域的只開放瀏覽學習。

成為指導者 共享知識,團隊提公升,知識、經驗、體會,開部落格等分享而不是講座,可以結對程式設計。讓別人相信你可以幫他們,而不是故意訂立規矩為難他們。

允許大家自己想辦法 告訴別人思路,讓他們自己思考和實現,一段時間後反饋,看是自己的起作用,還是他們的新方式,能讓自己學習。

準備好後再共享** 完成一項任務後,立即提交,可備別人使用並收集反饋。原子提交並加注釋,便於回滾。

**複查:查詢問題效率高,但可能會犧牲一些時間,並引發一些反感。-互相複查是一種方式,或者結對程式設計。 要訂製檢查問題列表,包括不限於 所有異常處理不空,**易於理解,是否有明顯錯誤,是否解耦不影響其他模組,是否重複,是否可重構等。**複查不是批評,應允許不同的實現方式。

及時通報進展和問題 別等到最後一刻才報告問題,立會時。

9走向敏捷

開發習慣一點點引入,困境的專案如果一下改變必然失敗,像不能要求乙個病人立即運動一樣。

引入敏捷 目的是為了更輕鬆的工作,

步驟: 1讓團隊知道接下來要發生什麼,從立會開始,讓架構師(所有人)參與編碼,開展非正式**審核。

2準備開發環境,版本控制、單元測試、自動構建、日誌記錄、開發日誌。

3帶團隊進入固定節奏,用5、6、7章的習慣解決日常問題。

讀書筆記 軟體除錯修煉之道 1

由於project中總是debug,修改問題,故通過自己讀過的一本書來記錄,並做說明。什麼是除錯?除錯不僅是排除缺陷,有效的除錯需要採用一下步驟 1.弄清楚軟體為什麼執行失常?2.修復這一問題。3.避免破壞其他部分 在我司重要通過regression來保證,這一點非常好 4.保持或提高 的總體質量 ...

敏捷開發修煉之道

敏捷開發宣言 敏捷的精神 敏捷的修煉之道 敏捷工具箱 做事欲速則不達 對事不對人 排除萬難,奮勇前行 敏捷需要不斷的學習和充電 跟蹤變化 對團隊投資 懂得丟棄 打破砂鍋問到底 把握開發節奏 沒有任何計畫在遇敵後還能繼續執行。讓客戶做決定 讓設計指導而不是操作開發 好設計是一張地圖,它也會進化。設計指...

敏捷開發修煉之道

敏捷開發宣言 敏捷的精神 敏捷的修煉之道 敏捷工具箱 做事欲速則不達 對事不對人 排除萬難,奮勇前行 敏捷需要不斷的學習和充電 跟蹤變化 對團隊投資 懂得丟棄 打破砂鍋問到底 把握開發節奏 沒有任何計畫在遇敵後還能繼續執行。讓客戶做決定 讓設計指導而不是操作開發 好設計是一張地圖,它也會進化。設計指...