結對程式設計其實可以變變?

2021-09-22 04:54:30 字數 800 閱讀 9755

想必大家對敏捷開發中的結對程式設計都有所了解,可在公司試用推廣時卻很容易遭到大多數同事的反對,反對理由如下:

1.長期的習慣導致在有個人在旁邊監督你編寫**時很彆扭;

2.敏捷的結對程式設計要求兩個程式設計師最好能力水平相當?這個不好界定吧,另外每個人都有每個人的編碼習慣,大家也知道,做為程式設計師的我們往往比較固執,也比較愛布道,所以很容易產生各種實時衝突,影響開發效率;

3.也許兩個人會聊其他話題哦,比如這款智慧型機怎樣,那遊戲怎麼樣,哈哈,這種情況應該比較少吧。

其實我認為可以引入一種結對程式設計的變種,並不是嚴格按照敏捷概念的那種結對。而是對大範圍的乙個結對,比如說乙個產品(在我們公司常常就有乙個人開發乙個產品的情況),乙個子系統,乙個核心功能的結對,不是針對編碼的結對,恰恰,編碼要分開!我覺得這種結對的精髓就是,對核心功能的設計兩個人都去參與研究和設計,然後綜合二人的方案提交給部門乙個評審方案,因為乙個人研究乙個核心功能難免會有思維侷限,要麼就是陷入誤區後無法很快找到熟悉此功能的人一起**。而結對程式設計在某種程度上規避了此種風險的發生,子系統的設計開發和產品的設計開發同理。注意,有一點,編碼上一定要嚴格分開,兩人不能有功能和**上的交叉重疊。**完成後,**評審也在兩人間進行。

我覺得採用以上結對程式設計,相比傳統的敏捷結對程式設計有以下幾個好處:

1.沒人監視程式設計了,很舒服,自主;

2.水平不相當也沒關係,把簡單功能分給水平稍低的;

3.功能的分解由兩個人同時寫**完成肯定比只有乙個人寫**快;

4.質量?沒關係,有**評審呢;

5.衝突,至少實時的衝突沒有了,兩個人可以在**評審時互相學習,集中解決衝突。

yaocoder

結對程式設計其實可以變變?

想必大家對敏捷開發中的結對程式設計都有所了解,可在公司試用推廣時卻很容易遭到大多數同事的反對,反對理由如下 1.長期的習慣導致在有個人在旁邊監督你編寫 時很彆扭 2.敏捷的結對程式設計要求兩個程式設計師最好能力水平相當?這個不好界定吧,另外每個人都有每個人的編碼習慣,大家也知道,做為程式設計師的我們...

其實你可以不必Redis exists

今天,不小心看到一段 因之前優化過類似的問題。但是這種問題一而再再而三出現,真心覺得碼農,也不是誰都能當好的。細節決定成敗,做事情的風格,真真的會阻礙乙個人的發展。廢話不多說,直接上 不友好使用方式 if jedis.exists key else 友好使用方式 string value jedis...

其實幸福可以很簡單

愛,本來就是一件百轉千迴的事,說不定有那麼一瞬就會幡然悔悟 原來你也在這裡。其實,幸福真的很簡單。仔細想想,你的身邊是不是有這樣的人?他清楚地記得你喜歡吃什麼口味的零食,兩人一起吃飯時會主動地把肥肉 骨頭 菜根 配菜挑到自己碗裡 心情不好時,他會靜靜陪著你。卻不會追問到底是什麼事,他會等你主動告訴他...