业务逻辑代码有时候会成为接手的人觉得特别差的屎山代码。
多为以下原因：
- 第一手实现者，或因为能力或思考不足，设计实现问题
- 经多人经手，需求反复改，或赶deadline，先让功能工作起来，后期也没时间再优化
可能我们因为一些需求会需要修改屎山代码，个人经验，做优化的时候，步子不要迈太大，特别是遇到屎山代码的时候。不要一次优化原本内容，还同时也把看起来顺手就可以改的业务逻辑也优化了。特别是一些tricky代码，改了容易出一些特定条件的bug。还是分开一步步做比较好。
我不是说应该有屎山代码或为其辩护，只是说我们应该正确看待。
程序员应该还是要提高对自己的代码要求。但世间的事却又事多元化，就如当前语境下“圣母”带有贬义一样。
听说全球大公司微软内部也有一堆很多Could work但是程序员不想碰的屎山代码。