靈活開發修煉之道——高效程式員的45個習慣二（态度決定一切）

傳統的軟體開發圖書一般先介紹一個項目的角色配置，然後是你需要産生那些工件——文檔、任務清單、甘特圖等，接着就是規則制度，往往是這樣的。而靈活方法的世界則有些不同。靈活依賴人，而不是依賴于項目的甘特圖和裡程表，圖表、內建開發環境或者設計工具，它們本身都無法産生軟體，軟體是從你的大腦中産生的。而它不是孤立的大腦活動，還會有許多其它方面的因素：個人情緒、辦公室文化、自我主義、記憶力等。它們混為一體，态度和心情的瞬息變化都可能導緻巨大的差别。

隻有在對項目、工作、事業有一個專業的态度時，使用靈活方法才會生效。如果态度不正确，那麼所有的這些習慣都不管用。有了正确的态度，才可以從這些方法中完全受益。下面是一些習慣和建議：

[b](一)、做事：[/b]

指責不會修複BUG，把矛頭對準問題的解決辦法，而不是人。這是真正有用處的正面效應。

切身感受：勇于承認自己不知道答案，這會讓人感覺放心。一個重大的錯誤應該被當作是一次學習而不是指責他人的機會。團隊成員們在一起工作，應該互相幫助，而不是互相指責。

[b](二)、欲速則不達：[/b]

不要墜入快速的簡單修複之中。要投入時間和精力保持代碼的整潔、敞亮。

1、不要孤立地編碼：團隊成員花些時間閱讀其他同僚寫的代碼，能確定代碼是可讀和可了解的。實作代碼複審，不僅有助于代碼更好了解，而且是發現bug最有效的方法之一。

2、使用單元測試：單元測試幫助你很自然地把代碼分層，分成很多可管理的小塊，這樣就會得到設計更好、更清晰的代碼。

切身感受：在項目中，代碼應該是很亮堂的，不應該有黑暗死角。你也許不知道每塊代碼的每個細節，或者每個算法的每個步驟，但是你對整體的相關知識有很好的了解。沒有任何一塊代碼被警戒線或者“切勿入内”的标志隔離開。

[b](三)、對事不對人：[/b]

讓我們驕傲地應該是解決了問題，而不是比較出誰的主意更好。

切身感受：一個團隊能夠很公正的讨論一些方案的優點和缺點，你不會因為拒絕了有太多缺陷的方案而傷害别人，也不會因為采納了某個不甚完美（但是更好的）解決方案而被人忌恨。

平衡的藝術：

1、盡力貢獻自己的好想法，如果你的想法沒有被采納也無需生氣。不要因為隻是想展現自己的想法而對拟定的好思路畫蛇添足。

2、脫離實際的反方觀點會使争論變味。若對一個想法有成見，你很容易提出一堆不太可能發生或不太實際的情形去批駁它。

3、在開始尋找最好的解決方案之前，大家對“最好”的含義要先達成共識。在開發者眼中的最好，不一定就是使用者認為最好的。反之亦然。

4、隻有更好，沒有最好。

5、不帶個人情緒并不是要盲目地接受所有的觀點。用合适的詞和理由去解釋為什麼你不贊同這個觀點或方案，并提出明确的問題。

[b](四)、排除萬難，奮勇前進：[/b]

做正确的事，要誠實，要有勇氣去說出實情。有時，這樣做很困難，是以我們要有足夠的勇氣。

切身感受：勇氣會讓人覺得有點不自在，提前鼓足勇氣更需要魄力。但有些時候，它是掃除障礙的唯一途徑，否則問題就會進一步惡化下去。鼓起你的勇氣，這能讓你從恐懼中解脫出來。

平衡的藝術：

1、如果你說天快要塌下來了，但其他團隊成員都不贊同。反思一下，也許你是正确的，但你沒有解釋清楚自己的理由。

2、如果你說天快要塌下來了，但其他團隊成員都不贊同。認真考濾一下，他們也許是對的。

3、如果設計或代碼中出現了奇怪的問題，花時間去了解為什麼代碼會是這樣的。如果你找到了解決辦法，但是代碼仍然令人費解，唯一的解決辦法是重構代碼，讓它可讀性更強。如果你沒有馬上了解那段代碼，不要輕易地否定和重寫他們。那不是勇氣，而是魯莽。

4、當你勇敢地站出來時，如果受到了缺乏背景知識的抉擇者的抵制，你需要用他們能夠聽懂的話語表達。節約資金、獲得更好的投資回報，避免訴訟以及增加使用者利益，會讓論點更有說服力。

5、如果你在壓力下要對代碼品質作出妥協，你可以指出，作為一名開發者，你沒有職權毀壞公司的資産。