通過昨天對老師的提問，也算是對一直以來的困惑和思考做了個總結。

敏捷開發是一種內涵非常豐富的思想，面向使用者，面向需求，而不是面向模組。而TDD則是一種卓有成效地提高工作效率的辦法，與敏捷相輔相成。

接下來，結合本人最近專案上的一些經驗和教訓，來做一個深入的總結和反思吧~

關於敏捷，面向需求和麵向模組究竟有什麼區別呢？

以目前的經驗為例，作為一個使用者量巨大的後臺，按照模組來分，有測試模組，面向資料庫的模組，面向快取的模組和麵向前端的模組。如果按照模組來分工合作的話，會出現的問題是，介面的負責人很難提供其他模組所需要的特定功能，很難知道自己的介面在其他模組究竟是怎樣執行的，發揮著什麼樣的作用。倘若嘗試解決這些問題，溝通的成本是昂貴的，需要給出的API文件的工作量和需要的時間成本同樣很高，但是需要更新甚至返工的概率是很大的。那麼按照需求來分工的話，則是功能的開發者對所需要的模組介面進行全域性的設計和實現，在已有的可擴充套件性較高的介面基礎之上，為需求進行專屬的擴充套件。事實上有經驗的對業務進展十分清楚的程式設計師會能夠在最初設計介面是就考慮介面的通用性，為後來的介面擴充套件提供便利，但多數情況下還是按照功能，定製地去拓展介面。

這種情況下對程式設計師的挑戰是大於以往的，一方面，前期的結構對於後期功能的拓展可能會是一種阻礙，很可能需要全部重來。如果介面的可拓展性極差，或者架構對後期的功能的新增會產生大量負面影響而需要重新設計，推翻重來是不可避免的。所以這是十分需要經驗的，現代軟體開發流程的科學化使得很多公司有專門的架構師，這類人所承擔的責任通常是巨大的，就我現在的感受而言，架構師應該不僅僅是面向開發團隊的，同時也是面向使用者的。在我們這次實踐中，SM便是這樣的一種角色，而PO更像是使用者和SM之間的橋樑。如果SM缺乏面向使用者的意識，整個團隊的代價是無法真正實現敏捷的，開發過程中遇到的阻礙也可能會變多。另一方面，是對程式設計技能的要求更高，需要更加全面的程式設計知識。譬如，一個後臺程式設計師，除了要對前端有所瞭解，對於演算法，資料庫，資料庫底層，作業系統效能等方面都比較熟悉，否則同樣是無法敏捷的。也就是說，對於一個整體的功能，任何拿到部分功能的程式設計師，都應當具備實現全域性功能的程式設計能力，同時也意味著不同的人是需要操作相同的模組的。

關於測試，什麼樣的測試才是系統測試呢？

還是結合自身經歷來思考。對於一個面向前端的登入介面，我們獲得前端的輸入，返回其想要的結果，我們不需要關心使用者資訊是否寫入了資料庫或快取，不需要關心返回值是如何計算的，這個過程中可能出現的錯誤等。我們的測試是不依賴於實現的。那麼單元測試呢？我的理解是，單元測試時關注實現的，譬如我的需求，a+b+c，實現者利用了函式sum(a,b,c,)，過程需要函式add（x,y），系統只關心初值和終值，單元卻還會關心過程中的兩次add，他需要知道實現，才能確認實現，進而測試實現來保證最終結果。

那麼，TDD是什麼，又如何應用呢？

TDD，所謂測試驅動開發，那麼一定是測試現行。TDD的過程中，我們需要的是專注於一個需求的開發，直到測試通過。這裡我說針對一個需求，我想強調的，這裡的測試，應當是不依賴於實現的系統測試，而不是單元測試。否則，TDD將難以展開。

大多數情況下，開發者會先開發再測試，很可能出現的一種情況是，過程中一系列的單元測試都是通過的，但最終的功能依舊無法保證，這時再開展系統測試，可以說是比較耗費時間的，畢竟，原本你的目標可以變成：通過眼前這一項測試。

先這麼多吧~期待後面會有更多不一樣的感受。