不要浪费时间写完美代码

时间: 2017-11-20阅读: 667标签: 代码

一个系统可以维持5年,10年,甚至20年以上,但是代码和设计模式的生命周期非常短,当对一个解决方案使用不同的方法进行迭代的时候,通常只能维持数月,数日,甚至几分钟的时间。



代码重要性区分

随着对代码是如何改变的研究,致力于代码修改艺术的人发现了一个代码库的规律曲线。每个系统都有很多从未改变的代码。但是也有小部分非常重要且有用的代码一次又一次的改变,经过了多次重构和重写。

当你对一个系统,问题域,或者架构方法越来越熟悉的时候,就更容易发现和预测哪些代码会经常修改,哪些代码不会被修改,即区分重要代码和非重要代码。


我们应该尝试追求完美代码?

众所周知,我们应该写干净整洁的代码,而干净整洁就应该是尽可能一致,易懂,简单。

有些人追求极致,强迫自己写的代码要漂亮且优雅,接近于他们所能达到的完美,疯狂的进行重构,并致力于每一个细节。

与写完代码不再变动相比,一直修改的代码会让完美的需求和具有前瞻性的设计变得有些多余和没必要。

你不能写出完美的软件,这样的结果会使你受伤了?没必要,把它当做人生格言,信奉并祝贺,因为完美的软件并不存在,在计算机历史中没一个人曾经写出过完美软件,当然,你也不可能成为第一个,只有接受这样一个事实,你才能不再在浪费时间,将精力放在可能实现的理想中。

Andrew Hunt, 实用程序员:从路人到大师

曾经写过的代码不需要优美优雅。它必须是正确的且容易理解的,因为在系统的生命周期中那些从不用修改的代码也会被多次访问。同样这些代码不需要又整洁又紧凑——只要整洁就足够了。在一定程度上,复制粘贴和其他快捷方法写出的代码是允许的。即使这些代码周围的代码变了,这些代码不需要反复修改,不需要重构(直到你需要修改它)。这样的代码是不值得花费额外的时间的。

那些经常修改的代码该如何处理呢?苦思冥想代码风格和提出最优雅的解决方案是浪费时间的,因为这些代码可能会在几天或几周之内再次修改,甚至重写。因为希望代码应该变得更好而痴迷地重构那些需要经常修改代码,或者重构那些基本不会修改的代码。代码一直可以变得更好,但这并不重要。

最重要的是:代码是否做到了它应该做的事?代码运行正确且可用又高效吗?能够处理错误和错误数据而不奔溃或者至少是安全地出错吗?容易调试吗?能简单又安全地修改代码吗?这些不是对于完美代码的主观想法,而是用来区分成功和失败的切实可行的措施。


实用的编码和重构

精益开发的核心思想是:不要浪费时间在那些不重要的事情上。这句话已告诉我们该怎样写代码,怎样重构代码,怎样评审代码,怎样测试代码。

为了把工作做好,只重构你需要的——Martin Fowler 称为机会主义重构(理解、清理不切实际的东西)和预先重构。足够让修改变得更简单更安全即可,其他的不必考虑。如果你不修改那些代码,那么那些代码长什么样子是无所谓的事。

在代码评审中,只关注那些重要的。代码正确吗?有防范机制吗?安全吗?容易理解吗?能够安全地修改吗?

忘掉编码风格(除非编码风格达到可理解的程度)。让你的 IDE 处理格式化。不要过多争论:代码是否可以是“更多的OO”。只要它有意义,不管它是否适当地遵循这种或那种模式,这些都不重要。无论你喜欢还是不喜欢都没关系。无论你能否以更好的方式做到这一点并不重要——除非你在教一个对平台和语言都不熟悉的新手,而且你需要做一些代码评审作为指导的一部分。

写测试是有必要的。测试那些涵盖主路径和重要例外情况的测试。测试可以让你以最少的工作量获得最多的自信心。大规模全范围测试或者小规模局部测试——在编写代码之前测试还是之后测试,都没关系,只要做了这个工作就行。


这不(仅)是关于代码

建筑学和工程学的隐喻从未在软件开发中生效。我们不是设计和建造桥梁或摩天大楼 —— 它们会在几年或几代内保持基本相同。我们正在建造一些更富有创造力和抽象性、更加短暂的东西。代码编写之后是用来修改的 —— 这就是为什么它被称为“软件”的原因。

