Quantcast
Channel: 工程師 – TechOrange
Viewing all articles
Browse latest Browse all 585

糟糕工程師症候群的徵兆之一:程式寫很快又愛放槍,錯了還繼續嘴硬

$
0
0

有一種說法是,「一個偉大工程師相當於 10 個平庸的工程師」。沒有人願意被貼上了糟糕工程師的標籤,但一個可悲的事實是,很多開發人員沒有意識到他們自己就屬於這一群體。沒有人願意問自己:我是一個糟糕的開發人員嗎?

  • 糟糕的開發人員

如果你還是 coding 新手,並且擔心自己寫的是糟糕的代碼,那麼可能你還不是高手。不過,你也不用因此灰心喪氣,因為只要你不是無可救藥的,那就都還有改進的餘地。

首先讓我們先來了解關於糟糕的開發人員的兩種主要類型:

  1. 牛仔 (為了閱讀方便,後面會統稱「牛仔」來指代這種類型)
  2. 平庸的開發人員

從本質來看,這兩者是相同的,但是它們通常表現出不同的行為。

  • 牛仔工程師

牛仔工程師會毀掉一個團隊,他們喜歡單槍匹馬的做項目,並且項目往往都很短命。

那些從來沒有受到過任何編寫可用代碼的指導,自學成才的工程師通常會有成為牛仔工程師的危險,並且很多優秀的,有經驗的工程師有可能在他們的編碼職業生涯的初期,就是一個牛仔工程師。那麼,什麼是牛仔工程師的關鍵屬性呢?

  • 1. 編碼速度非常快

通常,這種類型的不良開發者開發新功能的速度要遠遠快過平均值,然而,不幸的是,那麼不懂代碼的人,因此會認為這些「快槍手」很厲害(這只會進一步讓這些牛仔在自我膨脹的道路上越走越遠)。這類開發人員在獨自工作的時候最佳,在客戶對時間要求特別緊迫只要盡快實現功能的時候最適合。

牛仔編碼速度非常快——這意味著,他們的代碼沒有對可維護性有任何規劃。所以這就會導致……

  • 2. 凌亂、不可讀的代碼

快速代碼設計創建出來的項目常常會亂得一塌糊塗(或者更確切地說,他們就沒有進行代碼設計)。這種混亂的代碼,通常被稱為「意大利麵條式代碼」,這指的是它的形狀,而不是味道。意大利麵條式代碼難於理解,並且通常沒有必要那麼龐大和複雜,從而導致了其他人難於理解工程師的所作所為,因此這種代碼通常是維護的噩夢。這意味著如果有人不幸和一個牛仔一起工作,那麼整體生產力就會大幅度下降。

凌亂的代碼會導致……

  • 3.Bug,無處不在的 bug

如果一家公司的軟體在變大和變得更加複雜之後,他們的代碼仍然是一堆意大利麵條,那麼它就會成為一個等待爆炸的定時炸彈。在最壞的情況下,其後果甚至會像豐田汽車意外加速一樣嚴重。眾所周知,豐田汽車召回是一場災難。

更重要的是,意大利麵條式代碼是不可擴展的。這意味著如果增加新功能,那麼這種代碼就像行走在雷區上——不知道什麼時候,就會爆炸。這通常是因為牛仔將每個功能都混合在一起,於是任何變化都可能會破壞軟體。如果有更好的代碼設計和 / 或單元測試,或許就能阻止這種情況,但是,牛仔不在乎他們的代碼是否是可用的,也不想編寫測試(因為需要時間)。

更甚者,從糟糕的設計決策衍生出的代碼結構方式,通常是不可測試的,甚至是無法調試的。在牛仔程序員身上,還有一種常見的情況是,在他們迅速「修復」一些 bug 的同時,創造出了更多的 bug。因此他們總是感覺很忙,就像英勇的消防員,疲於到處滅火。

總而言之,每一個糟糕開發人員創造的 bug 和錯誤都會導致消耗生產力。哪怕剛開始的時候,他們看上去很牛,總是能按時完成其他開發人員不敢輕易允諾的編碼任務,但是這是以各種意外錯誤頻頻降臨為代價的,而這原本可以通過優秀開發人員的精心設計和簡潔代碼編寫扼殺在襁褓中。

如果你超過 80%的開發時間都花在了調試自己的代碼上,並且調試過程像一場噩夢的話(即這邊解決了一個 bug,那邊又出來了另一個 bug),那麼說明代碼庫不佳,並且你需要改進你的代碼。

  • 自大

