《敏捷軟件開發》讀書筆記 --項目開發過程中如何輕裝簡行

文章目錄

為什么是《敏捷軟件開發》

極限編程實踐

完整團隊

計劃游戲

客戶測試

簡單設計

結對編程

測試驅動開發

改進設計

可持續的速度

敏捷軟件開發宣言

結對編程

《重構》讀書筆記

設計模式六大原則

什么激發了軟件設計的腐臭味

為什么是《敏捷軟件開發》

我也想風馳電掣，快馬加鞭。但是殘酷的現實一次次的打在我的臉上。一天一天就這么的浪費在了無意義的編碼上，不斷的推翻，重建，推翻，重建。倒不是為了精益求精而改寫代碼，而是每一版都有邏輯上的大問題，以及需求的不明確，導致寫出來的東西要么不能用，要么不合規。更有甚者，寫到末期了，發現那臨門一腳，邁不開，回溯到了前邊不知哪一步了。

時間都去哪兒了？

為什么是《敏捷軟件開發》？

當然是因為我有需求啊，而這本在我的書庫里面躺灰的書的書名恰巧引起了我的注意。

不知它是或否能解決我的困惑呢？為我帶來這曙光。

Tips：

本文不涉及代碼，還愿意繼續嗎

Tips：不但如此，還會有穿插文中的鏈接

極限編程實踐

（本段出自《敏捷軟件開發》，是我非常喜歡的一個片段，放在開頭與大家共享）

完整團隊

XP項目的所有參與者(開發人員、業務分析師、測試人員等等)一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。

關于這點，我前些天去我樂哥的公司玩兒的時候，就感受到了這種輕松愉快的氛圍，還挺喜歡，這就是工作嗎，那也是愿意上班的。

計劃游戲

計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。

這個暫時還體會不到。曾經我的老師跟我說，程序員應該每個月都在項目期，這樣的進步是非常快的。我也不知道對不對，但是讓我這么搞，我這小身板兒怕是hold不住啊。

客戶測試

作為選擇每個所期望的特性的一部分，客戶定義出自動驗收測試來表明該特性可以工作。

簡單設計

團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復,表達出了編寫者想表達的所有東西，并且包含盡可能少的代碼。

這也是我一直追求的。以前是通過代碼的不斷迭代，但是現在我覺得應該是通過理論的不斷迭代來達成這個愿景。

結對編程

所有的產品軟件都是由兩個程序員、并排坐在一-起在同一臺機器上構建的。

這個我也曾努力過，但是他們都去上班了。。。

測試驅動開發

程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。

這個就是我一直對我的團隊成員說的，每一個模塊，在開始寫之前應該先把測試的刁鉆案例先寫好，模塊一寫完馬上進行測試。

改進設計

隨時改進糟糕的代碼，保持代碼盡可能的干凈、具有表達力。

可持續的速度

團隊只有持久才有獲勝的希望，他們能夠以長期維持的速度努力工作，他們保存精力，他們把項目看做是馬拉松長跑，而不是全速短跑。

敏捷軟件開發宣言

墨子說：非賢無急，非士無與慮國

優質的團隊固然重要，但是更為重要的是團隊成員之間的協作。

詳盡的文檔固然重要，但是給你一本磚頭一樣的工具書你能看幾頁？

至于第三點，嗯，懂得都懂。。。

結對編程

我靠，這個實在是太喜歡了。倒也不是找不到人，只是沒有去找。

好吧，是有點困難。

結對編程：所有的產品代碼都是由結對的程序員使用一臺電腦共同完成的。結對人員中的一位控制鍵盤輸入，另一位觀察輸入的代碼中的錯誤和可以改進的地方···

多好。實名羨慕。

理想中是這樣的：

當然這樣也是可以接受的：

總不能這樣吧：（其實也并無不可，我要在后邊）

靠，下次帶團隊項目就這么玩，，，

主要是我自己想玩

《重構》讀書筆記

重構<1> 好好的項目為什么我要一遍遍重寫

重構<2> 那些該回爐重造的回鍋肉

重構<3> 我是一個類，難道我不配擁有專屬測試代碼嗎？

設計模式六大原則

六大原則不熟？那你學什么設計模式！

什么激發了軟件設計的腐臭味

僵化、脆弱、不牢固

粘滯、不必要的復雜、不必要的重復、晦澀難懂。

什么時候，我們寫出來的代碼變成了這樣。

如果不服氣，請找出自己兩個月前寫的開發代碼。如果覺得還很不錯，那要么是你的代碼作風真的非常好，要么就是你這兩個月就沒什么進步。

我經常翻看自己以前寫的項目代碼，常常感慨：這寫的什么狗屎？這段代碼的算法思想是什么？WC，為什么注釋亂寫？？？？？

哎。。。然后開始大改。

改到一半，實在受不了了，這還不如重寫。

問題出在哪里呢？

首先就是設計的問題，代碼結構設計不好，其實那時候的我們可能也就那個水平，只能設計出那樣的結構來，也無話可說。

其次就是不寫注釋，或者亂寫注釋。不是說，程序員最討厭的兩件事就是：別人不寫注釋，和別人叫我寫注釋嘛。（我正在養成寫好注釋的習慣，盡量言簡意賅）

再就是面向CV編程了。

少復制粘貼吧，實在不行，就手抄嘛，復制粘貼很容易出問題，特別是在變量命名上，有時候就把別的地方的變量夾帶過去，又忘記改，回頭來找還不好找。

對付時常變化的需求，就將功能封裝成可拓展性強的模塊吧。

我的困惑已經得到了解決，《敏捷軟件開發》這本書里面的設計模式講的也不錯，后面我還會用這本書在整理一下我所學的設計模式。

不知解決了你的困惑嗎，如果你發現看不懂那本書，或者看不懂我這么淺顯易懂的文，敲個幾萬行熟悉一下就好啦，問題不大。

敏捷開發 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。