本文轉自我原博客:我的原博客地址,原博客已不再更新.
做事
指責不能修復bug—Blame dosn’t fix bugs.
- 把精力放在解決問題上,而不是抱怨和指責.
- 過程符合標準並不意味着結果是正確的.
- 在團隊中,勇於承認自己不知道答案,這會讓人放心.
- “這不是我的錯”,這句話不對.”這都是你的錯”,這句話更不對!
- 如果你沒犯過任何錯誤,說明你可能沒有努力去工作.
- 如果團隊中的一個成員的行爲一再傷害了團隊,則他表現的很不職業.
欲速則不達
防微杜漸—Be ware of land mines.
- 不要墜入快速的簡單修復之中.要投入時間和經精力保持代碼的整潔,敞亮.
一次又一次的快速修復,每一次都不探究問題的根源,久而久之就形成了一個危險的沼澤池,最終會吞噬整個項目的生命. - 你需要了解團隊的開發方法或開發過程.
- 如果團隊成員花些時間閱讀其他成員的代碼,他們就能保證代碼是可閱讀和可理解的.
- 代碼複審是發現bug的最有效的方法之一.
- 單元測試是防止代碼難懂的重要技術.
- 你必須要理解一塊代碼的是如何工作的,但不是一定需要成爲專家.
- 不要急於修復一段沒能真正理解的代碼.
- 所有的大型系統都非常複雜,沒有一個人可以完全明白所有的代碼.
對事不對人
消極扼殺創新—Negativity kills innovation.
- 整個團隊應該關注真正有價值的問題,而不是勾心鬥角,誤入歧途.
- 你必須把重點放在解決問題上,而不是極力證明誰的注意更好.
- 你不需要出色才能起步,但是你必須起步才能出色.
- 如果你是一個有遠見的人,就一定要特別尊重別人的意見.
- 你是一個掌舵者,一定要把握方向,深思熟慮,吸取各方意見.
- 關於決策:設定最終期限,逆向思維,設立仲裁人,支持已經做出的決定
- 盡力貢獻自己的好想法,如果你的想法沒有采納也無需生氣.
- 脫離實際的反方觀點會使爭論變味.不帶個人情緒並不是盲目接受所有的觀點.
排除萬難,奮勇向前
- 動手證明是最有效的方式,把糟糕的代碼放到一邊,立刻重寫.
- 當發現問題時,不要視圖掩蓋這些問題.
- 如果設計或代碼中出現了奇怪的問題,花時間去理解爲什麼代碼會是這樣.
- 如果你找到解決的辦法,但代碼仍舊令人費解,唯一的解決辦法是重構代碼,讓他可讀性更強.
- 如果你沒有馬上理解那段代碼,不要輕易地否定和重寫他們.
- 如果你說天快要塌下來了,但是團隊成員都不贊同.反思一下,也許是你是正確的但你沒有說清楚自己的理由.
- 如果你說天快要塌下來了,但是團隊成員都不贊同.認真考慮下,他們也許是對的.