敏捷開發的宣言和原則

貌似有段時間沒寫什麼博客了，有質量的博客更少，雖然寫博客的初衷是記錄本身的學習內容，相似筆記性質的東西，但也但願能更有內容，而不是空泛的一些東西。。。

最近一大堆雜事，公司、生活，心力俱疲。節後算是找回了一些狀態，這個月的學習計劃，大概就是《敏捷軟件開發》這本書。。。

這篇博客，就大概介紹下敏捷軟件開發的宣言、原則和麪向對象設計的原則，以及我的的一些理解（楷體字體作區別）。。。

我的感受，瞭解一種東西，必定要明白它的設計理念，才能更懂如何去學習。。。

 

1、敏捷軟件開發宣言

個體和互動高於流程和工具

工做的軟件高於詳盡的文檔

--注重產品自己，而不是形式和流程，文檔應簡潔易閱讀，方便維護和同步

客戶合做高於合同談判

--主動擁抱變化，及時響應，持續交付

響應變化高於遵循計劃

--制定可實現的短時間清晰的目標，中期的粗略的計劃，長期的大方向有大概目標便可

 

2、敏捷宣言遵循的原則

一、咱們最重要的目標，是經過持續不斷的及早交付有價值的軟件使客戶滿意。

--持續交付，快速迭代

二、欣然面對變化，即便在開發後期也同樣，爲了客戶的競爭優點，敏捷過程掌握變化。

--敏捷更多適用於互聯網企業，移動端更甚，一個機會的存在期可能短的可憐，應儘可能保持軟件的靈活性，減少對系統形成的影響

三、常常交付可工做的軟件，相隔幾星期或一兩個月，傾向於採起較短的週期。

--儘早的、常常的交付可工做的知足需求的軟件，在Google，甚至能夠作到天天交付一個可工做的軟件，即beta版本

四、業務人員和開發人員必須互相合做，項目中的每一天都不例外。

--及時溝通，避免信息斷層，減小延時，隨時調整

五、激發個體的鬥志，以他們爲核心搭建項目，提供所需的環境和支援，輔以信任，從而打成目標。

--過程和方法對於項目的影響只有次要的影響，首要的影響是人

六、不論團隊內外，傳遞信息效果最好效率最高的方式是面對面的交談。

--郵件聽不了語氣，語音看不到表情，面對面溝通是最高效的辦法

七、可工做的軟件是進度的首要度量標準。

--最終產出物是可工做的軟件，so，快速迭代交付的重要性不言而喻，這也是衡量一個項目進度的重要的element

八、敏捷過程倡導可持續開發，負責人、開發人員和用戶要可以共同維持其步調穩定延續。

--目標清晰，設定可實現的短時間的詳細的目標，固然這種步調須要長時間的培養和鍛鍊

九、堅持不懈的追求技術卓越和良好設計，敏捷能力由此加強。

--拒絕平庸，追求卓越，良好的設計能減小不少工做中後期的麻煩，好比技術負債！

十、以簡潔爲本，它是極力減小沒必要要工做量的藝術。

--輕文檔，輕流程，重產出，重目標

十一、最好的架構、需求和設計出自自組織團隊。

--想起一句話：管理的最高境界是爲共同的目標，整個團隊共同承擔責任，而不是單一職權負責制

十二、團隊按期的反思如何能提升成效，並所以調整自身的舉止表現。

--不斷思考總結，調優，減小沒必要要的資源消耗

 

3、面向對象設計原則

SRP：單一職責原則

　　 就一個類而言，應該僅有一個引發它變化的緣由。

OCP：開放封閉原則

　　 軟件實體（類、模塊、函數等）應該是可擴展的，可是不可修改。

LSP：Liskov替換原則

　　 子類型必須能替換掉他們的基本類型。

DIP：依賴倒置原則

　　 抽象不該該依賴於細節，細節應該依賴於抽象。

ISP：接口隔離原則

　　 不該強迫用戶依賴於他們不用的方法，接口屬於用戶，不屬於它所在的類層次結構。

REP：重用發佈等價原則

　　 重用的粒度就是發佈的粒度。

CCP：共同重用原則

　　 一個包中全部的類應該是共同重用的，若是重用了包中的一個類，那麼就要重用包中的全部類，相互之間沒有緊密聯繫的類不該該在同一個包中。

CRP：共同封閉原則

　　 一個包中全部類對於同一類性質的變化應該是共同封閉的，一個變化若對一個包影響，則將對包中的全部類產生影響，而對其餘包不形成任何影響。

ADP：無依賴原則

　　 在包的依賴關係中不容許存在環，細節不該該被依賴。

SDP：穩定依賴原則

　　 朝着穩定的方向進行依賴。

SAP：穩定抽象原則

　　 一個包的抽象程度應該和其餘穩定程度一致。

 

關於敏捷軟件開發模式，其宣言和原則就是上面的一些內容，後續會不斷更新相關的，關於開發設計，敏捷測試的一些內容。