在我的工程计算中干燥时有多少是太多了？ [关闭]答案

【问题标题】：How much is too much when being DRY in my engineering computations? [closed]在我的工程计算中干燥时有多少是太多了？ [关闭]
【发布时间】：2021-08-23 07:57:36
【问题描述】：

我是一名工科学生，我必须提交运行模拟代码的项目。计算全部在 Python 中进行，但推导/设置是在纸上完成并包含在报告中。我有时会发现自己在复制和粘贴重复图形或数值模拟的代码，所以我想为这些编写函数（试图在 DRY 方面做得更好）。

在编写函数来做这些事情时，我担心我“隐藏”了函数背后的许多代码。例如，此函数将绘制两个仅在公差级别不同的模拟。这将用于检查 ode 数值模拟中的收敛性。

def plot_visual_convergence_check(odefunc, time, reltol):
    sol_1 = solve_ivp(odefunc, time, (0,0), rtol=reltol)
    sol_2 = solve_ivp(odefunc, time, (0,0), rtol=reltol/100)
    
    plt.text('rtol is...')
    plt.text('rtol for the increased tolerance is...')
    plt.plot(<both plots together>)
    return plt.show()

在这里，所有运行solve_ivp 的业务仅在相对容差方面有所不同，并将它们绘制成一个场景。我不认为人们会想要细节，只是输出和确认“是”模拟已经收敛。我什至在图表上都写了两个 rtol，以便在不显示代码的情况下更清楚地了解使用了哪些值。

是否可以将这些类型的操作封装起来（因为我认为这样看起来更简洁），还是作为工程师将所有内容都布置好让每个人都可以看到而不必滚动到函数定义会更好？

【问题讨论】：

函数的主要好处之一是隐藏了实现细节。将“电线”暴露在各处会使您的代码更难阅读，因为要了解正在发生的事情，您需要筛选更高级别的逻辑和做出贡献的较低级别的细节。如果有人想查看函数是如何实现的，他们可以查看您的定义。只要函数公开的接口（传入和传出的内容）有意义，您通常可以通过包装代码并将定义移至别处而受益。
只要函数名称是描述性的，参数名称是可以理解的，并且您编写一个文档字符串来解释函数应该做什么（而不是它是如何做的），那就太好了。所有现代编辑器都可以让用户快速导航到该功能，然后再返回给想知道香肠是如何制作的人。
This section DRY 原则上的维基百科文章提到了称为 AHA（避免仓促抽象）的东西，这正是您所要求的。它包含几个指向该主题的外部参考资料的链接（非常好）。

标签： python dry organization readability computation

【解决方案1】：

根据我的经验，在编写要重用的库和代码时，干原则更为重要。但是我的经验是，如果您想制作报告，那么有时让事情变干实际上会使事情变得更难维护。 IE。有时您希望能够在一个地方更改单个图形/绘图/数据片段，而不会影响报告的其余部分。需要一些实践和经验才能找出最适合您的方法。在这个特定的用例中，在编写库或应用程序时不要那么关注遵循 DRY 规则。

另外，如果我必须做出这样的报告并且情况允许的话。我会在 Jupyter 笔记本中使用。在这里，您可以很好地将代码与文本和图形输出混合在一起。

【讨论】：