29.保持简单

“软件是很复杂的东西。随便哪个笨蛋都可以编写出简单、优雅的软件。通过编写史上最复杂的程序,你将会得到美誉和认可,更不用提保住你的工作了。”

也许你看过这样一篇文章,其中提到了一个设计想法,表示为一个带有花哨名称的模式。放下杂志,眼前的代码似乎马上就可以用到这种模式。这时要扪心自问,是不是正的需要用它,以及它将如何帮你解决眼前的问题。问问自己,是不是特定的问题强迫你使用这个解决方案。不要让自己被迫进行过分设计,也不要将代码过分复杂化。

Andy曾经认识一个家伙,他对设计模式非常着迷,想把它们全都用起来。有一次,要写一个大概几百行代码的程序。在被别人发现之前,他已经成功地将GoF那本书[FHJV95]中的17个模式,都运用到那可怜的程序中。

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 5 美元

这不应该是编写敏捷代码的方式。

问题在于,许多开发人员倾向于将投入的努力与程序复杂性混同起来。如果你看到别人给出的解决方案,并评价说“非常简单且易于理解”,很有可能你会让设计者不高兴。许多开发人员以自己程序的复杂性为荣,如果能听到说:“Wow,这很难,一定是花了很多时间和精力才做出来的吧。”他们就会面带自豪的微笑了。其实应当恰恰相反,开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。

“简单性”这个词汇被人们大大误解了(在软件开 简单不是简陋发工作以及人们的日常生活中,皆是如此)。它并 Simple is not simplistic不意味着简陋、业余或是能力不足。恰恰相反,相比一个过分复杂、拙劣的解决方案,简单的方案通常更难以获得。

简单性,在编程或是写作中,就像是厨师的收汁调料。从大量的葡萄酒、主料和配料开始,你小心地进行烹调,到最后得到了最浓缩的精华部分。这就是好的代码应该带给人的感觉——不是一大锅黏糊糊的、乱七八糟的东西,而是真正的、富含营养的、口味上佳的酱汁。

评价设计质量的最佳方式之一,就是听从直觉。直觉不是魔术,它是经验和技能的厚积薄发之产物。在查看一个设计时,听从头脑中的声音。如果觉得什么地方不对,那就好好想想,是哪里出现了问题。一个好的设计会让人觉得很舒服。

开发可以工作的、最简单的解决方案。除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术之类的东西。

切身感受

当你觉得所编写的代码中没有一行是多余的,并且仍能交付全部的功能时,这种感觉就对了。这样的代码容易理解和改正。

平衡的艺术

□ 代码几乎总是可以得到进一步精炼,但是到了某个点之后,再做改进就不会带来任何实质性的好处了。这时开发人员就该停下来,去做其他方面的工作了。

□ 要将目标牢记在心:简单、可读性高的代码。强行让代码变得优雅与过早优化类似,同样会产生恶劣的影响。

□ 当然,简单的解决方案必须要满足功能需求。为了简单而在功能上妥协,这就是过分简化了。

□ 太过简洁不等于简单,那样无法达到沟通的目的。

□ 一个人认为简单的东西,可能对另一个人就意味着复杂。