阅读作业之Big Ball of Mud——洪虹

  大泥球,是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来,为了对付这个泥球,我们看到了多种指导方法,比如SOLID、GRASP和KISS,与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而,实际情形没多大变化,“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发(Agile)的很多方面会直接导致泥球,包括:缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。

  我们理想中的代码是清晰的,优雅的,云淡风轻,一望无垠,坐在电脑前深呼吸,都能闻到雨后泥土的芬芳。但是现实呢?一打开编译器就头痛。代码看得眼花,整天去修BUG,还要花半天时间先读以前的代码。好不容易改完提交了,第二天却报出更多的新BUG。

  其实,我们的软件,在发布前,其实就已经百病缠身了,随着功能的增加,便有了BUG,老的BUG改了,可能引入新的BUG。复杂的商业软件多少都会有BUG。我们思考这样几个问题:我们如何发现烂代码?烂代码要不要改呢?应该怎么改?如果烂代码不是先天性的,那是不是可以预防?

  很多时候无论花费多少时间试图去找出完美的软件结构,客户总是引入一个变化破坏这个结构,不存在完美结构,只存在那些试图平衡当前的代价和收益的结构。有时候,我们会把原因归咎于客户,责怪他们总是改变需求。有些人认为,只要客户的需求仅限于他们最初所声明的,那么我们的设计就是没问题的,所以错就错在客户改变了他们的需求。需求变化是非常正常的,JOBS说“用户根本不知道他想要什么,直到你把产品交到他的手中”。这种情况也是或多或少存在的。但是,客户连源代码都看不到,这种怨念却是没道理的。

  制约程序员编写高质量代码的因素有哪些?对需求和设计的理解不透彻,对软件业务流程不熟悉,没有开发经验,不知道怎样的代码是好的,对开发工具或开发语言不熟悉,缺少监督体系或不重视质量评估,受情绪因素的影响等因素,其它非代码因素也起着关键作用。很多时候,好的代码会促生好的代码,糟糕的代码也会促生糟糕的代码。没人想去整理糟糕的代码,同样没人想把完美的代码弄得一团糟。因此,保持代码整洁很重要。

  函数的第一规则是要短小,第二条规则是要更短小。 我无法证明这个断言,我给不出任何证实了小函数更好的研究结果,我能说的是,40年来,我写过各种不同大小的函数,我写过另人憎恶的长达3000行的厌物,也写过许多100行到300行的函数,我还写过20行到30行的。经过漫长的试错,经验告诉我,函数就该小。

    ——《代码整洁之道》

  我们团队的代码中也肯定存在着大泥球,有些已经被发现的我们都已经尽力优化,比如我写用户排名RANK类的时候需要多次判断同一调用函数Sum的返回值,这时候定义一个变量就能避免没有必要的多次调用,大大提高了代码效率。当然肯定还存在一些还没被发现的大泥球,还有待我们进一步检查。

你可能感兴趣的:(BI)