我如何让它更简洁？(不应该很难)_重复字符串清理，如何让它更简洁_如何让它变得更漂亮？ - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

如何让你的代码更简洁？

如果你所写出来的代码比你所需要的多，那么多出来的那部分代码不应该存在其中。任何的多余都是不可能容忍的，而且一直以来我甚至觉得一个空格都不允许多余。...读到其中如“永远不要接受一个坏了的窗口”之类的观点时，让我产生了共鸣。这设想起来十分简单。想象下，你有一间房子，然后因为没有设计图来修复它，墙面开始裂开，然后越来越严重，直到房顶坍塌。...另一方面，我希望我的代码能够在第一次就尽可能完美，不是我喜欢浪费时间，而是因为足够节约，我知道这将在之后给我省下更多时间。如何完成“简洁代码”设计那么，该怎样创造“简洁代码”呢？...这就是为什么，对我来说，程序的第一步，就是和客户方了解清楚，他需要的结果具体是什么样的。如果您遵循领域模型驱动设计，那么下一步让代码简洁的方法是：创建共用语言或“领域通用语言”。...等级扁平的公司更容易促成这种讨论。总是要尽早让客户参与讨论。有时，意见不同的原因可能是客户不晓得他们的选择会导致性能不佳、维护困难或成本高昂。所以，问他们：“我们现在真的需要这个功能吗？

9090 0

React 还是 Vue: 你应该选择哪一个Web前端框架？

两种框架，两个拥护者在这篇文章中我想用尽可能公平，全面的对比来回答这些疑问。但是问题来了：我是个不折不扣的Vue迷弟，肯定会偏向它。...今年我在项目中大量地使用了Vue，在Medium上安利它的好处，甚至还在Udemy开设了一门关于Vue的入门课程。为了平衡一下，我邀请了我的朋友Alexis Mangin一起参与讨论。...，当时由于我不太了解React，所以很难给出一个很好的回答。于是我向他提议，我们找一天带上各自的笔记本电脑，一起探讨我们各自喜爱的框架的好处。...令人佩服的是，Vue中改变状态的操作不仅更加简洁，而且它的重新渲染系统实际上比React的更快更高效。不过Vue的响应系统还是有些坑的，比如它无法检测属性的添加和删除，以及某些数组更改。...如果你计划构建一个大型应用程序，请使用React 像文章开头那样，用Vue和React实现的简单应用程序来比较两者，可能会让一个开发者从一开始就更倾向于Vue。

1.6K2 0

您找到你想要的搜索结果了吗？

是的

没有找到

如何在 Python 中应用设计原则

写出能用的代码很简单，写出好用的代码很难。什么是好用的代码呢？其实就是代码质量比较高，如何评价代码质量的高低呢？...最常用的、最重要的评价标准，就是代码的可维护性、可读性、可扩展性、灵活性、简洁性、可复用性、可测试性。...如果我们把它翻译成中文，那就是：一个类或者模块只负责完成一个职责（或者功能）。让我们举一个更简单的例子，我们有一个数字 L = [n1, n2, …, nx] 的列表，我们计算一些数学函数。...可测试，为代码的每个功能创建测试更容易。但是要增加新功能，比如计算中位数，main 函数还是很难维护，因此还需要第二个原则：OCP。...这样设计好处有两点：低层次模块更加通用，适用性更广高层次模块没有依赖低层次模块的具体实现，方便低层次模块的替换最后的话我去年（2020）年 2 月 3 号购买的《设计模式之美》专栏，将近一年半才把它学习完

9504 0

如何写出优质干净的代码

简单地说，代码越简洁就越容易解释，误解也就越少。 3．更容易遵循编码模式有一件事需要记住，理解和学习如何使用代码是一回事。然而，这仅仅是个开始，同时还需要确保开发人员能够愿意遵循我们的编码模式。...即使让别人无法访问我们的代码，但我们自己也可能在将来又重新拾起这些代码。出于这些原因，让代码便于阅读和理解是符合我们自己的利益的。那么如何实现呢？最简单的方法是使用空格。...3.让一个函数或方法只执行一个任务当开始编写代码时，使用的函数和方法看起来就像一把瑞士军刀，几乎可以处理任何事情，但是很难找到一个好的命名。...另外，除了编写者，几乎没有人知道函数是用来做什么的以及该如何使用它。有时我就会遇到这些问题，我在这方面做的很不好。然后，有人提出了一个很好的建议：让每个函数或方法只执行一个任务。...如果你很难找到函数和方法的描述性名称，或者需要编写冗长的指令以便其他人可以使用，那请考虑这个建议，让每个函数或方法只执行一个任务。

