大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，比如SOLID、GRASP和KISS，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发（Agile）的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
我们理想中的代码是清晰的，优雅的，云淡风轻，一望无垠，坐在电脑前深呼吸，都能闻到雨后泥土的芬芳。但是现实呢？一打开编译器就头痛。代码看得眼花，整天去修BUG，还要花半天时间先读以前的代码。好不容易改完提交了，第二天却报出更多的新BUG。
其实，我们的软件，在发布前，其实就已经百病缠身了，随着功能的增加，便有了BUG，老的BUG改了，可能引入新的BUG。复杂的商业软件多少都会有BUG。我们思考这样几个问题：我们如何发现烂代码？烂代码要不要改呢？应该怎么改？如果烂代码不是先天性的，那是不是可以预防？
很多时候无论花费多少时间试图去找出完美的软件结构,客户总是引入一个变化破坏这个结构,不存在完美结构,只存在那些试图平衡当前的代价和收益的结构。有时候,我们会把原因归咎于客户,责怪他们总是改变需求。有些人认为,只要客户的需求仅限于他们最初所声明的,那么我们的设计就是没问题的,所以错就错在客户改变了他们的需求。需求变化是非常正常的，JOBS说“用户根本不知道他想要什么，直到你把产品交到他的手中”。这种情况也是或多或少存在的。但是，客户连源代码都看不到，这种怨念却是没道理的。
制约程序员编写高质量代码的因素有哪些？对需求和设计的理解不透彻，对软件业务流程不熟悉，没有开发经验，不知道怎样的代码是好的，对开发工具或开发语言不熟悉，缺少监督体系或不重视质量评估，受情绪因素的影响等因素，其它非代码因素也起着关键作用。很多时候，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟。因此，保持代码整洁很重要。
函数的第一规则是要短小，第二条规则是要更短小。 我无法证明这个断言，我给不出任何证实了小函数更好的研究结果，我能说的是，40年来，我写过各种不同大小的函数，我写过另人憎恶的长达3000行的厌物，也写过许多100行到300行的函数，我还写过20行到30行的。经过漫长的试错，经验告诉我，函数就该小。
——《代码整洁之道》
我们团队的代码中也肯定存在着大泥球，有些已经被发现的我们都已经尽力优化，比如我写用户排名RANK类的时候需要多次判断同一调用函数Sum的返回值,这时候定义一个变量就能避免没有必要的多次调用，大大提高了代码效率。当然肯定还存在一些还没被发现的大泥球，还有待我们进一步检查。