關於團隊成員之間協做的一點感悟

 

我之前作什麼都喜歡一我的，靜悄悄地，誰都不鳥。工做了以後更多的是團隊協做，十幾我的的項目組和十來我的的部門都待過，打過交道的人多了以後對人與人之間的合做關係就有了一點點感悟，特此作一下總結。

-----------------------------------------------------------------------------------------------

 

關於BUG

現代軟件都是多個工(wu)種(zhong)之間互相配合協做開發的，既然哥幾個搭夥兒搞事情，事情搞多了，就不免有搞砸的時候，當事情搞砸出現問題的時候應該如何處理呢。

 

通常解決問題的兩個步驟：

1. 排查出問題出在哪裏（打開冰箱門）

2. 給出解決方案，執行並觀察結果（把大象塞進去關上冰箱門）

 

第一步，排查出問題出在哪裏，這一步是容易致使內訌的地方，沒人願意認可本身的東西有問題，可是爭吵是解決不了問題的（武力更不行...）。以前跟測試打交(si)道(bi)的經歷告訴我，靠吼是沒有用的，遇事必定要講道理，只有拿出證據才能讓人信服。

1. 不帶我的感情，有一個現象就是當咱們對某我的的某個行爲看不順眼的時候，慢慢會演變爲對這我的整我的的否認，平時可能還看不出來，當遇到問題的時候就很容易被誤導產生偏激的想法。

2. 屬於本身職責範圍內的事情，當別人提出質疑的時候，應該本身證實本身是沒問題的，而不是讓別人來證實你是有問題的。

3. 若是證實確實是本身的問題，坦然認可並修復它，不準內心明知道確實是本身錯了還死要面子梗着脖子嘴硬（我也有過信誓旦旦嘴硬的時候被鐵通常的證據啪啪打臉....~~o(>_<)o ~~）。

4. 無論寫的是代碼，仍是腳本，關鍵操做什麼的都要多打log，log能夠避免不少無心義的爭吵，log讓生活更美好（Axure是產品經理的利器，log是程序員的利器）。

5. 必定要博學，擁有必定的廣度和深度，當你對某個東西不是很熟悉的時候，人家說啥你也很懵逼，就很沒有底氣，因此說人醜就要多讀書是有必定道理的！

 

第二步，給出解決方案，執行並觀察結果

1. 誰污染，誰治理。誰搞出來的問題誰負責修復它，一個是這我的比較熟悉，修復起來成本比較低，另外一個就是培養責任感，如今不少程序員都缺乏責任感。

2. 解決方案要公開，透明，別藏着掖着只說修復啦，到底怎麼修復的啊，拿出來給你們看看科學不，萬一有明顯漏洞也能及早發現避免bug reopen。

 

 

關於聯調

1. 本身作的東西，起碼要自測一遍確認沒有明顯問題再交給對方，這是對合做夥伴的基本尊重，不要傳個還有語法錯誤的文件說搞好了。

2. 若是是作前端的，頁面寫完了作點假數據，本身點一點，多用幾個瀏覽器測一測，server url要統一在一個地方配置，不要好幾個地方搞的人家部署的人頭都大了。

3. 若是是寫後端接口的，應該出一份接口文檔，此文檔以實用爲主，哪一個接口，接受什麼參數，參數數據類型，是否必選，默認值是啥，接口請求的樣例數據，接口響應的返回樣例，返回字段解釋等等。

4. 若是是傳統型軟件，計算任務（日期格式化之類的將原始數據轉爲對用戶友好易讀格式的計算任務）放在後端沒問題，可能後端處理確實要方便一些，但若是是高併發型項目，服務器資源很寶貴，應該儘可能將計算任務往前移，緣由是顯然的。

 

 

 

最後，學好Linux很重要！學好Linux很重要！學好Linux很重要！

道理都懂，仍是作很差.........

 

 

。