7382 0

高级 PHP 工程师必备的编码技巧及思维

本文，我将向你展示一些现实生活中技巧和想法的例子，来帮助你清理你的逻辑代码，重构它，让它变得更健壮和模块化。这些技巧将不仅仅帮助你重构你的旧代码，而且给你一些如何从现在开始写出简洁代码的好建议。...下面的内容将向你展示一些重构逻辑代码，让它变得更好的例子。不要在没有单元测试的情况下重构生产环境的代码我的第一条建议是从不在没有完全进行单元测试的情况下开始重构逻辑代码。...我的理由是：你将会以很难有修复的损坏的功能收尾，因为你也很难指出是哪里损坏了。因此，如果你要重构它，从测试开始。保证你准备重构的部分被测试覆盖到。PHPUnit 代码覆盖分析....它变得更加简洁，易读，易于测试。...很多功能能够节约你们的的时间，而且能够让你们的代码更健壮。看下下面的示例，注意如何在更少代码情况下更容易达到相同的结果的，通过使用类型提示。

7976 0

研究上千张数据图表后我学到12条可视化的秘密准则 | 附资源

可视化处理应当简洁明了 ▼ 但在这里“简洁”到底意味着什么呢？在看完成百上千个Priceonomics图形和图表后，我发现最成功的可视化图形往往能在几秒钟内传递所要表达的思想。...这让读者更容易地吸收文章要表达的信息。 3. 图片可作为帖子缩略图 ▼ Priceonomics的人们经常这么做，并且我认为这是一个非常好的思路。...明确地理解这个图表的表达内容，这使它在社交媒体中更容易被分享。为什么我们不能运用文字去帮助读者理解我们在可视化图形中试图阐述的呢？它并不像数据点和文字那样，不能共存在同一图表上。 5....并且，它很难用颜色来进行有效的可视化区分和表达，因为有一些值的差距只有0.01%。 7. 图表应突出重点 ▼ 如我一再强调，可视化是为了让数据更为一目了然。...可视化做成这样，就显得赏心悦目且通俗易懂，更重要的是，节省了屏幕空间，使页面看上去更简洁明了。如果图片以纵向显示，那么屏幕上就会留有大片空白，必须用到浏览器的滚屏，很浪费屏幕空间。

8684 0

6个编写优质干净代码的技巧

简单地说，代码越简洁就越容易解释，误解也就越少。 3．更容易遵循编码模式有一件事需要记住，理解和学习如何使用代码是一回事。然而，这仅仅是个开始，同时还需要确保开发人员能够愿意遵循我们的编码模式。...即使让别人无法访问我们的代码，但我们自己也可能在将来又重新拾起这些代码。出于这些原因，让代码便于阅读和理解是符合我们自己的利益的。那么如何实现呢？最简单的方法是使用空格。...然后，看着代码就可以更容易理解它了。来看两个简单的例子。...另外，除了编写者，几乎没有人知道函数是用来做什么的以及该如何使用它。有时我就会遇到这些问题，我在这方面做的很不好。然后，有人提出了一个很好的建议：让每个函数或方法只执行一个任务。...如果你很难找到函数和方法的描述性名称，或者需要编写冗长的指令以便其他人可以使用，那请考虑这个建议，让每个函数或方法只执行一个任务。

68910 0

架构之思-分析那些深入骨髓的设计原则

在平时工作中，不自觉的进行了熟练的运用：看到公司里有个基础数据这样的服务，明知道很难很难也要决心治理掉：“这种服务不应该存在！任何一个软件模块都应该只对一个用户或系统利益相关者负责(单一职责原则)。...这个行为抽象为函数是这个样子的： function 梅花变香泥(一枝梅) { 第一步：孤立它第二步：让它经历黑暗第三步：让它经历风雨第四步：让其他花儿妒忌它...第五步：让它凋落到泥里化为尘土只保留香气 } 这里“梅花变香泥”行为被抽象，对调用者来说只要调用了这个函数，就是调用了那5步骤的行为。...函数式编程确实有很多优势：因为函数式编程的引入变量都是不可变的，虚拟机实现时可以去掉很多多余的锁，并发处理更快；代码简洁；内聚性更好…… 我仔细想了一下，对诸如java这种面向对象的编程语言来说，函数式编程和面向接口编程一样...但是“在看率”上来了，可以感受到大家的支持，让我充满力量。女孩子嘛，比较感性，决定本周加更这篇，表达一下自己的感恩~~