“经过五年的使用和修改,成功的软件的源码通常与最初版本完全不一样,而五年之后的成功的建筑几乎没有什么变化。”

Kevin Tate, 可持续软件开发

我们需要将代码看作是我们工作的一个暂存:

…有时在面对更重要的事情时,我们被引导到盲目崇拜代码。我们经常会处于这样的幻象中:在移交产品时最有价值的东西是代码,实际上这可能是对问题域的理解、设计难题的进展甚至是客户反馈。

Dan Grover, 代码和创造性破坏

迭代开发教会了我们通过实验来验证我们工作的结果 —— 我们是否已解决了这个问题,如果没有,我们学到了什么,我们该如何改进?我们正在构建的软件永远不会完成。即使设计和代码是正确的,它们可能也只是在一段时间内是正确的,直到环境要求其再次改动或被替换为更好的东西。

我们需要编写好的代码:可理解、正确、安全和可靠的代码。我们需要重构和审查它,并写出好的有用的测试用例,直到其中的一些代码(也可能是全部(),可能会很快被抛弃,或者可能永远不会被再次看到,或根本不会使用了。我们需要认识到,我们的一些工作必然会被浪费掉,并要为此进行优化。做那些必须做的,不做无用功。不要浪费时间尝试编写完美的代码。


译文:https://www.oschina.net/translate/dont-waste-time-writing
原文:https://dzone.com/articles/dont-waste-time-writing
吐血推荐

1.站长广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入...

2.休闲娱乐: 直播/交友    优惠券领取   网页游戏   H5游戏

链接: http://www.fly63.com/article/detial/130

掌握依赖注入5大原则,无需额外编代码!

如果是第一次接触这个概念,可能会一时没有头绪,网上的各种解释可能会让你更加混乱,并觉得它没那么简单。 其实依赖注入本身是单纯、简单的。简单来说,依赖注入是一种方式、方法或者说手段

如何在 React 中优雅的写 CSS?

如果是 ui 组件库中使用建议使用 namespaces 方案,ui 组件库维护人员基本固定,遵守约定的规范较为容易,可通过约定规范来解决不同组件 CSS 相互影响问题,由于 ui 组件库会应用于整个公司的产品

让代码具有可读性的10种最佳实践

如果咱们关注代码本身结构及可读笥,而不是只关心它是否能工作,那么咱们写代码是有一定的水准。专业开发人员将为未来的自己和“其他人”编写代码,而不仅仅只编写能应付当前工作的代码。

如何执行innerHtml中的script代码?

有时候我们会有把一整段 HTML 动态塞进页面的需求,例如渲染了一个模板,从服务器端获取了一段广告代码等。一般情况下我们使用 container.innerHTML 即可

编写可维护的Js代码

不省略分号(在原生及使用工具函数的情况不建议省略,在使用比较完善的框架如vue或者自己配置好 webpack 时可以省略),1行代码长度不超过80个字符(个人比较推荐,毕竟编辑器的自动换行有时真的很难受)

什么才是优秀的代码?

究竟什么是优秀的代码?Robert Martin的一句话可以完美诠释。代码质量的唯一衡量标准是每分钟说多少次WTF,我来解释一下这句话。当我在做code review时,通常会有三种不同的感受:

好代码的用处,怎么写出好代码?

实际上本书建立在一个相当不可靠的前提之上:好的代码是有意义的。我见过太多丑陋的代码给他们的主人赚着大把钞票,所以在我看来,软件要取得商业成功或者广泛使用

如何增强前端代码的健壮性?

前端页面的成功呈现,不仅要求在理想情况下没问题,当一些后台接口访问异常、静态文件获取失败时,仍然需要尽可能提供降级方案或给用户良好的反馈,不至于整个页面的奔溃

webpack优化之玩转代码分割和公共代码提取

开发多页应用的时候,如果不对webpack打包进行优化,当某个模块被多个入口模块引用时,它就会被打包多次(在最终打包出来的某几个文件里,它们都会有一份相同的代码)。当项目业务越来越复杂

网站加入收藏、设为首页Js代码(兼容各种浏览器)

这里虽然说是兼容,但是有些浏览器的设置就是不支持用js来把页面设为首页,加入收藏夹,只能让用户手动去在浏览器或者按键去设置这些功能,这里说的兼容是指当浏览器有这个设置的时候js会有提示

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全