refactor重构编程

     

如何使用OO和函数式两个方法实现重构? - DZone

1111 2 2K

Java 中的重构有很多方面,但其中有两个基础:面向对象和函数式。面向对象几乎从第一个 Java 版本开始就存在,而函数式只出现在 Java 1.8(2014 年 3 月)中。Java 是一种经典的面.

Golang不利于重构升级? - fasterthanli

1223 1 2K

本文作者曾经发布《我想离开Golang先生的狂野之旅》,该文反复出现在Reddit、Lobste.rs、HackerNews等地方引起广泛争议,本文是其最新文章,主要指出go虽然很容易上手,但是随着系.

编码时请将“单位”写入名词以突出明确 - Ruud

718 3K

有一个代码可读性陷阱,一旦你意识到它就很容易避免,但这个陷阱无处不在:人们喜欢省略“单位unit”。看看 Python、Java 和 Haskell 中的以下三个片段:time.sleep(300)T.

如何通过代码库的抽象分支以增量方式进行大规模更改 - Paul

838

团队经常使用版本控制分支进行大规模更改,以便他们可以继续开发功能并修复主线上的错误。但是如果您的代码位于分支上,则它不能被集成的。合并回主线肯定是痛苦的,痛苦的程度取决于你想要做出多大的改变,同时你在.

RefactorFirst:寻找Java代码库中无所不包的大型“上帝”类

1103
这个 Java 代码库工具将帮助您识别应该首先重构的上帝类,也就是意大利面条的“大泥球”类,代码很长都混沌编织在一起的类,这样的上帝类往往是出现Bug最多的地方,也是技术债务中的核心债务,需要重构甚至.

副作用是编程头号敌人!如何剥离它?- spin

1219 1 2K

随着时间的推移,我注意到一种设计启发式方法,它极大地帮助了我完成无数项目。这种启发式的地方在于它在概念上易于理解和应用,但它自然会引导您更接近函数式编程。事实上,这与 Haskell 处理 IO 的方.

重构复杂条件的规则设计模式 - levelup

1475 1 6K

通过编写if else条件语句来验证对象是软件开发中的一项常见任务。想象一下,开发人员收到了以下文件验证要求: 只允许txt和html扩展名。 txt 文件的大小不能超过 5 MB。 html 文件的.

编写可维护的代码是一种沟通技巧 - Max Chernyak

1332 1 6K

编写可维护的代码很容易。只需保持方法和参数列表简短,名称和注释较长,并遵循样式指南。正如一位著名记者曾经写道:“对于每一个复杂的问题,都有一个清晰、简单和错误的答案。”使代码难以维护的不是样式和形状。.

使用反应式编程替换Java自动资源管理 - Arvind

1420 1 5K

自动资源管理(Automatic resource management 简称ARM)在 Java 7 中首次引入时是一个受欢迎的特性,也就是通常说的无需finally的try()用法。然后ARM 继.

建议将技术债务更名为科技财富 - increment

885 2K
技术债务是由于在构建功能时采用了太多的技术捷径。产品团队创建了一个雄心勃勃的路线图,几乎没有犯错的空间,工程师在已经过时的软件基础设施上进行不守规则的破解以实现这些雄心壮志。债务像一个孩子踮起脚尖走进.

避免过早的软件抽象 - Jonas

1090 1 4K
让我们看一些在实践中经常发生的过早抽象的具体案例。这些都是基于在我们自己的代码库中找到的真实示例。职责抽象得太细了使用设计模式没有真正的好处性能过早优化低耦合无处不在让我们分别仔细看看其中的每一个。 .

重构 001 - 删除Java的Setter方法

978 4K

Setter方法违反了不变性并添加了意外耦合!重构步骤:找到 setter 的用法如果您正在设置基本属性,请将它们移动到构造函数并删除该方法如果你需要改变一个偶然的属性,它不是一个 setter。删除.

技术债务让51%的工程师考虑辞职 - venturebeat

1497 3
根据Stepsize 的一项新研究,51% 的工程师因技术债务而离职或考虑离职。这解释了为什么薪酬和成长机会可能不足以让工程师满意;技术债务会导致挫折并阻碍创新。在高层次上,技术债务是由质量和速度之间.

成熟机器学习系统持续改进面临的问题 - danshiebler

812

任何在大公司建立机器学习模型的人都会认识到。对成熟的机器学习系统进行可衡量的改进是极其困难的:机器学习系统极其复杂,并且具有破坏软件组件之间抽象的令人沮丧的能力。这对 ML 成功必不可少的迭代开发类型.

用 set或map修复if-else的坏味道 - egkatzioura

1227 1 3K

