目前咱們程序員客棧www.proginn.com全部的開發者都是通過實名認證簽約的,可是就算這樣仍是有不少開發者,在開發過程當中表現出做爲一名程序員不合格的地方,這些人咱們發現後就會取消簽約,下面以我我的的經驗,糟糕的程序員具備如下這些特質:程序員
1,Stack Overflow機器人:這種人遇到問題時,會靈活地使用Google搜尋,並採用所找到的第一個結果(按:好的答案一般在Stack Overflow上)。數據庫
問題不在於從Stack Overflow上抄答案回來用,由於Stack Overflow上面的數據確實比多數官方手冊來的豐富與完整。因此請不要誤會個人意思,上網找答案就算不是最棒的途徑也屬上上策。問題在於不加理解就機械化地採用網絡上的答案,甚至也無論適不適用於本身的問題。許多人竟然會以爲論壇上的說法比他們眼前的代碼更可靠。網絡
2,我不是測試人員:我不須要測試本身的代碼,那是測試人員的工做。學習
我不認爲這種態度在這個敏捷開發方法成熟的時代已經形式漸微。仍是有一些緣由形成他們不肯改變習慣去測試本身的代碼。其中一部分來自於對設定測試環境沒有興趣,另外一部分是對測試這門學問沒有通盤的認識。(還有一部分是開發人員社羣對測試人員存有不便明說的輕蔑。)測試
3,討厭手冊:有些人好像認爲手冊必需要壓韻,而他們沒有那種文學素養,因此那天然不會是他們的工做。blog
一點淺見:這是活躍的程序計劃的頭號敵人。好的程序不是那種酷炫功能多如繁星的,而是那種具有一些多數人須要的好功能且代碼持續被許多開發人員閱讀、修改和更新的。這類不喜歡技術交流和精確、詳盡的手冊的開發人員,是公司邁向成功的最大阻力。開發
4,代碼很醜:個人代碼能夠跑,可是:產品
我喜歡爲變數取名叫x、flag、str、arr等等。效率
我絕大多數的代碼都集中在一個很長很長的函式裏。重構
沒有縮排。
沒有一致的風格和規則。
處處都是全局變數。
這一項是最令我困擾的。也不是說程序寫得很差啦,這裏面仍是有可能會有超猛的代碼。但我打個比方,若是一串鑽石項煉掛在像酷斯拉那麼大的超巨型噁心怪蟲的屍體上被埋葬於地底,就不再會有人找到它了。就算被找到,也不會有人想要清理它甚或戴上它。
5,短線投機客:他會不斷地寫出程序給你,可是不會嘗試深刻了解問題,對程序應用領域的背景知識也全無興趣。
給他一些工做,他就算加班也會使命必達地交給你一個會動的程序。但也僅止於此。有時候開發人員具有一些自私的心態,促使他不僅關心截止日期,也想從處理的事物中學到東西是很重要的。
6,給本身找理由:
「那不是我作的。」
「這看起來真糟糕。」
「不是個人問題。」
「這不是我修改的代碼形成的問題,而是用到個人代碼的人沒寫對。」
「我超討厭這個(一天要講十遍)。」
「這我修很差,請去把寫這程序的人找來親自處理。」當初寫出錯誤的人已經離職了,不知道何時會輪到你?
7,夜郎自大:「個人方法」或「這纔是王道」是他們的座右銘。
但他說來講去都是在比較他的想法和你的想法,而不是這個案子的規格。否則就是拿你的解法和他的解法作比較,隨之而來的就是彼此間的爭論。有時候他們會一直不斷挑剔你的代碼,由於就算你的代碼會動、經過測試、看起來也很工整,仍舊令他們感到不舒服。這種人是開發效率的瓶頸,並且一般抗壓性不好。他們對團隊其實沒什麼幫助,雖然他們極可能是資深的開發人員。
8,固步自封:例如當Java的程序員聽到必需要用Python來寫一支程序,立刻就會臉色給你看。
有些人對於學習新事物感到很痛苦,有些人則很怕寫東西進數據庫。他們會用盡一切方法來避免離開本身的溫馨圈,此外有些迷信也使得他們不敢碰某些特定領域的東西。以我本身的經驗來講,這種現象在新手中是很常見沒錯,但一個好的開發人員即使在他們不熟悉的領域也樂於探索。
9,粗心:忘記備份、同一個案子的代碼有不少版本分別放在不一樣的文件夾、在產品版本的程序中印出開發用的除錯信息等等。
這是另外一個常見的新手現象,在他的經驗值提升後就會有所改善。
10,懶惰的假高手:他們對可以透過一些特殊的技巧讓程序運做感到自豪,會用一些神奇的方法來解決看起來很複雜的問題。
不過根據個人經驗,這些招式十有八九都只是化妝術。那些怪招都嘛很爛,由於不知道何時會爆炸,並且以後在修復、重構上花的時間會比如今一次作好還要多。