2711 0

微服务的创建和管理最常见问题是什么?

如果崩溃和烧伤，您可以替换它，如果它是无状态的。 2)关注架构。如何拆分不同的组件。你可以增加复杂性而不是减少复杂性。复杂性任何考虑的团队都不应该介入，如果他们不清楚他们试图解决的问题的领域。...简洁明了的api和逻辑，很容易让你的头脑去构建更复杂的应用程序和行为。大多数传统组织都不得不移动传统的应用程序。这是一个多年的旅程。你不能停止支持单体系统。一次只做一次服务。...更多关于如何做事情的文档。在不合适的时候尝试做微服务。我们如何让自动化和可观察性到位?我们如何测试我们的应用程序并获取数据以询问平台和应用程序，以及何时比较它们何时开始退化?...如果你没有一个平台，你的企业文化也没有很好地结合起来，你就很难将微服务融入到产品中。无论你追求的是什么新项目，你都要把它作为一个微服务来做，而不是改变传统的应用程序。慢慢开始，逐步进入架构。...如果没有自动化，如果你很难部署大的东西部署成百上千的小的东西如果没有自动化就无法完成。在分解系统之前，把自动化放在适当的位置。我认为影响微服务的最大问题将是维护API兼容性。

7651 0

17年编程生涯的三大经验总结

和大多数工程师一样，我对持续重构一直到代码尽可能地少和简洁的机会垂涎三尺。如果可以选择更少又更简洁的代码来完成同样的任务，那么我为什么要选择要个更多代码的方案呢？...通常情况下，更简洁的语言会导致更好的交流。画蛇添足只会阻碍核心信息的提取。但是，最终的目标不应该是简洁——而应该是可交流。于我而言，下面这段直截了当的代码，在它更长的时候…… ?...……反而比这个简洁版本更明确。 ? 虽然这是一个品味问题（有些人可能会觉得后者看上去更加一目了然），但是我在这里要表述的观点是，有时候解释的最伟大方法并不是简化。...举例来说，我想要更明确和更详细地告诉我爸爸应该如何关闭iPad（“按住右侧的按钮一段时间……”）。...有时它值得你现在承担一点债务——错过抽象或者有一些未优化的SQL代码——如果这样做可以让你更快地发布内容给不断增长的观众的话。关键是要了解你必须偿还它，以及你可以在适当的时间段之后偿还。

4905 0

17年编程生涯的三大经验总结

和大多数工程师一样，我对持续重构一直到代码尽可能地少和简洁的机会垂涎三尺。如果可以选择更少又更简洁的代码来完成同样的任务，那么我为什么要选择要个更多代码的方案呢？...通常情况下，更简洁的语言会导致更好的交流。画蛇添足只会阻碍核心信息的提取。但是，最终的目标不应该是简洁——而应该是可交流。于我而言，下面这段直截了当的代码，在它更长的时候…… ?...……反而比这个简洁版本更明确。 ? 虽然这是一个品味问题（有些人可能会觉得后者看上去更加一目了然），但是我在这里要表述的观点是，有时候解释的最伟大方法并不是简化。...举例来说，我想要更明确和更详细地告诉我爸爸应该如何关闭iPad（“按住右侧的按钮一段时间……”）。...有时它值得你现在承担一点债务——错过抽象或者有一些未优化的SQL代码——如果这样做可以让你更快地发布内容给不断增长的观众的话。关键是要了解你必须偿还它，以及你可以在适当的时间段之后偿还。

2833 0

如何提高代码品味

