江苏龙网

  1. 首页 > 人文 > >

『』?为什么大多数代码都很糟糕，能做些什么来改进代码吗？


全文共2245字 ， 预计学习时长7分钟
『』?为什么大多数代码都很糟糕，能做些什么来改进代码吗？
本文插图
来源：Pexels
大多数代码都很糟糕 ， 这听起来有些刺耳 ， 不是吗？
但事实上 ， 其中有一点是真实的 。 你可能已经研究过一些代码库 ， 并认为它们是一团乱麻 。
没有开发者是完美无缺的 。 他们所有人 ， 不论你认为他们有多优秀 ， 都会犯或大或小的错误 。
糟糕的命名 ， 太宏观的函数 ， 糟糕的架构决策 ， 重复的代码 。 我可以接连说出很多问题 ， 并且你可能都见过这些错误 。 可能是自己看到了这些错误或是有人点明它们 ， 或是自己有幸看到了其他开发人员的修改请求 。
于是乎 ， 小芯在本文中将和大家一起讨论如何减少代码库中的混乱 ， 使它成为一个更优秀的代码库 。
【『』?为什么大多数代码都很糟糕，能做些什么来改进代码吗？】
『』?为什么大多数代码都很糟糕，能做些什么来改进代码吗？
本文插图
糟糕代码产生的原因
好的代码符合一些特定的标准 。 首先是可读性 。 大多数代码糟糕的原因之一是它难以阅读 。
代码的可读性是至关重要的一个因素 ， 因为该代码开发员可能不是唯一一个从事这个项目的开发人员 。 即使是 ， 一年后还会记得整个代码库吗？
提高代码的可读性的方式有很多 。 其中之一是给变量、方法和类别赋予有意义的名称 。 是的 ， elapsedTime是一个不错的变量名 ， 但是elapsedTimeInSeconds呢？比之前者 ， 这才更有意义 。
使用可发音的名字来说明代码库的用途 ， 避免错误信息 。 知道如何给出有意义的名字可以让理解一篇代码变得更容易 ， 这样也更容易对代码进行维护 。
尽量保持函数的简短来确保可读性 。 这也会让函数更容易理解 。 百行函数包含三条命令是不可取的 。 为了保持简短 ， 函数应该有且只有一项命令 。
保持代码可读性的另一个好方法是限制缩进的数量 。 缩进过多时 ， 代码往往难以阅读 。
可以使用guard子句 ， 而非各式嵌套的if else构造 。 这将有助于限制所需的缩进数量 。
此外 ， 避免使用“单行奇迹” 。 可读性非常重要 ， 不应该为了使用较少的代码而牺牲可读性 。
请记住 ， 代码被阅读的频率比被编写的频率高得多 。 罗伯特·马丁对可读性的论述如下:
“我们一直在阅读旧代码 ， 这是为编写新代码所做的部分努力 。 因此 ， 读起来容易 ， 写起来也容易 。 ”——罗伯特·马丁
“你编写的代码需要最大限度地减少其他人理解代码所需的时间 ， 即使其他人就是你自己 。 ”——达斯汀·博斯韦尔和特雷弗·福彻
代码是可读的 ， 但仍然不容易理解 。 以古怪的“单行奇迹”为例 。 有时可能读起来很顺畅 ， 但依旧会误导人 。
『』?为什么大多数代码都很糟糕，能做些什么来改进代码吗？
本文插图
来源：Pexels
可以通过添加注释使代码更易理解 。 虽然好代码可能不需要注释来解释意图 ， 但仍然可以添加注释来解释原因 。
一旦项目进入维护阶段 ， 用来解释原因的注释就变得至关重要了 。 这就引出了大多数代码糟糕的下一个原因——它不可维护 。
开发人员或许竭尽所能使项目及时交付生产 。 为了在截止日期之前完成任务 ， 开发人员会做出一些牺牲 。 虽然这不可取 ， 但可以理解 。
由于所做的牺牲 ， 一个新的、重大的问题随之而来 。 它会耗费开发员大量的时间 。 一个已被更改 ， 通常只需要几行代码就可以修复的要求 ， 现在需耗费几个小时 ， 因为必须重写一部分代码 。
可维护性被牺牲了 。
有趣的是 ， 可维护性更容易被自身缺失所识别 。 粗略地说 ， 可维护性与开发人员进行变更所需的时间以及变更会造成破坏的风险成反比 。


推荐阅读


上一篇：『安卓每日推送』苹果 iOS 13.4 内测岭南通、深圳通交通卡

下一篇：「芥末堆」「竞创教育」获近千万元天使轮融资，将投入芸课芸校发展