Quora 上看到一篇不錯的文章,原文為 What are the characteristics of a bad software engineer?

以下為筆者翻譯的版本,在 Quora 的授權條款下,譯文採創用 CC 4.0 姓名標示授權,轉載請註名原文出處及譯者姓名。Quora 原作保留收回授權的權利。

以我個人的經驗,糟糕的程式設計師具有以下這些特質:

  1. Stack Overflow 機器人:這種人遇到問題時,會靈活地使用 Google 搜尋,並採用所找到的第一個結果(按:好的答案通常在 Stack Overflow 上)。

    問題不在於從 Stack Overflow 上抄答案回來用,因為 Stack Overflow 上面的資料確實比多數官方手冊來的豐富與完整。所以請不要誤會我的意思,上網找答案就算不是最棒的途徑也屬上上策。問題在於不加理解就機械化地採用網路上的答案,甚至也不管適不適用於自己的問題。許多人居然會覺得論壇上的說法比他們眼前的程式碼更可靠。

  2. 我不是測試人員:我不需要測試自己的程式碼,那是測試人員的工作。

    我不認為這種態度在這個敏捷開發方法成熟的時代已經式微。還是有一些原因造成他們不願改變習慣去測試自己的程式碼。其中一部分來自於對設定測試環境沒有興趣,另一部分是對測試這門學問沒有通盤的認識。(還有一部分是開發人員社群對測試人員存有不便明說的輕蔑。)

  3. 討厭手冊:有些人好像認為手冊必須要押韻,而他們沒有那種文學素養,所以那自然不會是他們的工作。

    一點淺見:這是活躍的程式計畫的頭號敵人。好的程式不是那種酷炫功能多如繁星的,而是那種具備一些多數人需要的好功能且程式碼持續被許多開發人員閱讀、修改和更新的。這類不喜歡技術交流和精確、詳盡的手冊的開發人員,是公司邁向成功的最大阻力。

  4. 程式碼很醜:我的程式碼可以跑,但是:

    • 我喜歡為變數取名叫 x、flag、str、arr 等等。
    • 我絕大多數的程式碼都集中在一個很長很長的函式裡。
    • 沒有縮排。
    • 沒有一致的風格和規則。
    • 到處都是全域變數。

    這一項是最令我困擾的。也不是說程式寫得不好啦,這裡面還是有可能會有超猛的程式碼。但我打個比方,如果一串鑽石項鍊掛在像酷斯拉那麼大的超巨型噁心怪蟲的屍體上被埋葬於地底,就再也不會有人找到它了。就算被找到,也不會有人想要清理它甚或戴上它。

  5. 短線投機客:他會不斷地寫出程式給你,但是不會嘗試深入瞭解問題,對程式應用領域的背景知識也全無興趣。

    給他一些工作,他就算加班也會使命必達地交給你一個會動的程式。但也僅止於此。有時候開發人員具備一些自私的心態,促使他不只關心截止日期,也想從處理的事物中學到東西是很重要的。

  6. 切割達人:

    「那不是我做的。」

    「這看起來真糟糕。」

    「不是我的問題。」

    「這不是我修改的程式碼造成的問題,而是用到我的程式碼的人沒寫對。」

    「我超討厭這個(一天要講十遍)。」

    「這我修不好,請去把寫這程式的人找來親自處理。」當初寫出錯誤的人已經離職了,不知道什麼時候會輪到你?

  7. 夜郎自大:「我的方法」或「這才是王道」是他們的座右銘。

    但他說來說去都是在比較他的想法和你的想法,而不是這個案子的規格。不然就是拿你的解法和他的解法做比較,隨之而來的就是彼此間的爭論。有時候他們會一直不斷挑剔你的程式碼,因為就算你的程式碼會動、通過測試、看起來也很工整,仍舊令他們感到不舒服。這種人是開發效率的瓶頸,而且通常抗壓性很差。他們對團隊其實沒什麼幫助,雖然他們很可能是資深的開發人員。

  8. 固步自封:例如當 Java 的程式設計師聽到必須要用 Python 來寫一支程式,馬上就會石化給你看。

    有些人對於學習新事物感到很痛苦,有些人則很怕寫東西進資料庫。他們會用盡一切方法來避免離開自己的舒適圈,此外有些迷信也使得他們不敢碰某些特定領域的東西。以我自己的經驗來說,這種現象在新手中是很常見沒錯,但一個好的開發人員即便在他們不熟悉的領域也樂於探索。

  9. 粗心:忘記備份、同一個案子的程式碼有很多版本分別放在不同的資料夾、在產品版本的程式中印出開發用的除錯訊息等等。

    這是另一個常見的新手現象,在他的經驗值提高後就會有所改善。

  10. 懶惰的假高手:他們對能夠透過一些特殊的技巧讓程式運作感到自豪,會用一些神奇的方法來解決看起來很複雜的問題。

    不過根據我的經驗,這些招式十有八九都只是化妝術。那些怪招都嘛很爛,因為不知道什麼時候會爆炸,而且之後在修複、重構上花的時間會比現在一次做好還要多。