有的牛仔並不壞,因為他們只是根據管理 / 客戶不可能的期限要求,才生產出了意大利麵條式代碼(但是,那些重視自己代碼的開發人員會選擇離開這樣的公司或拒絕這樣的客戶)。很多初學者和初級開發人員是因為沒有編碼計劃,因而生產出了一堆有 bug 的代碼,但有時是因為他們缺乏問題的經驗,從而做出了錯誤的決定。

這些初學者通過接受來自於資深的優秀的開發者的指導,是可以改正的。但是,如果他們的身邊盡是和他們一樣或平庸的開發人員,那麼他們就會陷入自我感覺良好的錯覺中。

只要你願意為自己的錯誤承擔責任,只要你願意從錯誤中學習,那麼你就不算是一個糟糕的開發人員。

使得這些工程師變得糟糕的最重要​​的屬性,是自大。

糟糕的工程師認為他們的代碼是完美的,只會歸咎於是客戶的愚蠢導致了程序的崩潰,而不是反思——為什麼他們做的軟體會崩潰。牛仔通常是自私的開發者,因為他們不會對那些不得不為他們「擦屁股」的開發人員抱有一絲同情心。

更為重要的是,這些自大的工程師總是認為自己的智力高人一等,總是自認為別人沒有註釋不行,總是認為那些不明白他們代碼的人是因為太愚蠢,但從來不曾想想為什麼大家不理解他們的代碼。這種一直堅定不移地認為他們自己是對的,總是認為自己高人一等的結果就是,沒有與人好好溝通就自作主張地構建了可能會給團隊帶來很多問題和麻煩的功能。還有的人由於(毫無正當理由地)深信自己的代碼更好,因而有時候甚至會迴避最佳做法或標準作法。

最糟的是,糟糕的工程師都不願意聽別人說教,不願意從錯誤中學習,因為他們不承認他們犯了錯誤,正如前面提到的,他們通常會推卸責任。

請注意,這並不意味著牛仔在現實中就是難相處或低智商的人——也許他們就是你遇到過的最和藹親切的人——但是,在他們面對批評的時候,卻有著一種根深蒂固的自大和不願意承擔過錯責任的心態。

  • 平庸的開發者

這裡我指的平庸意味著「不能勝任」。在某些方面,平庸的開發者比牛仔更糟,因為他們知道自己不能夠勝任,卻不願意去努力,滿足於停留在技能階梯的底層。

不像牛仔,平庸的開發者通常對寫程式缺乏興趣,因此在理解概念方面有困難。他們需要很長的時間來創建一些東西,同時生產的代碼欠佳並且充滿問題。他們通常對毫無沒有激情 / 興趣可言,他們在學習新技術時進展緩慢,或通常沒有實際的操作經驗。

也許平庸的開發者不像牛仔那樣具有破壞性,這是因為他們處在一個團隊中,但他們絕對不會為團隊帶來任何好處,並且他們提出的解決辦法總是劣於優秀的開發人員(他們常常會因為錯誤的決策,導致滿是 bug/ 低效的代碼)。

關於平庸的開發者,我就不再多說什麼了。最差的估計是,他們可能會拖累整個團隊,最好的情況是,他們勉勉強強也算是在最後期限內完成了任務。

  • 問題的核心

促使開發者盤踞糟糕寶座的核心是因為他們缺乏成為一個更好工程師的願望。糟糕的工程師對目前的行為方式感到滿意和舒適。更糟的是,牛仔和平庸工程師通常自認為知道那些其實他們不知道的東西。

更重要的是,糟糕工程師往往對學習新事物不感興趣,因此不會有意地去改進自己。

這也是為什麼在糟糕工程師的代碼上經常可以發現大量複製& 貼上的東西,因為他們基本上不會去搞清楚為什麼有些地方這些代碼奏效而有些地方不奏效。複製& 貼上本身並不是壞事,但只有在下面這些情況下:

  1. 你知道你正在在做什麼(很多糟糕的開發人員會自以為他們知道自己在做什麼)
  2. 確信複製&貼上的代碼會有效工作
  3. 只用於測試 / 檢驗

糟糕的開發者通常只會復制粘貼 StackOverflow 代碼,而不是去理解它,或者調整解決方案以匹配他們自己的代碼。

