文章目錄
- 為什么是《敏捷軟體開發》
- 極限編程實踐
- 完整團隊
- 計劃游戲
- 客戶測驗
- 簡單設計
- 結對編程
- 測驗驅動開發
- 改進設計
- 可持續的速度
- 敏捷軟體開發宣言
- 結對編程
- 《重構》讀書筆記
- 設計模式六大原則
- 什么激發了軟體設計的腐臭味
為什么是《敏捷軟體開發》
我也想風馳電掣，快馬加鞭，但是殘酷的現實一次次的打在我的臉上，一天一天就這么的浪費在了無意義的編碼上，不斷的推翻，重建，推翻，重建，倒不是為了精益求精而改寫代碼，而是每一版都有邏輯上的大問題，以及需求的不明確，導致寫出來的東西要么不能用，要么不合規，更有甚者，寫到末期了，發現那臨門一腳，邁不開，回溯到了前邊不知哪一步了，
時間都去哪兒了？
為什么是《敏捷軟體開發》？
當然是因為我有需求啊，而這本在我的書庫里面躺灰的書的書名恰巧引起了我的注意，
不知它是或否能解決我的困惑呢？為我帶來這曙光，
Tips：本文不涉及代碼，還愿意繼續嗎
Tips：不但如此，還會有穿插文中的鏈接
極限編程實踐
（本段出自《敏捷軟體開發》，是我非常喜歡的一個片段，放在開頭與大家共享）
完整團隊
XP專案的所有參與者(開發人員、業務分析師、測驗人員等等)一起作業在一個開放的場所中，他們是同一個團隊的成員，這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西，
關于這點，我前些天去我樂哥的公司玩兒的時候，就感受到了這種輕松愉快的氛圍，還挺喜歡，這就是作業嗎，那也是愿意上班的，
計劃游戲
計劃是持續的、循序漸進的，每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實作的特性，
這個暫時還體會不到，曾經我的老師跟我說，程式員應該每個月都在專案期，這樣的進步是非常快的，我也不知道對不對，但是讓我這么搞，我這小身板兒怕是hold不住啊，
客戶測驗
作為選擇每個所期望的特性的一部分，客戶定義出自動驗收測驗來表明該特性可以作業，
簡單設計
團隊保持設計恰好和當前的系統功能相匹配，它通過了所有的測驗，不包含任何重復,表達出了撰寫者想表達的所有東西，并且包含盡可能少的代碼，
這也是我一直追求的，以前是通過代碼的不斷迭代，但是現在我覺得應該是通過理論的不斷迭代來達成這個愿景，
結對編程
所有的產品軟體都是由兩個程式員、并排坐在一-起在同一臺機器上構建的，
這個我也曾努力過，但是他們都去上班了，，，
測驗驅動開發
程式員以非常短的回圈周期作業，他們先增加一個失敗的測驗，然后使之通過，
這個就是我一直對我的團隊成員說的，每一個模塊，在開始寫之前應該先把測驗的刁鉆案例先寫好，模塊一寫完馬上進行測驗，
改進設計
隨時改進糟糕的代碼，保持代碼盡可能的干凈、具有表達力，
可持續的速度
團隊只有持久才有獲勝的希望，他們能夠以長期維持的速度努力作業，他們保存精力，他們把專案看做是馬拉松長跑，而不是全速短跑，
敏捷軟體開發宣言
| 個體和互動 | 勝過 | 程序工具 |
| 可以作業的伙伴 | 勝過 | 面面俱到的檔案 |
| 客戶合作 | 勝過 | 合同談判 |
| 回應變化 | 勝過 | 遵循計劃 |
墨子說：非賢無急，非士無與慮國
優質的團隊固然重要，但是更為重要的是團隊成員之間的協作，
詳盡的檔案固然重要，但是給你一本磚頭一樣的工具書你能看幾頁？
至于第三點，嗯，懂得都懂，，，
結對編程
我靠，這個實在是太喜歡了，倒也不是找不到人，只是沒有去找，
好吧，是有點困難，
結對編程：所有的產品代碼都是由結對的程式員使用一臺電腦共同完成的，結對人員中的一位控制鍵盤輸入，另一位觀察輸入的代碼中的錯誤和可以改進的地方···
多好，實名羨慕，
理想中是這樣的：
當然這樣也是可以接受的：
總不能這樣吧：（其實也并無不可，我要在后邊）
靠，下次帶團隊專案就這么玩，，，
主要是我自己想玩
《重構》讀書筆記
重構<1> 好好的專案為什么我要一遍遍重寫
重構<2> 那些該回爐重造的回鍋肉
重構<3> 我是一個類，難道我不配擁有專屬測驗代碼嗎？
設計模式六大原則
六大原則不熟？那你學什么設計模式！
什么激發了軟體設計的腐臭味
僵化、脆弱、不牢固
粘滯、不必要的復雜、不必要的重復、晦澀難懂，
什么時候，我們寫出來的代碼變成了這樣，
如果不服氣，請找出自己兩個月前寫的開發代碼，如果覺得還很不錯，那要么是你的代碼作風真的非常好，要么就是你這兩個月就沒什么進步，
我經常翻看自己以前寫的專案代碼，常常感慨：這寫的什么狗屎？這段代碼的演算法思想是什么？WC，為什么注釋亂寫？？？？？
哎，，，然后開始大改，
改到一半，實在受不了了，這還不如重寫，
問題出在哪里呢？
首先就是設計的問題，代碼結構設計不好，其實那時候的我們可能也就那個水平，只能設計出那樣的結構來，也無話可說，
其次就是不寫注釋，或者亂寫注釋，不是說，程式員最討厭的兩件事就是：別人不寫注釋，和別人叫我寫注釋嘛，（我正在養成寫好注釋的習慣，盡量言簡意賅）
再就是面向CV編程了，
少復制粘貼吧，實在不行，就手抄嘛，復制粘貼很容易出問題，特別是在變數命名上，有時候就把別的地方的變數夾帶過去，又忘記改，回頭來找還不好找，
對付時常變化的需求，就將功能封裝成可拓展性強的模塊吧，
我的困惑已經得到了解決，《敏捷軟體開發》這本書里面的設計模式講的也不錯，后面我還會用這本書在整理一下我所學的設計模式，
不知解決了你的困惑嗎，如果你發現看不懂那本書，或者看不懂我這么淺顯易懂的文，敲個幾萬行熟悉一下就好啦，問題不大，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/232005.html
標籤：其他