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