此外,那些始終堅持所謂的「最佳做法」而不去理解為什麼這些做法會被認為是最好的工程師也可以被歸類為糟糕的工程師。

總而言之,也許你並不需要知道一個大型的複雜框架的每一個細節的工作原理。但是,你至少應該弄清楚你使用的部分是如何工作的。

糟糕的工程師從來不會從自己的錯誤中吸取教訓,要麽是因為不承認他們犯了錯誤,要么是因為他們缺乏學習的慾望,要么兩者皆有。

每個人都會犯錯,每個工程師都會製造 bug,這沒有什麼大不了。但是,如果你總是在重複相同的錯誤,那就意味著你是一個不學習的糟糕的開發者。

  • 優秀的開發人員

經過漫談有關與糟糕開發者的相關特徵,你可能對是什麼造就了優秀開發人員已經有了一個模糊的想法。優秀的開發人員是開發隊伍的中堅力量,並且他們通常具有以下特徵。

有著一種山外有山人外有人的謙遜認識,願意為錯誤承擔責任,從錯誤中學習,寫出的代碼是可讀的、結構化的、經過可靠設計的、可被輕鬆調試的,努力理解事物的工作原理,和團隊中的其他人有著良好的溝通 / 協作,虛心接受批評和開放對待不同的方法,保持學習新技術的心態,樂於解決問題等等。

的確,關於何為高質量代碼是很難衡量的(這就是為什麼我沒有將它包含在特徵中,但是這確實是組成開發人員優秀的一個重要方面)。

那麼我們怎麼知道自己寫的代碼是否良好呢?請看漫畫中的完美解釋。

  • 真正優秀的開發人員

下面這兩種類型的開發人員,才是真正能夠幫助團隊的開發人員:

  1. MVP
  2. 樂於助人的開發人員
  • MVP

MVP 型開發者不希望只是簡單地解決問題,他們會努力尋找解決問題的最佳方法。他們能應付挑戰,因此在困難的任務面前總是表現出色——這也是為什麼 MVP 型開發者比大多數開發人員更富有生產力的原因。正是由於這種愛挑戰的冒險心態,所以如果雇主分配給他們的工作太容易或太平庸的話,可能會留不住他們,因為一旦他們感到厭倦的話,可能就會選擇離開。

由於 MVP 型開發者對自己工作的自豪感,因此他們常常會在質量和性能上吹毛求疵。事實上,他們會考慮很多邊緣情況,在發生之前就仔細斟酌。在某些情況下,他們是自己的 QA 工程師,會在用戶之前先檢驗自己的代碼。他們不會因為所謂的最佳實踐,就盲目地去做 TDD,但是他們會設計程式,從而大大減少調試的時間。因此,一個 MVP 型工程師的生產效率至少是一個糟糕工程ㄕ的 10 倍。

MVP 型開發者有著強烈的好奇心,會不惜一切代價地去尋找事物為什麼工作或不工作的原因。他們會花很多時間來閱讀有關寫程式的內容,以便於跟上新技術,但卻不會隨大流,因為他們更感興趣的是靠自己去找出問題的根源。他們非常熱愛編碼,所以經常在業餘時間寫程式,或者是搗鼓業務項目,或者是嘗試新的技術、工具和語言。

最後,MVP 型開發者自信且謙遜,因為他們始終牢記,三人行必有我師,他們喜歡和更優秀的人才一起合作,因為他們能從這些更好的開發人員身上學習。

  • 總結

要想成為一個優秀的,甚至是偉大的開發人員,最重要的因素是自己。也許這需要天賦和一種真正與生俱來的激情,才能成為頂尖的工程師,但只要對程式有興趣,任何人都可以是一個好的工程師。如果你不想成為一個優秀的工程師,那麼沒有人,可以幫你實現。你才是自己最大的敵人和對手,你的目標應該始終是成為一個比​​現在更好的工程師。

(本文獲碼農網授權刊載,原文Everything you need to know about bad programming styles,未經授權不得轉載)

  • 延伸閱讀

未來程式設計的 9 大猜想,其中之一就是 JavaScript 將成為主宰語言
工程師生涯 30 年:真希望在菜鳥時期就懂得的這些事
簡直是個老不死!年度工程師最愛程式語言 JAVA 勇奪第一名
iChef 共同創辦人:台灣開發者請為你的專業找價值、技術找舞台


Viewing all articles
Browse latest Browse all 585

Trending Articles