敏捷的反饋

敏捷反饋

守護天使

Coding feedback.
爲了應對代碼的變化，你須要持續得到代碼健康狀態的反饋：他是在作你指望的事情嗎？最近一次修改有沒有無心中破壞了什麼功能？爲了確保全部功能都能正常工做，就須要自動化單元測試。

一些開發者會對「測試」這個詞有意見，應把它看做是一個代碼技術。用代碼來檢查變量的具體值，而不是手工檢查那些感興趣的變量。

只要有了單元測試，就讓到他們自動運行，也就是每次編譯或者構建代碼的時候，就運行一次測試。把單元測試的結果看做是和編譯器同樣——若是測試沒有經過，那就像變異沒有經過同樣糟糕。

接下來就是在後臺假設一個構建機器，不斷獲取最新版本的源代碼，而後編譯代碼，並運行單元測試，若是有任何錯誤它會讓你及時知道，這是最容易修復也是成本最低的時候。

具體技巧

• 單元測試是優質股，值得投資。但一些簡單的屬性訪問方法或者價值不大的方法，是不值得花費時間進行測試的。
• 人們不編寫單元測試的不少藉口都是由於代碼中的設計缺陷。一般，抗議越強烈，就說明設計越糟糕。
• 單元測試只有在達到必定測試覆蓋率的時候，才能真正地發揮做用。你可使用一些測試覆蓋率工具，大體瞭解本身的單元測試的覆蓋狀況。
• 不是測試越多質量就會越高，測試必需要有效。若是測試沒法發現任何問題，也許它們就是沒有測試對路。

先用它再實現它

咱們的業務是要創造出能調用的API和可使用的接口。這就是說，你在說服其餘人使用它以前，先得讓本身切實地使用這些接口。事實上，在你剛作完設計但尚未完成後面的實現的時候，應該使用它。這個可行嗎？

Write test before writing code.
使用被稱爲TDD（Test Driven Development，測試驅動開發）的技術，你老是在有一個失敗的單元測試後纔開始編碼。測試老是先編寫。一般，測試失敗要麼是由於測試的方法不存在，要麼是由於方法的邏輯還不足以讓測試經過。

先寫測試，你就會站在代碼用戶的角度來思考，而不只僅是一個單純的實現者，這樣作是有很大區別的，你會發現，由於你本身要使用它們，因此能設計一個更有用、更一致的接口，除此以外，先寫測試有助於消除過分複雜的設計，讓你能夠專一於真正須要完成的工做。

消除那些尚未編寫的類，這會很容易地簡化代碼。相反，一旦你已經編寫了代碼，也許會強迫本身保留這些代碼，並繼續使用它，即便代碼已通過期做廢好久了。

Good design doesn’t mean more classes.
當你開發設計面向對象系統的時候，可能會迫使本身使用對象，有一種傾向認爲，面對對象的系統應該由對象組成，咱們迫使本身建立愈來愈多的對象類，無論他們是否真的須要。添加無用代碼老是很差的想法。

具體技巧

• 不要把測試優先和提交代碼以前的測試等同起來。測試先行能夠幫助你改進設計，但你仍是須要在提交代碼以前作測試。
• 任何一個設計均可以被改進
• 你在驗證一個想法或者設計一個原型的時候，單元測試也許並不適合。可是，玩意這些代碼不行倉促演變成了一個真正的系統，就必需要爲它們添加測試（可是最好能從新開始設計系統）。
• 單純的單元測試沒法保證好的設計，但它們會對設計有幫助，會讓設計更加簡單。

不一樣環境，就有不一樣問題

也許，你會要求測試團隊在全部支持的平臺上進行測試。若是它們是手工進行測試，可能並非最可靠的測試辦法。咱們須要更加面向開發者的測試辦法。

你已經編寫了單元測試，測試你的代碼。每次在修改或者重構代碼的時候，在提交代碼以前，你會運行測試用例。那麼如今所要作的，就是在各類支持的平臺和環境中運行這些測試用例。

Automate to save time.
可是，也許你已經有時間壓力了，所以，你怎麼可能有時間在多個平臺上運行測試呢？這就要靠持續集成來拯救了。咱們在前面的保持能夠發佈中學過，用一個持續集成工具，週期性地從源代碼控制系統中取得代碼，並運行代碼。若是有任何測試失敗了，他會通知相關的開發者。通知方式多是電子郵件、頁面I、RSS Feed或者其餘一些新穎的方式。要在多個平臺上測試，你只要爲每一個平臺設置持續集成系統就好了。當你或者同事提交了代碼，測試會在每一個平臺上自動運行。

具體技巧