我曾经觉得代码质量很重要，后来写业务写多了，又觉得如果连代码正确都做不到，又谈何代码质量。后来我又醒悟了，这世上很难有 bug free 的代码，当出现 bug 的时候，好代码比烂代码会好改很多。...那模块如何划分？我们可以说出一些普适的原则，譬如高内聚低耦合、单一职责原则、开闭原则等等，但这些东西说起来感觉很套路很不真诚，让人觉得无从下手。...我们有很多约定俗成的“潜规则”其实都有它背后的逻辑，譬如以前天天说的 MVC 和 MVVM 两个模式，他们的最主要区别不在于模块划分，而是模块间的交互，在划分方面它们都致力于让 UI 和逻辑分开，为什么呢...其实不是的，组件是一个小粒度的模块，它相对独立，具有很高的内聚性，组件中的“逻辑”更多的应该是 UI 相关的交互逻辑，而不是那些比较底层的逻辑，我们还是应该把相对稳定的逻辑抽出来放到更下层。...我很排斥一个观点是，为了让团队的所有人都能看懂，鼓励只使用语言的基本特性，一些高级的或者不太常用的特性不准用，用了就是炫技。

7772 0

单体优先的微服务架构

这些规律在我同事中产生了长期的讨论：你不应该在新项目之初就采用微服务架构，即使你坚信该应用未来会因业务演进而变得巨大无比。...正如我们现在所认识到的，通常判断一个软件和想法是否有用的最好方法，是构建一个简单的版本，看看它的跑起来效果如何。...然而，如果我听过很多这样的成功案例，我会觉得这种方法更合适，实际很难做到。一种更常见的方法是从一个庞然大物开始，然后逐渐从边缘剥离微服务。...然后，随着边界稳定下来，就会分解为更细粒度的服务。虽然我接触的大多数人倾向于“单体优先”的策略，但这不是绝对的。相反的观点认为，从微服务开始构建新的系统，可以让你适应在微服务环境中开发的节奏。...尽管证据不多，但我觉得你不应该从微服务开始，除非你有在团队中构建微服务系统的大量经验。我觉得我还没有足够的例子来明确如何决定是否使用“单体优先”策略。

1400 0

代码风格.Python-整体风格.000

