核心思想就是越過基礎建設，復制黏貼拿起鍵盤就是干，一把梭。
1）文檔
文檔一定不能寫，越是復雜的業務邏輯，越是要惜墨如金。
什么流程圖、示例代碼、SQL查詢語句、項目組件等都不能有，在一份WIKI文檔中，寫上幾行意思意思，描述下這個業務的功能即可，或者就不要有文檔了，一把梭。
某些重要業務常規的排錯步驟也不能有，出現問題就讓后人去查源碼和數據庫，一步步的調，基本弄個幾個小時后一般都能查明原因。
各類團隊規范也不必制訂，像團隊的代碼規范、協作流程規范等都不需要存在，有問題口頭傳達即可，一次沒傳達成功，那就再來兩次三次，總歸會有成功的那次，下次繼續這樣周而復始。
2）組件庫
組件庫怎么能有，各自寫各自的，自己寫完了，絕對不要和其他人分享，就讓它默默地呆在某個文件夾內。
自己知道有這么多組件就行了，其他人要相關功能的組件，如果問了，那就口頭說下有這么個組件。
3）注釋
越是重要的業務，越不要寫注釋，讓后人去猜吧，最多在路由前面加個說明。
數據庫表、字段的注釋，也不要寫，看表名和字段名就行了，而有些字段值是常量的，它們的含義也一並省略，讓后人繼續猜。
如果能讓幾個組的人都沒猜出來含義，那這個坑挖的非常成功。
4）服務
當前自己組維護的服務，也記得不要寫，后人遇到問題了，自然會去查那些服務。
給源碼就可以了，一切盡在源碼中。后人如果要查服務什么功能，就去問運維，運維不知道就看代碼。
5）監控
讓線上代碼自由自在的跑着吧，不需要監控他們的健康情況。有問題運營或客服會反饋，再看源碼也不遲。
性能優化量力而行，跑着沒啥問題就行，當不能跑的時候，就重構吧。
6）代碼
一個函數幾百行是家常便飯，不要解耦，函數內的 if-else 要嵌套的多點，讓人不容易發現哪個 if 和哪個 else 對應。
要利用好 JavaScript 弱類型的特點，在一些邊界條件中埋些隱蔽的坑。多用全局變量，以及命名要普通，不要包含語義。
多用冷門框架或技術，配套文檔和資源越少越好的那種，后人難以找到幫助信息，一遇到問題就得查源碼。
7）項目
項目為了趕工期，將可配置的地方寫死，邊界條件能省則省，不要考慮擴展，各種臨時方案。
項目跌跌撞撞能順利上線就行了，接下來就留給后人來打補丁，接歷史包袱。
暫時想到這些，如果你遇到過或經歷過哪些挖坑或填坑的經歷，歡迎在文末評論區分享。