Question

例如：当我们生成报告时，我们知道特定的代码块将来不会在任何其他地方使用，但它有数百行。假设我们用10种小方法破解该代码，现在当我们导出1000个项目的报告时，将10个方法调用1000次或者只是保持简单而不破解方法是好的。

Answer 1

任何具有100行代码的方法都不利于可维护性和复杂性。我的建议是保持每个函数最多20行。

Answer 2

始终牢记可维护性。我喜欢这样的情况我喜欢在子步骤中拆分Main方法，并且主方法看起来像：

MainMethod(){
   step1();
   step2();
   step3();
   ...
}

通过这种方式，您可以查看它并快速了解它在高级别所做的工作。如果需要，您可以逐步完成步骤并获取执行细节。可以对步骤应用相同的方法：您可以按子步骤划分它们并获得相同的结果，让读者对步骤进行高级概述，并让他在需要时逐步了解详细信息。

这种方法的理想情况是步骤之间的交互是有限的，因为您不必担心在步骤之间传递数据。

Answer 3

如果你能这样写：

GenerateReport(){
   var myReport = new ReportHelper();
   myReport.addPieChart(getSalesByCategories());
   myReport.addTable(getTopProducts(10));
   ...
   return myReport;
}

去吧。

创建一个帮助类，让您的生活更轻松（或找到一个）。这个帮助器类的方法可以是addTable（），addPieChart（），它们都接受对象。使用简单的函数，确保它们的名称是自我解释的（一如既往）并按执行顺序编写它们，您的代码将更具可读性。 main函数将包含对所有子函数的调用，将其放在开头，这将是未来开发人员稍后理解整个过程的一个很好的切入点。它可以更容易地跳到正确的位置来改变一些东西。你也可以为每个小函数编写测试，而你不能用于庞大的庞大方法。值得写一个帮助类来简化报告生成，所以它们看起来都像这样。

现实生活：我们在这里谈论一个报告生成器。它是应用程序中代码的一部分，它不与代码的其他部分交互。我想没有计划的测试（这很糟糕）。每个功能可能需要前面步骤中的数据，并且非常复杂。在一个流程中编写它可能更容易。它将避免使用全局变量，传递十几个参数...但请确保每10-20行放置注释，就像您将使用上述函数声明一样。我建议在开头添加一个过程的描述（它看起来像另一个案例的主要功能）。这里的问题是未来的维护者可以改变代码而不是反映主要流程解释的变化，而他将被迫用小函数来做。

对我而言，这取决于使用的语言，我更喜欢小功能（理论），但我经常写意大利面条代码（现实）。我需要重用一部分代码时创建函数。它还取决于使用的语言。我不喜欢写'这个'。在所有变量前面引用全局变量。

关于性能，每个函数调用都需要一点时间，但对于这种情况没有任何区别。

在多种方法中打破非重复代码是否更好？

3 个答案: