您必須在不碰一篇文章告訴您如何提高軟件開發技能的情況下，才能在Internet上搖搖欲墜。 大量文章告訴您如何成為"更好的溝通者"，"團隊合作者"和"不斷學習"。

Photo by JESHOOTS.COM on Unsplash

但是您知道您從未讀過的內容嗎？ 如何變得蹩腳。 沒錯-這篇文章，告訴您二十一種成為糟糕的軟件開發人員的方法。

為什么要浪費時間？ 讓我們開始吧。

1.不要格式化您的代碼

格式化代碼只會使其更具可讀性。 笨拙的編碼人員知道，未格式化的代碼難以閱讀且難以維護。 相信我，如果您不斷使用格式迥異的代碼檢入代碼，它將使您的開發人員發瘋。 而且無論您做什么，都不要使用任何縮進。

2.使用無意義的變量和方法名稱

有意義的變量名只會使代碼更易于理解。 如果您想變得蹩腳，請為變量名使用單個字母。 如果您用完了這些，請使用諸如MsgNand FuncMan之類的簡短而毫無意義的縮寫。 我最喜歡的時間之一是DoStuff方法名稱。

3.不要編寫單元測試

沒有什么比拒絕編寫單元測試更能說明"我編寫糟糕的代碼"了。 它的美麗之處在于，隨著時間的推移，您的代碼會變得越來越糟糕，因為缺乏測試會使更多的錯誤逐漸被發現。

4.盡可能將事物耦合在一起

將您的代碼緊密耦合在一起會帶來各種奇妙的失敗。 首先，它使您的代碼真的很難更改和更新。 其次，它使測試和調試變得非常有趣，因為在應用程序的一部分中進行更改，會導致范圍廣泛且分布廣泛的錯誤出現在陌生的地方。 還有什么比這更糟糕的呢？

5.編寫巨大的方法

這是我的最愛之一。 確保您具有執行各種不同操作的方法。 深度嵌入許多if語句可賺取積分。 幾乎沒有什么比"多次單擊Page Down"按鈕來查看"整個方法"更能喊出"這真是糟糕的代碼了"。

6.寫很多神的類

完全忽略代碼中的"單一責任原則"會給您帶來很多麻煩。 當您可以更輕松地將方法添加到現有類中時，為什么將功能隔離到離散類中？ 讓類承擔多重責任可能會導致惡作劇

7.完全不使用抽象

硬編碼所有內容。 盡可能利用實現。 忽略強大的語言功能，例如抽象類和接口。 這些事情只會使您的代碼更易于維護，而CrAppy Coder并不需要這樣做，出于善意。

8.不要學任何新東西

Crappy Coders認為，軟件開發的所有進步都在他們開始第一份工作的那天就結束了。 嘗試改進您已經知道的內容只會導致您編寫良好的代碼并使用新的和改進的技術。 腳的編碼員拒絕這樣做。

9.編寫糟糕的錯誤報告

如果"在我的機器上工作"不夠好，沒人會說。 確保在提交報告時，該報告對問題的描述不正確，并且沒有任何步驟可重現該問題。 我個人最喜歡的是"此功能已完全損壞"。 這將為需要修復該錯誤的開發人員確保真正糟糕的維護體驗。 如果開發人員離您三個月之久，您將獲得更多的榮譽！

10.不要費心學習工具。

您看，如果記事本不足以滿足您的編碼需求，那么Microsoft永遠不會發貨。 為什么要花時間學習使用Intellisense，鍵盤快捷鍵或任何其他"生產力黑客"？ 它們只是傾向于減少代碼的笨拙性并加快開發過程。

11.如果實際上必須調試，請始終使用控制臺。

好的，所以也許您可能實際上有一天需要修復一個錯誤。 我知道–誰想要這樣做？ 但是，無論您做什么，都不要使用調試器。 相反，只需使用對控制臺窗口的調用或快速彈出對話框的ShowMessage調用即可。 對于熟練的Crappy Coder來說，這已經足夠了。

12.與您的setter和getter產生很多副作用。

這總是很有趣。 確保在setter方法中刪除了某些內容。 當您用getter獲得價值時，請進行更改。 相信我，這很有趣。

13.遵循FRY原則：經常重復自己

Crappy Code的標志是在更改和更新內容方面存在困難。 不斷地在代碼中重復自己是確保更新困難的可靠方法。 使用大量的魔術數字。 為什么要在一個地方聲明常量，而在34個地方可以使用文字呢？

14.不要聽任何有經驗的開發人員

經驗-哼！ 誰需要它？ 那些老混混到底知道什么？ 僅僅因為他們看到了一切，并且犯了菜鳥們犯下的所有錯誤，并不意味著您也不要犯錯。 畢竟，如果您一開始會做得很爛，該如何獲得經驗？

15.失去對對象范圍的完全控制

另一種經典的方法-讓類實例的范圍完全迷失在方法參數的迷宮中。 只要有可能，就可以重用一個對象-為什么當現有實例可以通過七個方法調用鏈在應用程序中途傳遞時，浪費所有這些新調用？ 無法追蹤的內存泄漏是糟糕的編碼的標志。

16.使用很多全局變量

這可能是這里最有價值的提示。永遠不要百分百確定變量的狀態是編寫糟糕代碼的必勝之道。我的意思是，如果您不知道如何設置變量值的位置，以及設置的位置和值，那么肯定不會期望您修復涉及未知狀態的錯誤。

17.不要注意標識符的大小寫

我一直很喜歡這個。 在區分大小寫的語言中特別有效。 當您巧妙地更改JAVAScript中變量名的大小寫時，編寫很難發現的bug變得輕而易舉。 更好嗎？ 互換使用l和1。

18.寫大量無意義的評論

確保使用大量沒有價值的注釋來使代碼混亂，尤其是那些解釋代碼實際執行位置的操作的注釋。 例如，在調用OrderList.Clear之前將//清除訂單列表寫入。 那真的可以廢除您的代碼。 當注釋與它們最初關聯的代碼分開時，此技巧會變得更好。

19.編寫許多否定的布爾表達式

沒有什么能使大腦爆炸，就像帶有許多非修飾符的布爾表達式一樣。 認真的做很多事情，您的代碼將很難閱讀。

20.使用布爾參數使函數做兩件事

這是經典之作-確實使人們混淆了可以執行兩種不同操作的功能：

然后，您可以使用非常模糊且完全蹩腳的方式來稱呼它：

processOrder（False）;

額外的信用為雙重否定！ 完全不可理解！

21.提交巨大的變更集

真正蹩腳的碼農的標志是等待大約兩周才能進行提交，在一個變更集中提交大量不同的變更，然后使用"提交大量變更和修正"作為提交消息。

相信我，僅憑此一項就可以使您成為一個真正的開發者。

結論

所以，有 二十一種方法來編寫代碼，可確保您的代碼糟糕透頂。

糟糕的編碼，大家好！

(本文翻譯自Nick Hodges的文章《Twenty-one ways to be a Crappy Software Developer》，參考：https://medium.com/nickonsoftware/twenty-one-ways-to-be-a-crappy-software-developer-c69e4b39c5df)