简单介绍: 说明: 很难创造一个对简洁代码的精准定义,也许它的定义和程序员的数量一样多.然而,有些原则是可以应用到简洁代码的基础层面.我收集了9个最相关的原则,并将在下面简短地介绍他们....差的代码会做太多的事情,简洁代码则非常专一说明: 每个类,方法或是其它实体应该保持(SRP)单一职责原则,也就是说在一个给定的抽象层,一个功能单元仅仅应当为单方面系统需求(一个可以独立于其它方面而改变的需求的一个特性...你代码的语言应当看起来像是为问题而设计说明: 不应该使用会使代码和语言看起来拙劣的变通方法,如果你说一件事只能以一种变通的方法完成,这通常意味着你没有花费足够的事件去寻找一个好的简洁的解决办法. 3....应富有表现力说明: 代码表现力是让代码本身变成文档,从而使文档不再那么重要.

6711 0

15个简单的JS编码标准让你的代码更整洁

编码标准可以帮助以下方面：保持代码一致易于阅读和理解易于维护下面的编码标准是我对上述几点有帮助的看法。 1....使用 const 代替 let 这阻止了开发人员尝试更改不应该做的事情，并且确实有助于提高可读性。...尽可能使用ES6箭头函数箭头函数是编写函数表达式的更简洁的语法。...如果你在团队中工作，那么一件很难的事情就是强制执行编码标准。这里有一些建议可以帮助你：代码审查，逐行Pass代码。...整理或使用某种代码分析器创建新内容时，让你们的一位高级开发人员初始化，其他开发人员可以使用该代码作为指导。

9783 0

17年编程生涯的三大经验总结

和大多数工程师一样，我对持续重构一直到代码尽可能地少和简洁的机会垂涎三尺。如果可以选择更少又更简洁的代码来完成同样的任务，那么我为什么要选择要个更多代码的方案呢？...通常情况下，更简洁的语言会导致更好的交流。画蛇添足只会阻碍核心信息的提取。但是，最终的目标不应该是简洁——而应该是可交流。...举例来说，我想要更明确和更详细地告诉我爸爸应该如何关闭iPad（“按住右侧的按钮一段时间……”）。...作为一个孩子，我的看法是，债务完全是坏的。我从不认为欠债是一种优势。直到我看到其他人是如何对待债务的——在我20出头的时候——我终于知道了债务也可以是有益的。...有时它值得你现在承担一点债务——错过抽象或者有一些未优化的SQL代码——如果这样做可以让你更快地发布内容给不断增长的观众的话。关键是要了解你必须偿还它，以及你可以在适当的时间段之后偿还。

4858 0

Python 工匠：异常处理的三个好习惯

让我给你从头理理这段代码。最初编写 process_image 时，我虽然把它放在了 util.image 模块里，但当时调这个函数的地方就只有 “处理用户上传图片的 POST 请求” 而已。...为了偷懒，我让函数直接抛出 APIErrorCode 异常来完成了错误处理工作。再来说当时的问题。...所以必须对它抛出的异常进行恰当的包装，避免未来的底层变更对 requests 用户端错误处理逻辑产生影响。异常处理不应该喧宾夺主在前面我们提到异常捕获要精准、抽象级别要一致。...上下文管理器是一种配合 with 语句使用的特殊 Python 对象，通过它，可以让异常处理工作变得更方便。那么，如何利用上下文管理器来改善我们的异常处理流程呢？...使用该上下文管理器后，整个函数可以变得更清晰简洁： def upload_avatar(request): """用户上传新头像""" with raise_api_error

7274 0

为什么大规模 Scrum 框架大都只是跟风，迟早会被放弃？

我个人见到它被采用就有几次了，但我从未见过它产生了什么积极的影响。它也不是唯一一个受到严厉批评的大规模框架。...它们具有破坏性，让人们懒惰成性，使组织走上平庸之路。于是我提出了以下问题：为什么大规模框架在实践中往往不能解决它们承诺解决的问题？好吧，我不相信这个问题有一个单一的、简洁的答案。...作为这种极简主义方法的具体示例，可以参考我多次介绍过的 Feature Teams，但不需要实现 LeSS。我确实受益于 LeSS 框架提出的，关于如何引入 Feature Teams 的最佳实践。...用统计和经济学家 Ernst F.Schumacher 的话来说： “只会小聪明的人们都会让事情变得更大、更复杂、更暴力。这需要一点点天赋——以及朝着相反方向前进的巨大勇气。”...但是当你终于买了一个陀螺，并第一次用手指旋转它时，你就开始后悔了。你不禁想知道：“我怎么又交了一次智商税呢？”。

3581 0

【翻译】Kotlin致简代码之路

我们可以通过让自己的代码更加简洁、简短、简单并富有表现力来达到这个目的。我们在处理最少形式主义和语法噪点的时候也会遇到致简代码。致简代码和 Kotlin 让我们考虑几个出自 Robert C....然而，使用 Java 有时候很难写出小而富有表达力的函数。让我来举个例子。假设我们需要把 HTTP 响应的有效信息映射成一个对象并且能正确的处理各种错误分类。...特别要注意：很难读的怪诞表达式（看上面的一节：注意残缺）复杂的安全访问和 elvis 结构关于后面那一点让我来给你举几个例子。...我不认为这很差，特别是在遇到额外的少量的语法时候。 “让汽车更安全并不意味着你可以粗心驾驶。”...因此有很多的人（不仅仅是在谷歌）欢迎拥抱 Kotlin 以及它的特性。在这篇文章里，我努力指出 Kotlin 中提供的大量优秀的特性来让你们写出更加简洁的代码。

1.4K3 0

对于程序员来说写代码并不是最难的事情！

这样做可以让你尽早发现 bug，让你后续的回归测试变得更容易。有些公司甚至鼓励开发者在编写程序之前就可以写好测试程序。挑战：为每一部分进行测试是一件很枯燥乏味的事情，让人感觉是在做多余的事情。...这包括了独立的文档文件和代码注释，让更多的人理解你的代码。挑战：这是一件耗时的工作，如果没有人去读它们的话就是纯属浪费时间了。相比于写文档，程序员还是更爱写程序。...4，实现那些你不认可的功能任务描述任务描述：有时候你会不得不去实现一些功能和特征，它们不是你的本意，你觉得它们不应该出现在这个项目里，但是客户一定要坚持如此。...挑战：你需要用尽一切办法理解前任开发者的意图，他是如何设计的这些代码。特别是当这些代码写得很差，也没有注释和文档可以帮助到你时，那就很糟糕了。...挑战：即使是很小的程序或应用都需要给很多东西命名，你要想出那些适合的，简洁的，可以表达正确含义的一些名字。

1.2K0 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