高效程序員的45個習慣 敏捷開發修煉之道 讀書筆記 第二章 態度決定一切

以前看過相似的書很快就忘了，這樣的書，真正上班加入實際的項目開發中纔有真正的感同身受。

切身體會。

 

作事

blame doesn‘t fix bugs。

在咱們項目中出現問題的時候，常常容易不把解決問題放在最優先級，而是指責犯錯者上面的糾纏，若是你說的話會讓事態更復雜，這無疑是在問題火上澆油，寧肯不說出這樣的話

咱們要問問本身爲了解決這個問題，我可以作些什麼。

真實場景，當項目中的員工未能按照約定的時間完成工做的時候，

咱們更可能是須要如何幫助他完成，而不是指責他效率比較低說這樣傷人的話。

永遠不要在會議中說出傷人的話，指責不會修復bug。

 

若是大部分團隊成員（特別是開發領導者）的行爲都不職業，你就應該主動從這個團隊中離開，尋找更適合本身發展的團隊。

真實場景，領導只會畫大餅，只會告訴你這個完成這個項目很簡單，只須要學習XX技術就能夠了，而沒法給你更多幫助，或者領導層已經混亂了，沒法肯定項目的進展，

你就應該離開，這是一個有遠見的想法，不必眼睜睜地看着本身陷入一個「死亡之旅」的項目中。

 

欲速則不達 Beware of land mines 防微杜漸

千里之提潰於蟻穴，一次又一次的快速修復，每一次都不探究問題的根源，長此以往就造成一個危險的沼澤地，最終會吞噬整個項目的生命。

不要墜入快速的簡單修復之中，要投入時間和精力保持代碼的整潔、敞亮，說明誰是優秀程序員，誰是拙劣的代碼搬運工。

真實場景，咱們常常會遇到這種狀況，出現了一個bug，快速修復確實能夠解決他，只要新加一行代碼或者註釋掉某行，它就能夠工做，可是咱們這樣不假思索的改完代碼真的好？

這樣+1，-1的操做會留下隱患。

 

代碼複審，不要讓開發人員徹底孤立地編寫代碼，花點時間確保團隊成員寫的代碼是可讀和可理解的。

場景，像公司的需求會議評審、功能實現評審、代碼評審，這些真的能很好發現本身代碼的問題，不要懼怕本身出錯，而應該積極的記錄錯誤，並完善問題所在。

咱們寫的代碼更多的是讓別人能看明白和理解，而不是隻有本身明白。

 

單元測試，幫助你天然地把代碼分層，分紅不少可管理、更清晰、更易於理解的小塊（待續）

 

對事不對人

巧妙的提出問題，避免尷尬，

那樣作很蠢（否認我的能力）

那樣很蠢，你忘記考慮他要線程安全（之處明顯的缺點，並否認其觀點）

謝謝，先生，可是我想知道，若是兩個用戶同時登錄會發生什麼狀況（詢問你的隊友，並提出你的顧慮）

第三種方式還能巧妙避免是本身理解錯誤的尷尬， 

 

排除萬難，奮勇前進

當發現問題時，不要試圖掩蓋這些問題，而要有勇氣的站起來，不是向別人抱怨代碼有多麼糟糕，而是給出相應的解決方案，重寫緣由，重寫優勢等等。

每每項目中會發現一些代碼沒法很好地重用，咱們更多的是充滿勇氣的重構它，而不是複製修改，儘量減小項目重複的代碼。最近在項目中就犯了這樣的錯誤。

作正確的事情，要誠實，要有勇氣去說出實情，有時，這樣作很困難，因此咱們要有足夠的勇氣。