有时,我们的代码库中可能会出现一些巨大的“if”语句。必须维护这些语句并一遍又一遍地更改相同的代码块。这在“if”语句检查变量是否属于某个值范围的情况下也很常见。假设你有一个枚举:public enu.

幽默:重建模、重建和重构

1684 1
业务:重建模remodeling架构:重建reconstructing开发:重构refactoring 重建模与重构的区别三者目标:解决Bug!.

APIClarity如何解决API安全性的重构?

1265

API 重构是通过观察进出该 API 的流量来构建 API 规范。如果做得好,API 重构可让您了解微服务使用的 API,并使您能够评估 API 安全风险。构建规范后,相同的工具可以将运行时流量与规范.

重建模与重构的区别

2866 5
Refactoring is tactical, remodelling is strategic.重构是战术性的!  重新建模是战略性的。重构好像已经变成了提高软件质量的专有名词,这个词语是由Mar.

软件开发重点放在重用上是错误的 - Grady

1438 1

根据我的经验,将软件开发重点放在重用上是错误的。相反,专注于重构文化:这不仅会产生质量越来越高的更简单的软件,而且随着时间的推移,重用将以模式和框架的形式出现。 众说纷纭:只有当我们注意到我们一次又一.

将if-else之类嵌套循环重构为函数式管道 - XP123

1252 1 7K

嵌套结构难以阅读;管道stream通常更容易阅读和思考。嵌套结构具有“厄运之箭”的感觉,您需要同时管理所有父结构的上下文;而管道stream通常是线性的。 许多语言都添加了“函数式管道”风格,建立在首.

幽默:重构的德文定义

712 1

重构这个词语refactoring的德文定义:verschlimm bessern(V )to make something worse by a well-meaningbut misguided .

Share Pie: 隐藏的DDD宝藏 -Nick

2185 4 5K

领域驱动设计中有一个重要方面很少被提及。我认为这是 DDD 最重要的方面,但是如果您在网上搜索“领域驱动设计”,您不会找到它。这件宝藏一直隐藏在人们的视线中。这是 Eric Evans 的 DDD 书.

一位程序员如何花20年编写700,000行代码的游戏?

908 1

矮人要塞(Dwarf Fortress)是一款免费游戏,可以随机生成的幻想世界中扮演冒险家或充满矮人的堡垒。这一切都发生在一个 ASCII 界面中。整个游戏是开发者 Tarn Adams(又名 Toa.

在将单体迁移到微服务之前需要了解的模式 - Abhishek

1039 1

正确实施时,微服务比单体应用具有很多优势。许多组织希望将其单体应用程序代码更改为微服务代码。事实证明,迁移到微服务并不容易。您应该问的第一个问题是,您真的需要微服务吗?单体的许多问题可以通过使用模块化.

无法理解的程序Bug分类大全 - jvns

1522 2 5K

以下是无法理解Bug分类:很难复制你不太了解整个系统很难获得有关Bug的数据你的假设之一是错误的这个bug真的很复杂 1.本地难以重现的bug那些让我考虑转行的bug通常只发生在少数用户身上,无法由通.

从 CRUD 迁移到事件溯源的秘诀 - eventstore

1262 2 3K

事件溯源是高性能协作域的一种很好的架构风格,可以保证它增加的复杂性。但正如我之前所说,就像任何其他原则或实践一样,即使是事件溯源也有利有弊。而且它不是顶级架构。您系统的某些部分可能会从中受益,但其他部.

为什么程序员会有最喜欢与最讨厌的编程语言?(earthly)

1742 1 5K
Stack Overflow的2020年调查结果对“最恐惧的编程语言”和“最喜欢的编程语言”进行了排名。这两个排名都来自这个问题:在过去的一年中,您完成了哪些编程,脚本和标记语言的广泛开发工作,并且在.

乱弹马斯克与比尔盖茨两位首富的不同思维模式

2394 4

比尔盖茨在地球范围内搞内卷化,马斯克着眼火星外卷化,这是他们两个方向性最大不同:马斯克和比尔盖茨曾经先后成为过世界首富,但是他们的思维模式不同,比尔盖茨做了很多慈善项目,主要是立足于地球这个边界内,让.

单一责任SRP设计举例 - macerub

1061 1
单一责任/职责原则(SRP):“一个模块应该只承担一个责任”。 示例:客户Customer类。 generateInvoice:计算客户必须支付的金额。  computeDiscount:为客户返回%.

在不了解业务上下文情况下请容忍软件瑕疵Bug - jackhodkinson

1107 1

牢记业务上下文的技术决策建议,业务上下文是唯一的衡量软件质量的关键指标。如果有事情不对劲,软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地,我们对更高层次的抽象感到不安:我们.