• 硬件比開發人員的時間便宜。但若是你有不少配置，要支持大量的平臺，能夠選擇哪些平臺須要內部測試。
• 軟件在不少平臺上出現Bug極可能只是由於棧佈局的差別、機器字大小端的不一樣所致。所以，即便用Solaris的用戶比用Linux的少不少，你也仍然要在兩個系統上都進行測試。
• 你不但願由於一個錯誤而收到5次通知轟炸（這就像是雙重徵稅，會致使電子郵件疲勞症）。能夠設置一個主構建平臺或者配置，下降其餘構建服務器的運行頻率，這樣在它失敗的時候，你就有足夠的時間來修復主構建平臺。或者彙總全部錯誤報告信息到一個地方，進行統一處理。

自動驗收測試

關鍵業務邏輯必需要獨立進行嚴格的測試，而且最後須要經過用戶的審批。但你也不可能拉着用戶，逐一檢查每一個單元測試的運行結果。實際上，你須要能自動比較用戶指望和實際完成的工做。

有一個辦法可使驗收測試不一樣於單元測試。你應該讓用戶在沒必要學習編碼的狀況下，根據本身的須要進行添加、更新和修改數據。你有不少方法來實現它。

FIT，即集成測試框架，它很實用，能夠更容易地使用HTML表格定義測試用例，並比較測試結果數據。使用FIT，客戶能夠定義帶有新功能的使用樣本。客戶、測試人員和開發人員（根據樣本）均可以建立表格，爲代碼描述kennel的輸入和輸出值。開發人員會參照帶有正在開發的代碼結果的FIT表格中的樣本編寫測試代碼。測試結果成功或者失敗，都會顯示在HTML頁面中，用戶能夠很方便地查閱。

若是領域專家提供了業務的算法、運算或者方程式，爲他們實現一套能夠獨立運行的測試。要讓這些測試都成爲測試套件的一部分，你會在項目生命週期中確保持續爲它們提供正確的答案。

具體技巧

• 不是全部客戶都能給你提供正確的數據。若是它們已經有了正確的數據，就根本不須要新系統了。
• 你也許會在舊系統中發現之前根本不知道的bug，或者之前不存在的真正問題。
• 使用客戶的業務邏輯，可是不要陷入一望無際的文檔寫做之中。

度量真實的進度

時間的消逝能夠證實：判斷工做進度最好是看實際花費的時間而不是估計的時間。
咱們不該該去計算工做量完成的百分比，而應該測定還剩下多少工做量沒有完成。

在你最後真正完成一項任務時，要清楚知道完成這個任務真正花費的時間。奇怪的時，它花費的時間極可能要比最初估計時間長。沒有關係，咱們但願這能做爲下一次的參考。在爲下一個任務估計工做量時，能夠根據此次經驗調整評估。你的評估會波動一段時間，但隨着時間但推移，你但評估會與事實接近，你也會對任務所花費但時間有梗清楚的認識。

若是能一直讓下一步工做時可見的，會有助於進度度量。最好多作法就是使用待辦事項backlog。當添加新任務的時候，先排列它們的優先級，而後加入到待辦事項中。你也能夠有我的的待辦事項、當前迭代的待辦事項（工做項）或者整個項目的待辦事項（項目進行階段）。

具體技巧

• 6分鐘做爲一個時間單位，它的粒度太細了，這不是敏捷的作法。
• 一週或者一個月的時間單元，它的粒度太粗了，這也不是敏捷的作法。
• 關注功能，而不是日程表。
• 若是你在一個項目中花費了不少時間來了解你所花費的時間，而沒有足夠的時間進行工做，那麼你在瞭解你所花費的時間上花費的時間就太多了。聽懂了嗎？
• 一週工做40個小時，不是說你就有40個小時的編碼時間。你須要減去會議、電話、電子郵件以及其餘相關活動的時間。

傾聽用戶的聲音

It is a bug.
當出了錯誤，你要儘量地提供詳細信息。黑屏和含義不明的退出按鈕說很不友好的行爲。更糟糕的是，在獲得用戶反饋的時候，還嘲笑用戶愚蠢，而不去真正地解決問題。

無論它是不是產品的bug，仍是文檔的bug，或者是對用戶社區理解的bug，它都是團隊的問題，而不是用戶的問題。

咱們花費了很大的精力從單元測試之類的代碼中得到反饋，但卻最容易忽略最終用戶的反饋。你不只須要和真實用戶（不是他們的產品經理，也不是業務分析師之類的代理人）進行交談，還須要耐心地傾聽。

即便他們說的內容很傻！

具體技巧

• 沒有愚蠢的用戶
• 只有愚蠢自大的開發人員
• 「它就是這樣的。」這不是一個好的答案。
• 若是代碼問題解決不了，也許能夠考慮經過修改文檔或者培訓來彌補。
• 你的用戶有可能會閱讀全部的文檔，記住其中的全部內容，但也可能不會。