最近读了一本书,名字大家都看到了:《代码整洁之道》,之前一直只是听说过这本书的大名,却一直没有进行拜读,最近想起来了就想着看一看,不看不要紧,看了之后就像吃了炫迈,根本停不下来。。。虽然这本书已经出版了十几年的时间,但里面的理论到现在为止也不过时。
有人也许会以为,关于代码的书有点儿落后于时代--代码不再是问题;我们应当关注模型和需求。确实,有人说过我们正在临近代码的终结点。很快,代码就会自动产生出来,不需要再人工编写。程序员完全没用了,因为商务人士可以从规约直接生成程序。扯淡!我们永远抛不掉代码,因为代码呈现了需求的细节。在某些层面上,这些细节无法被忽略或抽象,必须明确之。将需求明确到机器可以执行的细节程度,就是编程要做的事。而这种规约正是代码。
看这本书的那种感觉很奇妙,有时感觉作者说地真对!有时感觉作者骂地真对!有时感觉作者讽刺地真对!还有时看到作者列出的真实代码中的错误示例,再看到作者写出的优化后的代码,内心不禁在想:太妙了,代码本应这样啊!
没错,代码本应该是整洁的,也本应该是好理解、易扩展的!我们常说的设计模式也并不是一种炫技,而是几十年来的老前辈们总结出来的经验,是为了让你的代码更好维护的,是一种理所应当。
在工作中遇到烂代码的可能性是 100%,即使是很厉害的大佬写的代码,在不知情的情况下让你去看,看了一会后都会得出以下结论:“写的啥玩意啊,看都看不懂,乱七八糟的语法糖,考虑过后面工作的人么?什么设计模式,什么各种模块,直接写一块不好么?” 假设的可能有点夸张,但也都是人之常情。有时工作中遇到的烂代码是假的,可能是由于当前自己的技术水平不够,不理解;当然还有一部分可能真的是烂,但是这种情况下还是要做出一些改变!
现在让大家看几个月之前自己写的代码可能都会觉得写的一团糟,用当前的眼光来看可能会有更好的方式或方法来实现,如果你有这种想法的话,请付诸实践!不要等,哪怕是一个单词的拼写错误、一段本不应该写两遍的逻辑、一段没有进行格式化的代码。。。。亦或者是比较大规模的代码改动,改完之后可扩展性会更强,维护起来会更加容易。千万不要等,不要忍受当前的烂代码,代码本就是一直在重构的一个过程,没有哪段代码从出来就不改。下面这段话是书里的内容:
我们都曾经瞟一眼自己亲手造成的混乱,决定弃之而不顾,走向新一天。我们都曾经看到自己的烂程序居然能运行,然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然,在那些日子里,我们都没听过勒布朗(LeBlanc)法则:稍后等于永不(Later equals never).
当然很多人会说:“项目中的屎山代码,我能在上面雕花已经很厉害了,还要干什么,即使我知道那块写的不好,但我也不会去动,因为现在它处于一个稳定的状态,如果我去修改了之后,出了问题全是自己背,吃力不讨好!”这也确实是很多人的现状,考虑的也不无道理,但在这里咱们单纯从代码的角度来看,从写代码的初心来看,早早的就背道而驰了。
代码格式不可忽略,必须严肃对待。代码格式关平沟通而沟通是专业开发者的头等大事。 或许你认为“让代码能工作”才是专业开发者的头等大事。然而,我希望本书能让你抛掉那种想法。你今天编写的功能,极有可能在下一版本中被修改,但代码的可读性却会对以后可能发生的修改行为产生深远影响。原始代码修改之后很久,其代码风格和可读性仍会影响到可维护性和扩展性。即便代码已不复存在,你的风格和律条仍存活下来。
我有代码洁癖,看不了没有格式的代码,看着有的项目中一个函数几百行甚至更多,里面各种重复逻辑,if/else不知道嵌套了多少层,表面看是逻辑复杂,再转念一想,为什么不用工厂、或者写一些别的类来简化下逻辑。这时肯定有人会站起来反对:“明明很简单的逻辑,非得使用什么设计模式,搞得一团乱还看不懂。。” 如果只是一个if/else,或者逻辑比较简单肯定没必要,但是逻辑复杂的情况下光if/else也足够将人搞晕,且当需求改变时代码变得难以维护。
我之前一直觉得写完代码格式化是正常的,是基本操作,但是工作中发现好像不是一个基本操作,格式化并不涉及到专业能力,而是态度,连格式化都懒得做,你说你写出的代码经过了严格的测试。。。。想起之前上学时老师经常说的一句话:作业会不会是能力问题,而做不做就是态度问题了。
说这些并没有什么恶意,仅是这本书的读后感,读完后就好像和作者已经是相识多年的老友,相视一笑。