十個讓你變成糟糕的程式設計師的行為

coolshell發表於2012-04-24

  這裡,我們主要討論十個糟糕程式設計師的特徵,主要是需要讓我們去避免和小心的。

  1) 情緒化的思維

  如果你開始使用不同顏色的眼光來看待這個世界的話,那麼你可能會成為一個很糟糕的程式設計師。情緒化的思維或態度很有可能會把自己變成一個怪物。相信你經常可以看到很多很糟糕的程式會使用下面的這些語句:

  • 我的程式不可能有這種問題。
  • Java就是shit。
  • 我最恨的就是使用UML做設計。
  • 需求怎麼老在變,沒辦幹了。
  • 受不了這些人,他們到底懂不懂啊。
  • …… ……

  這些帶著情緒化的思維和態度,不但可以讓你成為一個很糟糕的程式設計師,甚至可以影響你的前途。因為,情緒化通常都是魔鬼,會讓你做出錯誤的判斷和決定,錯誤位元速率的判斷和決定直接決定了你的人生。

  2) 懷疑別人

  糟糕的程式總是說:“我的程式碼一定是正確的,我懷疑編譯器有問題”,“我這應該沒有問題吧,STL庫怎麼這麼難用啊”。我曾經見過有程式設計師這樣使用STL類:map<char*, char*>,當他發現這樣放入字串後卻取不出來,覺得那是STL庫的BUG,然後自己寫了一個map!我的天啊!

  某些時候,過早的下結論是一個很不好的習慣,任何事情都有其原因,只有知道了原因,你才能知道是誰的問題。一般來說,總是自己出的問題。

  3) 過多關注實現,陷入問題細節

  有些時候,當我們面對一個問題或是一個需求的時候,糟糕的程式設計師總是會馬上去找一個解決方案或是實現,這是一個很不好的習慣。設計模式告訴我們,“喜歡介面,而不是實現”就是告訴我們,認清問題的本質和特性要比如何實現更重要。

  • 對於一個客戶的問題來說,首先應該想到的是如何先讓使用者正常工作,如何恢復正在“流血”的系統,而不是把使用者放在一邊而去分析問題的原因和解決方案。
  • 對於解決一個bug來說,重現bug,瞭解原來程式的意圖是首先重要的事,而不是馬上去修改程式碼,否則必然會引入更多的BUG。
  • 對於一個需求來說,我們需要了解的需求後面的商業背景,use case和真實意圖,而不是去討論如何實現。只有瞭解了使用者的真實意圖,實際使用的方式和案例,你才能真正如果去做設計。

  糟糕的程式總是容易陷入細節,爭論於如何實現和實現難題,以及問題的根本原因,而忽略了比這些更重要的東西。只有看懂了整個地圖,我們才知道要怎麼去走。

  4) 使用並不熟悉的程式碼

  糟糕的程式設計師最好的朋友是 Ctrl-C 和 Ctrl-V ,有些時候,他們並不知道程式碼的確切含義,就開始使用它,有證據表明,由拷貝貼上引發的bug佔了絕大多數。因為,程式碼總是隻能在特定的環境下才能正常地工作,如果程式碼的上下文改變了,很有可能使得程式碼產生很多你不知道的行為,當你連程式碼都控制不住了,你還能編出什麼好的程式呢?

  5) 拼命工作而不是聰明的工作

  對於糟糕的程式設計師,我們總是能看到他們拼命地修正他們的bug,總是花非常多時間並重復地完成某一工作。而好的程式可能會花雙倍的時間來準備一個有效的開發環境,工具,以及在開發的時候花雙倍甚至10倍的時間來避免一些錯誤。好的程式設計師總是會利用一切工具或手段來讓自己的工作變得更有效率,總是為在開發的時候儘可能得不出錯。後期出錯的成本將會是巨大的,而且那時改正錯誤的壓力也是巨大的。所以,糟糕的程式通常會讓自己進入一種惡性迴圈,他們看上去總是疲憊的,總是很辛苦的,所以更沒有時間來改善,越沒有時間來改善,就有越多的問題。所以,拼命工作有些時候可能表明你不是一個好的程式設計師。

  6) 總是在等待、找藉口以及抱怨

  當需求不明確的時候,當環境不是很滿意的時候,他們總是在等待別人的改善。出現問題的時候,總是在找藉口,或是抱怨這也不好,那也不好,所以自己當然就沒有做好。糟糕的程式設計師總是希望自己的所處的環境是最好的,有明確的需求,有非常不錯的開發環境,有足夠的時間,有不錯的QA,還有很強的team leader,以及體貼自己的經理,有足夠的培訓,有良好的討論,有別人強有力的支援……,這是一種“飯來張口,衣來伸手”的態度,這個世界本來就不完美,一個團隊需要所有人去奮鬥,況且,如果什麼都變得完美了,那麼,你的價值何在嗎?driving instead of waiting, leading instead of following.

  7) 滋生辦公室政治

  有句話叫“醜女多作怪”,意思是說如果一個自己沒有真實的能力的話,那麼他一定會在其它方面作文章。糟糕的程式設計師也是這樣,如果他們程式編不好的話,比不過別人的話,他們通常會去靠指責別人,推脫責任,或是排擠有能力的人,等等不正常的手段來保全自己。所以,糟糕的程式通常伴隨著辦公室政治。

  8) 說得多做得少

  糟糕的程式設計師總是覺得自己什麼都懂,他們並不會覺得自己的認識和知識都是有限的。這就是所謂的誇誇其談,是的,什麼都做不好的程式設計師能靠什麼混日子呢?就是吹啊吹啊。

  另一個表現方式是他們在評論起別人的程式或是設計,總是能挑出一堆毛病,但自己的程式寫得也很爛。總是批評抱怨,而沒有任何有建設性的意見,或是提出可行的解決方案。

  這些糟糕的程式設計師,總是喜歡以批評別人的程式而達到顯示自己的優秀。

  9) 頑固

  當你給出一打證據說明那裡有一個更好的方案,那裡有一個更好的方向的時候,他們總是會倔強的認為他們自己的做法才是最好的。一個我親身經歷的事例就是,當我看到一個新來的程式設計師在解決一個問題的時候走到了錯誤的方向上時,我提醒他,你可能走錯了,應該是另外那邊,並且我證明了給他看還有一個更為簡單的方法,有。然而,這位程式設計師卻告訴我,“那是我的方法,我一定要把之走下去,不然我會非常難受”,於是,在三天後的程式碼評審中,在經過頑固地解釋以及一片質疑聲中,他不得不採用了我最先告訴他的那個方法。

  這些程式設計師,從來不會去想,也不會去找人討論還有沒有更好的方法,而是堅持自己的想法,那怕是條死路都一往直前,不撞南牆永不回頭。

  10) 寫“聰明”的程式碼

  他們寫出來的程式碼需要別的同事檢視程式語言參考手冊,或是其程式的邏輯或是風格看上去相當時髦,但卻非常難讀。程式碼本應該簡潔和易讀,而他們喜歡在程式碼中表現自己,並嘗試另類的東西,以顯示自己的才氣。是的,只有能力有問題的程式設計師才需要藉助這樣的顯示。

  記得以前的一個經歷,一位英語很不錯的程式設計師加入公司,本來對我們這些英語二把刀來說,我們喜歡看到的是簡單和易讀的英文文件,然後,那位老兄為了展示他的英語如何牛,使用了很多GRE中比較生僻的短語和詞彙。讓大家閱讀得很艱苦。最有諷刺意味的是,有一位native的美國人後來在其郵件中詢問他某個單詞的意思。呵呵。

  你是一個糟糕的程式設計師嗎?歡迎你分享你的經歷。

  相關文件:著名程式設計語錄

相關文章