如何創造出難以維護的程式碼
前言
 |
| 可以點擊方塊查看每一個項目 |
這個網站是在講述如何寫出無法維護的程式碼．作者從大師那學習了某些技巧，這些技巧是關於如何撰寫出無法維護的程式碼，以至於在你之後需要維護的人需要花費數年的時間，才能做出簡單的更改．
個人感覺，這個網站比較像是反諷，發揮人的創造力，就算是一件爛事，也要把它做到最完美．
1. Naming (命名)
1.1 Single Letter Variable Names (用單字定義變數)
可以使用 a, b, c 來定義變數，讓未來參與維護的人員無法猜透變數的意義．
不使用傳統 for 迴圈大家常會用到的 i, j, k ，改成使用 ii, jj , kk 來噁心其他人．
1.2 Creative Miss-spelling (有創意的錯誤拼寫)
如果必須描述變數或 function 名稱，請務必拼寫要錯誤．且不能全部都拼寫錯誤，需要夾雜正確與錯誤的命名方式．讓人在 Ctrl + Shift + F 全域搜索時充滿困難．
1.3 Be Abstract (抽象)
比方說取得資料．就寫成 getData() 不要充分寫出是要取什麼類型的資料．
1.4 Ａ.C.R.O.N.Y.M.S (縮寫)
就只定義Ａ, B, C，正港的男子漢在定義完成後，不會再額外注釋意義．當然定義成 WTF, NMMD 也是可以的．
1.5 Thesaurus Surrogatisation (使用相近的詞來混淆)
要消除無聊，增加困難，將相同的功能使用不同的詞彙來表達，即使功能是完全相同的．
1.6 Reuse Names (相同命名)
全域變數如果已經命名過，function 內再重複命名一次，迫使維護人員需要仔細確認．
1.7 Bedazzling Names (令人眼花撩亂的名稱)
例如 superman, spider man 讓維護人員很難與真實要執行的程式碼連結．
1.8 CapiTaliSaTion (隨機字母大寫)
cOmputeR, prESidEnt
1.9 Lower Case I Looks a Lot Like the digit 1 (字母 I 和數字 1 混用)
2. Documentation (文件和註解寫法)
2.1 Lie in comments (在註解中說謊)
也可以不在註解中說謊，只要更新程式碼時，不把更新的原因更新到註解上．
2.2 Document the Obvious (在註解中加入廢話)
2.3 Document How not Why (只註解是什麼，不是為什麼)
只紀錄程式的訊息，但不告訴你改怎麼完成操作．當錯誤發生時，維護的人就不會知道該怎麼修復．
2.4 Units of Measure (測量單位)
切記不要紀錄任何值的測量單位，某些值如果需要透過計算才能轉換出來，也可以在註解中稍微修改其公式，加入一些不正確的資訊．
2.5 Avoid Documenting the Obvious (避免留下明顯紀錄)
如果一個 Bug 有 25 個地方需要修改，請不要留下紀錄．在接替你的人沒有完全搞懂程式碼時，無法隨意修改．
2.6 Disparage In the Comments (在程式碼中加入貶低的字句)
2.7 Obsolete Code (過時的程式碼)
確保沒有使用到的程式碼務必把它註解掉，而不是刪除．
3. Testing (測試)
3.1 Never Test (從不做測試)
如果客戶抱怨，告訴他們是操作系統或硬件的問題，他們永遠不知道
3.2 Never, Ever Do Any Performance Testing (永遠不做性能測試)
如果速度不夠快，告訴客戶購買新的機器即可．如果你一做測試，那麼可能就要更改算法或重新制定架構．
3.3 Never Write Any Test Case (不寫任何測試案例)
3.4 Testing is for cowards (測試是懦夫的行為)
真正的工程師是不需要測試程式碼的，一個勇敢的工程師不需要做到這一步，你只是害怕老闆，害怕被客戶抱怨，如果對程式碼有足夠的信心，還要測試什麼呢？
4. Program Design (程式設計)
4.1 Avoid Encapsulation (不要封裝)
為了提高效率，請不要封裝．當使用時還要從外部獲得資訊．全部寫在 function 內部方便查看．
4.2 No Secrets! (沒有任何秘密)
所有變數都宣告成 public，讓後來修改的人很難限制變數的使用．
4.3 Never Validate (從不驗證)
從不檢查外部輸入的資料是否正確，完全信任公司設備，並且信任所有同事和負責操作的人員，即使資料錯誤，也讓它返回合理的正常值．
4.4 Clone & Modify (複製, 修改)
使用 Copy + Paste，且不去了解其中的意義，追求效率．
4.5 Bloated classes (讓 class 非常龐大, 臃腫)
請務必確保每個 class 都非常艱深難懂，使特定程式碼在搜尋時，難度就像在垃圾場中，要去搜尋一小塊吉他撥片一樣．
5. Camouflage (偽裝)
5.1 Code That Masquerades As comments and Vice Veras (將程式碼偽裝成註解使其難以分辨)
5.2 Similar-Sounding Similar-Looking Variable Names (聽起來相似 ,看起來相似的變數名稱)
xy_Z, x_yZ, _xyZ 加入大小寫變換和底線，讓辨識的人感到痛苦．
5.3 Use Continuation to hide variables (使用連接方式)
會讓搜尋時查找不到關鍵字比如說 xy_z 被拆成兩行
5.4 Code names Must Not Match Screen Names (程式碼的名稱和螢幕上的名稱不同)
比方說程式碼定義是電話號碼，螢幕上卻顯示郵遞區號．
6. Coding Obfuscation (混淆程式碼)
6.1 L o n g L i n e s (程式碼非常長)
程式碼越長越好，讓閱讀的人需要來回滑動．
6.2 Early Returns (不要過早使用 Returns)
不要提早中斷判斷，讓他至少執行五層或全部執行完成．
6.3 Never Beautiful (永遠不美化排版)
不要使用 IDE 提供的程式碼整理工具，讓程式碼保持一制性．每個工程師都該保有自己的個性，這是神聖且不可侵犯的．
網站中還有很多有趣的部分，有興趣可以自行查看，以上文章只翻譯其中一部分．
留言
張貼留言