你是精英。 您完全了解Clean Code,梦想着实现SOLID设计,并且对编写的每一行进行单元测试。 您的代码是如此自我记录,您甚至无需编写注释!

那么这只蚂蚁就适合你! 因为让我告诉你一些事情:没有注释,使用代码仍然是一件令人痛苦的事情。 无论您多么精明,代码多么出色,如果没有一些明智的解释,它仍然是一堆无法使用且无法维护的烂摊子。

我以前从不抱怨-至少不是在这里-但我现在必须这样做,否则我的头会爆炸! 所以,请原谅我的语气。 冷静下来之后,我将写一篇关于该主题的文章。

自我证明代码

下次当我偶然发现界面或您的类中具有零评论的界面时,我发誓我要追捕您,将您的双腿咬掉。

但是,代码是自记录的,您说呢? 它是SOLID,格式正确,使用可表达的名称,由简短的方法和类组成,并且已经过全面测试? 不需要评论吗?

关于合同的故事

让我们从一个故事开始……

想象一下,如果您正在寻找一种保险,以免家人被卡车撞倒,可以避免家人流落街头。 您决定了一项政策,并要求公司签订合同,以便您可以签署该合同。 但猜猜怎么了? 他们不再签合同了! 取而代之的是,他们采取了“对未读合同的工作公司”的政策。

他们将很高兴地邀请您前往其总部,在这里您可以随意欣赏其清晰的组织结构,在其经过专业设计的建筑物和公园中漫步,并与他们的数千名专注的员工进行交谈。 的确,您应该来,这些人和女舞者甚至都拥有Mitch和Dorothee之类的好名字!

他们还想给您现有的客户清单。 您可以打电话给他们,以了解他们与公司的关系。 考虑到他们的个人历史和付款方式,当他们发生任何事情时,公司会怎么做? 顺便说一句,您甚至也可以参观他们的家!

因此,您问他们,这将如何下降? 容易,只要开始给我们每月布线,他们就会回答。

很棒的自我证明保险单! 但是您会以家人的幸福来信任他们吗?

测验

现在让我们回到代码。 到现在为止,您也许可以发现同意的行为与观察到的行为之间的差异。 那测试呢? 我听到你问,他们不定义预期的行为吗?

你在拖钓,对不对? 现在,我不仅要检查您的实现,还要进行大量测试? 因此,我现在不去编写代码,而是研究数十种测试方法,以希望找出一种能反映我的用例的方法? 所有这些推断出我是否可以期望不返回null?

嗯是的 不幸的是,您甚至无法在单元测试中证明这一点。 除非您设法通过示例证明“所有人”定理,否则这确实令人印象深刻。 您在测试中无法清楚记录的其他内容? 只有微不足道的细节,例如线程安全性(或缺乏安全性)和不变性。

另外,如果您信任测试可以记录代码,则最好确保人们因未达到90%以上的测试覆盖率而被解雇。 根据我的经验,“不编写测试”和“不编写文档”开发人员存在很多重叠。

最后,您是否知道有多少社区会使用RTFT回答问题-阅读他妈的测试? 没有? 那我当时在想什么呢?

名字

但是,您的名字富有表现力,您说呢? 他们会节省一天的时间! 真? 这是我在阅读文档时可能需要的东西:

  • 有哪些先决条件,特别是关于我要传递的论点?
  • 关于返回值有什么保证?
  • 参数和返回值使用什么单位?
  • 线程安全性,可变性,不变性或依赖性又如何呢?
  • 在什么情况下会引发异常?

不要告诉我,您把所有这些都塞进了您的名字,因为您没有。 而且不要告诉我,它总是显而易见的,因为事实并非如此。 顺便说一句,我也对您为什么选择当前设计感兴趣。 我不知道这怎么适合变量名。

以及这种表达性命名对于接口究竟如何起作用? 我可以告诉你怎么做:一点也不! 还是您希望我理解所有十二种实现,以了解它们是否应该是不变的。

我也很好奇您的同事将如何实现一个未记录的接口。 因为如我所见,他们基本上可以做任何他们想做的事。

猜测

因此,下次您开始使用新图书馆时,请吃自己的狗食。 忽略文档!

通过查看代码来猜测,如果不存在**,Java的Map.get可能返回什么。 看一下ConcurrentHashMap并告诉我是否允许空键。 无需任何介绍即可使用番石榴的TypeTokenCache 使用反射而不看注释。

你说什么? 这些都是API吗? 这是完全不同的吗? 认真吗? 他妈的到底有什么不同? 我不在乎是使用API®还是调用您的代码-它可以告诉我它是做什么的,或者我会猜测。

猜猜……因为如果您不告诉我会发生什么,那就是我会做的。 您真的认为我将遍历所有五个实现和单元测试的三位数,以找出方法的作用? 没有! 我会做一个有根据的猜测,因为我很着急,必须把事情做好。

那不是敏捷的目标吗? 让开发人员减少猜测?

谈到敏捷

我们从“我们不写文档是因为讨厌文档”变为“我们不写文档是因为我们重视工作代码而不是全面的文档”。 因此,现在我们像以前一样忽略文档,但最终由于我们的代码突然变得很棒而被允许? 是的,对...

因此,请不要相信这个废话,而要记下《敏捷宣言》如何不说“我们不发表评论”。

老化评论

但是评论年龄,您说呢? 这就像在说“车祸”。 是的,他们偶尔这样做。 (顺便说一句,在大多数情况下,由于某种形式的过失而应受到法律的制裁。)但这并不能阻止我们使用它们。 这并不意味着我们不负责尝试防止这种情况的发生。

另外,我很想听听您似乎正在使用的魔术编译器。 防止包,类,字段,方法和变量名老化的程序。 可以在更改代码时使它们保持最新和准确的状态。

哦,没有这样的事吗? 令人震惊! 您正在更新它们吗? 恭喜你! 现在成为负责任的小开发人员,并在该过程中包含这些评论,我们很好。

评论您的他妈的代码!

因此,请不要再太忙了,而只在此处和此处添加有用的评论。 哪里? 我将在下一篇文章中进行介绍。

翻译自: https://www.javacodegeeks.com/2015/07/comment-your-fucking-code.html

相关文章:

  • 2021-06-16
  • 2021-10-04
  • 2021-09-28
  • 2021-06-12
  • 2021-08-07
  • 2021-07-18
  • 2022-12-23
  • 2021-11-21
猜你喜欢
  • 2022-12-23
  • 2022-12-23
  • 2021-11-04
  • 2021-10-09
  • 2022-12-23
  • 2022-12-23
  • 2022-01-07
相关资源
相似解决方案