在開發新功能，維護老功能，或者重構優化前人的代碼時，不知有沒有踩過坑，或者覺得前人爲了偷懶而使用了很多不可持續的方法。
業務逐漸豐富後，代碼也日益複雜。複雜的代碼維護成本很高：看的時候很費時間，改的時候也戰戰兢兢的。所以，爲了少犯錯，就很有可能偷懶。看別人的代碼，會發現偷懶的代碼；回過頭看自己的代碼，也有偷懶的地方。
譬如，需要對現有接口進行擴展，爲了不破壞先前的功能，直接將先前接口的的代碼全部複製，然後進行修改，增加新的功能。這種做法很穩妥，因爲對於原有的功能沒有影響，即使出了問題，也是新功能出問題，可以將影響最小化。但是，後人在維護時，就有很大的難度。譬如，擴展接口和非擴展接口都需要針對新場景增加功能，代碼都是相同的。如果後人也偷懶，直接在擴展接口和非擴展接口中使用同樣的代碼，就又增加了維護的難度。如果後人有心，將擴展接口和非擴展接口統一後，在增加新的功能，開發及維護起來都很方便。
再譬如，一個函數入口有很多 switch - case （或者 if - else）語句，翻了 N 頁都還沒有見底。看到這種情形，你已經知道這段代碼不可讀了。但是，你依然需要再增加一個或者幾個 case 語句。你知道不應該這麼做，但是，你更不願意去優化這些代碼。因爲優化就有犯錯的可能，犯錯一般是有懲罰，而主動優化代碼不一定有那麼快的獎勵。所以，你很不情願的把代碼增加進去了，留給後人更多翻頁的機會。但是，反過來想想，如果你主動去優化，通過詳細的測試保證沒有問題，那麼你的勞動會被看到，會被認可。縱然，沒有直接的獎勵，自己也成長了，這也挺好的，重要的本來就是自己的成長。
再譬如，爲了快速開發，你沒有進行詳細的設計就吭哧吭哧的敲擊鍵盤。噼裏啪啦，噼裏啪啦，寫的很盡興，功能也逐漸實現，心裏也挺有成就感的。你告訴自己，等功能調試通過了，再對代碼進行優化，可是後來，再也沒有考慮完善自己的代碼。突然有一天，回頭看，代碼怎麼這麼難看，怎麼什麼功能都揉在一起，根本就沒有經過設計嘛，對於有些代碼，自己都不清楚爲什麼那麼寫，沒有註釋，也沒有文檔說明。這個時候，即使有心優化完善，也不敢了。後人就更不敢改了，那些代碼只能默默的睡在那兒。
再譬如，一段代碼複用性很高，很多地方都在用。你需要用時，直接複製過來。而不是把公用的代碼提取成函數，簡化調用關係，後續的維護也容易。如果需要增加新的代碼，只需在提取的函數中增加就好了，不用在很多地方一一增加。如果不進行提煉，需要新增功能時，很有可能只增加一個地方，畢竟需求是在那個場景下暴露的。如果對整體代碼不熟，哪裏知道還有其他地方也需要增加該功能。
再譬如，多線程下的競態，直接用各種玄學的 sleep 函數減少出現的頻率。根本不去思考如何徹底解決競態。如果覺得自己沒能力解決，可以問身邊的大佬。如果解決起來確實很難，可以專門投入人力進行攻關。再不濟，應該給後人留些遺產，詳細說明一下原因。
再譬如，使用各種變量的組合進行各種狀態的切換，自己看的一頭霧水不說，後人就更看不懂了。這樣的代碼，自己以後不會看，因爲太費腦了，後人更不願意看，除非被逼着。
再譬如，代碼沒有註釋，函數名、變量名很隨意，封裝性很差等等。
以上的偷懶，有些自己也會犯，有些不會。有則改正，無則加勉了。
