1将變量命名變成解謎遊戲
圖譯：parseDBMXML 代指什麼：A、解析 DBM XML 。B、解析 DB MXML。C、解析 DB Mx 标記語言。D、解析 DB Mx 機器學習。
首先，從最簡單的開始，在函數命名或變量命名時畫蛇添足，使用不必要的縮寫字母。好的代碼實踐會建議人們在命名時盡量清晰表達其用途，比如
handleFormSubmit
、
getUserConfiguration
，或者是
parseCustomerInformation
。
而糟糕的代碼實踐是在命名中盡可能地使用縮寫和簡寫，這樣接手你代碼的下一位開發者得靠猜測才能搞明白你想做什麼。
像
handleBtnClick
、
getConfig
，或是
parseInfo
這樣的命名就挺随意。從這些名字裡不太看得出函數的用處，但别人做代碼審查的時候還是可以接受它們的。不必要的縮寫更能讓别人困惑，btn、func、config，或者 cb，個個都太難懂了。
變量命名能動的手腳就更多了！有一個未确認使用者的清單？别寫
unconfirmedUsers
，直接用
users
，這樣接手的開發者得通讀你全部代碼才能搞清楚這個變量指的是什麼。對付這位可憐的開發者也别用 discountedProducts，直接用 product 這個名字足矣。
想要再添把火？可以，大小寫就是你的下一個玩具，我向你保證，接手你代碼的同僚絕對會恨死你。别用優秀代碼例子中的
readXmlDocument
這種命名了（縮寫的大小寫應與其他單詞大小寫形式相同），readXMLDocument 才會讓其他的開發者們更仔細地閱讀你的代碼，更認真地讀你的變量名才能想明白你要表達什麼。
當然，這些迷惑手法都會死在代碼稽核階段，但你可不會就此躺平不是？或許是因為懶癌發作不想改，或許是因為你的叛逆個性作祟，但不管怎麼說，你永遠可以誇下海口，在下一次的 PR 中做出修正，并雙手合十祈禱你的同僚會原諒你的罪孽（指不定他們就原諒你了）。
2複雜化代碼
圖譯：我：試圖在一個調用中寫完整個功能
不知道你是否有過證明自己是軟體開發界的 Rick Sanchez（瑞克和莫蒂中的一個奇怪且酗酒的瘋狂科學家）的機會。
你要做的僅僅是對你的代碼進行些不必要的複雜工序。
比如通過一般化的手法，在兩個地方重複利用三行代碼？你要做的也就是寫個接受五個變量的小函數而已。再精明一點，你還可以把這三行代碼縮寫到一個精密的三層嵌套三元操作裡！想象力無極限，我的朋友！
當然，這些會讓應用 更難讀懂也更難維護，但這些負擔大概隻會落到你同僚的肩膀上，對吧？那可真是太棒了！
那麼快來試試，用代碼來證明你才是真正的黑客。我會建議你試試鍊式函數、嵌套條件語句、過度膨脹的設計模式，以及利用程式設計語言中不為人知的小技巧編寫的精妙的單行代碼。如果我們可以用更加神秘的
+new Date()
，那麼為什麼還要用老套的
Date.now()
呢？我相信你同項目的同僚在研究你代碼到底在搞什麼的時候，一定會深深地感謝你的！
請記住，越是過于精巧以及過早優化的代碼，你同僚經手它們時的境遇就會更糟糕。為你所使用的每一個 reduce 函數加十分尊敬分，為每一個遞歸調用加一百分。在項目的最後，你一定會成為一名真正的程式設計高手，加油！
3混亂的 import
圖譯：我：試圖解釋項目的依賴階層
之前我們提到這些絕招很可能在代碼審查階段就不幸落命，但如果你是使用 JS 或 PSP 的 web 開發者，那麼在你所有的檔案開頭大機率都會有一連串的 import 或 use 語句。開發者們在做審查時基本不會管這些東西，他們隻關心那些更有料的部分。
這也就是為什麼依賴是個亂搞代碼的好地方。
試着想象一下，你在 React 中有個叫
UserSubscriptions
的 view，然後再建立個叫
calculateTimeToSubscriptionEnd
的 helper 函數。那麼，現在問題來了，你要把這個 helper 函數放在哪？在存放所有和訂閱或付費相關的域邏輯的單獨檔案裡？多沒意思。不如直接放在你剛建立的 view 旁邊！
再提前規劃下最後建立管理面闆以及這個例子裡的
Subscription
view 的情況，你大可直接從 user 的 view 裡 import 你想要的 helper 函數，畢竟沒人會在乎區區 import 清單。兩個毫不相關的子產品攪在一起，别人再想修改或重構你的代碼就得費好大的功夫。相信我，開發者們最最憎惡的莫過于是結構稀爛的項目。
你說什麼？“這還不夠混亂”？小菜鳥程式員們很可能在短時間内都不會動你的代碼，他們會在你創造的一團亂麻中苦苦掙紮，想着保險起見還是保持原樣最好。而每當有新開發者嘗試了解你的項目結構，都會帶來新一輪的折磨，當開發中更新或者删除了什麼你在 import 中提到的東西，也會讓這份折磨加倍返還。對所有人都有百害而無一益的混亂局面，隻有勇士才能拯救的局面，或許你可以嘗試成為這名勇士？
4運作方式不同的同一函數
圖譯：男：在管理界面我加了個新的使用者相關節點，會傳回新的資料那種
女：是會像其他那些使用者相關節點一樣，接收使用者 ID 的對吧？
男：（你說呢）
女：……是會像其他那些使用者相關節點一樣，接收使用者 ID 的，對吧？
或許你會認為自己是有創造力的，并且很有藝術感的人。請容我向你介紹，這一全新的折磨方式。
世界是瞬息萬變的，沒人說過所有東西都必須一成不變。也沒人說過一緻性和可預測性是優秀開發經驗和成功項目的關鍵。也許真的有人說過，但我們也不一定要聽他們的不是？
我們的任務是通過讓代碼庫中的一個函數擁有一點點的可變性，來毀掉别人的美好一天。
舉例來說，一個驗證函數，資料驗證通過會傳回 True，驗證失敗則會傳回一條失敗資訊。那麼，如果這個函數會在資料正确的情況下傳回 False 或未定義，你的同僚大概就要再多寫幾個情況來處理你的傳回了，這豈不美哉。
當然，你也可以在所有函數中都接受不同形狀的參數。拿上面這張梗圖為例，讓一些函數接受使用者 ID，另一些則在完全可以隻用使用者 ID 的情況下接受整個使用者對象。或許你還可以找到些接受使用者電郵位址的方法？接手你代碼的家夥要面臨的可就是地獄啊。
你甚至還可以再添加一點驚喜的元素，讓一切都變得不可預測起來。管他的一緻性，随機性萬歲！當然，别再惦記着整個代碼庫了，一個檔案一個檔案地改過去多好。工程師有什麼意思，不如做個藝術家快活自在！我相信你的開發者同僚們一定會打心底地恨着你。但這又有什麼用呢，你已早早領先了。
5把代碼複制黏貼得到處都是
圖譯：我的代碼庫：把其他檔案裡的同一段代碼複制黏貼到不同檔案裡
等你這麼做了之後，我相信沒人會想再和你共事了。
别把相同邏輯分散到不同的函數、類、元件裡去。隻複制黏貼你需要的那幾行代碼就夠了。
畢竟，你的代碼是完美且意義非凡的，所有人都要在項目中的不同部分重複看到很多遍才夠。讓你的代碼發光發熱吧！
但你也知道，這并不是你瘋狂複制代碼的原因。在一些更新中，系統會要求開發者們同時更改大量檔案内容。如果測試範圍不夠，某些人可能會忘記删掉一兩次的重複邏輯，并不得不開始第二次甚至是第三次的更新。還有什麼是比在成千上百的檔案中搜尋重複代碼更有趣的事呢？你的同僚們一定會樂在其中的。
記得我說過好的縮寫很難并且非常浪費時間嗎？那麼我們為什麼不直接在需要的地方把代碼複制過去呢？不然的話，你大概還要再花時間向别人解釋你為啥要不斷複制你之前的代碼。我相信你，你一定可以做到的！
6總結
很明顯，這篇文章就是圖一樂。請千萬不要嘗試我在文中描述的這些操作，這可不是什麼可以“賭五毛”的小玩笑。
請一定要在實踐中按相反的來：
- 代碼中的命名保持清晰明了
- 代碼要簡單易懂
- 保持整潔的項目結構
- 記得使用常量以及可預測的界面
- 在保持代碼清晰的同時分割相同邏輯
以及最重要的一點，善待你的同僚們！
在開發社群中流傳着這樣一個說法，在你編寫代碼時，永遠要像是被連環殺人犯接手你的代碼一樣。你可不想被一個連環殺人犯盯上，對不對？而我則認為，你更應該在寫代碼時，想象着如果下一個接手這份代碼的人是你自己，你會怎麼想。在你程式設計時，請一定要問問自己，“如果我早就不記得這些程式是幹什麼的時候，我會樂意看到這些代碼嗎？”
— 本文結束 —