核心思想就是越過基礎(chǔ)建設(shè)，復(fù)制黏貼拿起鍵盤就是干，一把梭。

　　

1）文檔

　　文檔一定不能寫，越是復(fù)雜的業(yè)務(wù)邏輯，越是要惜墨如金。

　　什么流程圖、示例代碼、SQL查詢語句、項目組件等都不能有，在一份WIKI文檔中，寫上幾行意思意思，描述下這個業(yè)務(wù)的功能即可，或者就不要有文檔了，一把梭。

　　某些重要業(yè)務(wù)常規(guī)的排錯步驟也不能有，出現(xiàn)問題就讓后人去查源碼和數(shù)據(jù)庫，一步步的調(diào)，基本弄個幾個小時后一般都能查明原因。

　　各類團隊規(guī)范也不必制訂，像團隊的代碼規(guī)范、協(xié)作流程規(guī)范等都不需要存在，有問題口頭傳達即可，一次沒傳達成功，那就再來兩次三次，總歸會有成功的那次，下次繼續(xù)這樣周而復(fù)始。

2）組件庫

　　組件庫怎么能有，各自寫各自的，自己寫完了，絕對不要和其他人分享，就讓它默默地呆在某個文件夾內(nèi)。

　　自己知道有這么多組件就行了，其他人要相關(guān)功能的組件，如果問了，那就口頭說下有這么個組件。

3）注釋

　　越是重要的業(yè)務(wù)，越不要寫注釋，讓后人去猜吧，最多在路由前面加個說明。

　　數(shù)據(jù)庫表、字段的注釋，也不要寫，看表名和字段名就行了，而有些字段值是常量的，它們的含義也一并省略，讓后人繼續(xù)猜。

　　如果能讓幾個組的人都沒猜出來含義，那這個坑挖的非常成功。

4）服務(wù)

　　當前自己組維護的服務(wù)，也記得不要寫，后人遇到問題了，自然會去查那些服務(wù)。

　　給源碼就可以了，一切盡在源碼中。后人如果要查服務(wù)什么功能，就去問運維，運維不知道就看代碼。

5）監(jiān)控

　　讓線上代碼自由自在的跑著吧，不需要監(jiān)控他們的健康情況。有問題運營或客服會反饋，再看源碼也不遲。

　　性能優(yōu)化量力而行，跑著沒啥問題就行，當不能跑的時候，就重構(gòu)吧。

6）代碼

　　一個函數(shù)幾百行是家常便飯，不要解耦，函數(shù)內(nèi)的 if-else 要嵌套的多點，讓人不容易發(fā)現(xiàn)哪個 if 和哪個 else 對應(yīng)。

　　要利用好 JavaScript 弱類型的特點，在一些邊界條件中埋些隱蔽的坑。多用全局變量，以及命名要普通，不要包含語義。

　　多用冷門框架或技術(shù)，配套文檔和資源越少越好的那種，后人難以找到幫助信息，一遇到問題就得查源碼。

7）項目

　　項目為了趕工期，將可配置的地方寫死，邊界條件能省則省，不要考慮擴展，各種臨時方案。

　　項目跌跌撞撞能順利上線就行了，接下來就留給后人來打補丁，接歷史包袱。

?

暫時想到這些，如果你遇到過或經(jīng)歷過哪些挖坑或填坑的經(jīng)歷，歡迎在文末評論區(qū)分享。