在开发新功能，维护老功能，或者重构优化前人的代码时，不知有没有踩过坑，或者觉得前人为了偷懒而使用了很多不可持续的方法。
业务逐渐丰富后，代码也日益复杂。复杂的代码维护成本很高：看的时候很费时间，改的时候也战战兢兢的。所以，为了少犯错，就很有可能偷懒。看别人的代码，会发现偷懒的代码；回过头看自己的代码，也有偷懒的地方。
譬如，需要对现有接口进行扩展，为了不破坏先前的功能，直接将先前接口的的代码全部复制，然后进行修改，增加新的功能。这种做法很稳妥，因为对于原有的功能没有影响，即使出了问题，也是新功能出问题，可以将影响最小化。但是，后人在维护时，就有很大的难度。譬如，扩展接口和非扩展接口都需要针对新场景增加功能，代码都是相同的。如果后人也偷懒，直接在扩展接口和非扩展接口中使用同样的代码，就又增加了维护的难度。如果后人有心，将扩展接口和非扩展接口统一后，在增加新的功能，开发及维护起来都很方便。
再譬如，一个函数入口有很多 switch - case （或者 if - else）语句，翻了 N 页都还没有见底。看到这种情形，你已经知道这段代码不可读了。但是，你依然需要再增加一个或者几个 case 语句。你知道不应该这么做，但是，你更不愿意去优化这些代码。因为优化就有犯错的可能，犯错一般是有惩罚，而主动优化代码不一定有那么快的奖励。所以，你很不情愿的把代码增加进去了，留给后人更多翻页的机会。但是，反过来想想，如果你主动去优化，通过详细的测试保证没有问题，那么你的劳动会被看到，会被认可。纵然，没有直接的奖励，自己也成长了，这也挺好的，重要的本来就是自己的成长。
再譬如，为了快速开发，你没有进行详细的设计就吭哧吭哧的敲击键盘。噼里啪啦，噼里啪啦，写的很尽兴，功能也逐渐实现，心里也挺有成就感的。你告诉自己，等功能调试通过了，再对代码进行优化，可是后来，再也没有考虑完善自己的代码。突然有一天，回头看，代码怎么这么难看，怎么什么功能都揉在一起，根本就没有经过设计嘛，对于有些代码，自己都不清楚为什么那么写，没有注释，也没有文档说明。这个时候，即使有心优化完善，也不敢了。后人就更不敢改了，那些代码只能默默的睡在那儿。
再譬如，一段代码复用性很高，很多地方都在用。你需要用时，直接复制过来。而不是把公用的代码提取成函数，简化调用关系，后续的维护也容易。如果需要增加新的代码，只需在提取的函数中增加就好了，不用在很多地方一一增加。如果不进行提炼，需要新增功能时，很有可能只增加一个地方，毕竟需求是在那个场景下暴露的。如果对整体代码不熟，哪里知道还有其他地方也需要增加该功能。
再譬如，多线程下的竞态，直接用各种玄学的 sleep 函数减少出现的频率。根本不去思考如何彻底解决竞态。如果觉得自己没能力解决，可以问身边的大佬。如果解决起来确实很难，可以专门投入人力进行攻关。再不济，应该给后人留些遗产，详细说明一下原因。
再譬如，使用各种变量的组合进行各种状态的切换，自己看的一头雾水不说，后人就更看不懂了。这样的代码，自己以后不会看，因为太费脑了，后人更不愿意看，除非被逼着。
再譬如，代码没有注释，函数名、变量名很随意，封装性很差等等。
以上的偷懒，有些自己也会犯，有些不会。有则改正，无则加勉了。
