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

　　

1）文檔

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

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

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

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

2）組件庫(kù)

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

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

3）注釋

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

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

　　如果能讓幾個(gè)組的人都沒(méi)猜出來(lái)含義，那這個(gè)坑挖的非常成功。

4）服務(wù)

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

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

5）監(jiān)控

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

　　性能優(yōu)化量力而行，跑著沒(méi)啥問(wèn)題就行，當(dāng)不能跑的時(shí)候，就重構(gòu)吧。

6）代碼

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

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

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

7）項(xiàng)目

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

　　項(xiàng)目跌跌撞撞能順利上線就行了，接下來(lái)就留給后人來(lái)打補(bǔ)丁，接歷史包袱。

?

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