itpub個人空間 v2bu+j-u y.sy%a
itpub個人空間&r0y;f~ v;j!k,l%v
itpub個人空間ftd/ky&?
j5~,a i@0
文/陳序明
黃彥軍 敏捷開
發中code review的目的及內容
做任何事情，首先要清晰為什麼要做，才能有目標和動力把事情做得更好，code review 也是如此。只有清晰明確了敏捷團隊進行codereview 的動機，才能以此為方向開展後續工作。下面我們推薦的敏捷開發中常見的code review的目的：
itpub個人空間 e,~3[ ~c x7|!b(e
設計合理性review
在筆者的另一篇文章中《敏捷開發中的架構設計》談到，敏捷開發中崇尚code is design，對開發人員提出了比以往更高的要求，即需要開發人員不斷地重構出合理的設計。所以敏捷開發中的code review也需要承擔一部分「結對設計」和「設計把關」的職責。
這部分的code review 包括：設計的合理性（如實現方法，資料結構，設計模式，擴充套件性考慮等），是否存在大量重複**和其他元件是否有重複的**，包結構設計是否合理等。
筆者了解的一些專案中， 進行敏捷開發後， 提高了開發效率， 但是設計的質量卻下降了。如repeat
yourself 的現象（特別是跨元件之間的repeat yourself 現象）；更有甚者，在筆者看到乙個某銀行的應用中（不是國內的），資料庫連線和操作是直接在jsp中寫sql語句。
像這些bad design 的例子還是很多的。這些在重構的時候應該由開發人員解決。但考慮到不同開發人員之間技術功底不一，很有必要在code
review階段進行review和討論。
互為backup
這是很容易被忽略，但是又很重要的乙個code review的目的。
我們知道，敏捷開發中強調高質量的**勝過詳細的文件，所以某種程度上來說code is document。敏捷開發中的**承擔了一部分document的職責，即傳遞技術的作用。
code review 中，review 的開發人員了解**的設計和實現，傳遞了技術，開發人員互為backup，方便後期的維護，也減少了專案風險。
itpub個人空間 y z-/p,`9n
分享知識、設計、技術
這也是很容易被忽略的乙個很重要的目的。敏捷開發是乙個**集中控制到個體發揮積極性的過程，**集中控制的優點就是有統一的檢視和控制，經常開大會，開長會，這樣知識和經驗也較容易集中。敏捷開發中，分散在兩個scrum team的開發人員之間，如果沒有好的機制，相互溝通也會相對較少，造成知識和好的經驗無法在整個團隊傳播。
筆者參加的專案中就碰到了類似情況， 當時我們整個團隊分成三個scrum team，其中乙個scrum team負責乙個eclipse 工具的開發， 其中用到的一些功能和知識在其他scrumteam上以前都有涉及過。當時負責開發的同事非常優秀而且能力突出，但由於不知道其他 scrum team同事有這方面的經驗，沒有很好地分享以往好的經驗和知識，以至於最後導致浪費了一些學習的成本。
code review是乙個學習和享受的過程，乙個開發人員的能力有限，而code review正是這樣的一種機制，讓好的知識、設計在團隊中分享，實現整體團隊的成長和整體的效益最大化。
itpub個人空間 [/y*m)^l x*?~h#`j9l
n1mm}+q.mg,v0
itpub個人空間&c{ d e;v e7o?k
敏捷開發 敏捷開發中的質量
有小夥伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了乙個faq，內容如下 敏捷開發是什麼？敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟體開發方法，至於什麼是敏捷，就去問問度娘吧。對於敏捷團隊來說，是乙個自組織的，有集體目...
敏捷中開發中的承諾解析
敏捷中的 promise 和 從commitment其實是不同的，具體參考下面兩篇文章的說法 摘抄其中說的不錯的一段 當自己得到這個問題的答案之後，我思考的第二個問題是，在具體的專案實踐中，怎麼去落地這5個價值觀？對於勇氣，尊重，專注，開放這4點，我並沒有花費很多時間就想到了方案，我相信如果能認同這...
敏捷開發中的軟體測試
敏捷開發中的軟體測試 陳能技 2007 9 5 參考 bret pettichord 的 agile testing what is it?can it work?和 agile testing challenges 敏捷宣言 個體和互動比過程和工具更有價值 能工作的軟體比全面的文件更有價值 顧客的...