Question

我的同行正在撰写一份报告，显示我们小型咨询公司每位员工的每周（周日至周六）预付款。他编写了一段代码，显示了与目标周中的天数相对应的列。他的算法如下：

获取该月第一天的哪一天。如果是星期天，将标志设置为零;否则，将其设置为一个。
遍历月中的所有日子。如果是星期天，请递增旗帜。然后，如果标志的值等于要显示的周，则显示与当天相对应的列;否则，隐藏列。

当然，该标志表示当前周是什么。

我提出了另一种算法：

获取指定周的第一天（F）和最后一天（L）。例如，2009年10月的第一周从星期二的1日开始，到星期六的3日结束。
遍历对应于第1天到第F-1天的列，并隐藏它们。
遍历对应于天F到L的列，并显示它们。
遍历对应于天L + 1到DaysOfMonth的列，并隐藏它们。

我的算法中的“困难”部分是第1部分。我的意思是“难以”，因为“难以理解”，因为执行它的算法复杂性是不变的。我的算法具有更紧密的循环优势。我的同行循环对每月的每一天进行比较。我没有。

这是一个小例子，你可能会说这里的过度优化有点过于偏执。但是当我们编写实际的性能关键代码时，他的编程风格并没有改变。

他的代码也充满了这些测试：

/* doSomething() doesn't change the state of the relevant variables. */
if (condition)
{
    flag++;
    if (flag > test)
        doSomething();
}
else
    if (flag >= test)
        doSomething();

当然，可以这样做：

if (flag >= test);
    doSomething();
if (condition)
    flag++;

我该怎么办？！？！？！

编辑：我更正了代码示例中的比较。

Answer 1

我认为你的朋友有正确的想法。采用对算法来说明显正确的算法需要花费一个小时来解释，但是，如果没有特定的性能目标，则更快。

如果您有特定的性能要求，例如'代码需要能够在机器X上的200微秒内在未来十年内为所有月份提供正确的结果'，和更简单的代码如果没有要求，那么您可以考虑使用您的版本。

（您发布的代码示例确实在您的方式上更好，因为它不那么复杂。）

Answer 2

根据您的描述，我不确定我是否同意您的同事。这里的关键问题是这段代码是否是性能瓶颈。

要说服我切换到您的算法，您必须对有问题的应用程序进行概要分析，并告诉我这段代码对性能至关重要。然后进行更改并再次进行配置。这样你就有了客观的比较基础。

如果两种算法之间存在有意义的差异，那么你们俩可以讨论是否值得进行转换。

如果您担心网络应用程序的页面加载时间，请记住High Performance Web Sites和Yahoo performance guidelines的课程 - 如何处理CSS，javascript和缓存将比优化具有更大的影响在您的服务器上运行的算法。

在没有测量的情况下倡导优化与忽略天真算法的性能影响一样危险。

Answer 3

嗯，你不应该干涉，因为显然你错了......这两段代码并不相同。只需要条件= 1，flag = 0和test = 1

Answer 4

这是你的任务，还是他的？如果是他的，那就让他做吧。我是一个在效率上茁壮成长的人，事实上，当事情看起来效率低下而且我无法控制时，我会变得非常沮丧。

有超过200人在SO上可以让我最“有效”的想法，算法和代码感到羞耻。可能更多，你不能单独去代表。如果Linus Torvalds自己签约，他就会像我们其他人一样从1开始。

您必须考虑的是人们需要能够维护他们编写的代码。这意味着，他们必须理解它，好像他们生下了它一样。即使有人演示了另一种比我自己更有效的算法，我也不会使用它，除非我舒适使用它。

如果这是一个联合项目，请按照自己的方式写下来，展示速度，然后与同伴一起度过非常非常有耐心的时间，帮助他真正掌握它。

回顾5年前写的东西， 每个人都必须通过 来学习，每个人都以自己的速度做事，特别是学习。

Answer 5

天儿真好，

我建议你应该支持在你的约束条件下执行的算法简单性而不是那些没有实际收益的聪明，过于复杂的算法。根据我的经验，这些过于聪明的技巧很可能会成为未来的维护噩梦！

以下引用更好地表达了这个想法：

“有能力的程序员完全了解他自己头骨的严格限制;因此他完全谦虚地接近编程任务，除此之外，他还避免像瘟疫一样聪明的伎俩。” - Edsger Dijkstra在他1972年的ACM图灵讲座“The Humble Programmer”

BTW那篇论文很棒！以及他在E.W.Dijkstra Archive

在线提供的许多其他论文

HTH

欢呼声，

Answer 6

我在这里看不到问题......虽然他的版本有一点迂回的方式来达到目标，但他确实到了那里。

我要说的这句话不应该脱离背景：但是总会有人这样做 - 这没有错，恰恰相反......他可能不知道做某事的好方法，但无论他的方法多么丑陋，他都知道如何得到结果当没有人知道某些东西的正确算法时，这可能是一个真正的救生员......他可能会以某种方式将其录下来。

Answer 7

我同意这里普遍存在的观点：如果性能提升会使代码更难以阅读，那么最好有充分理由做出改变。

另一方面，这并不意味着我们应该永远满足首先想到的事情。有时，有明确优越的替代方案同样可读或几乎可读。

如果你想说服你的同事认真选择算法，你应该仔细挑选你的战斗。不要试图颠覆他的世界，并在你发现的每一个案例上强制解决问题。首先提出你的建议，只有当你能想到一个明显优越且清晰的替代算法时，如果他拒绝就准备退出。

如果你感到狡猾，你甚至可以给他提示，提出引导性问题，或者你能想到的任何其他技巧，以帮助他自己弄明白。

Answer 8

我感觉到你的痛苦。程序员本质上是顽固的。每个人都有自己的原则和规则来构建程序。如果其他一些观点与其他观点相冲突，那么改变程序员的观点就像是移动摩天大楼建筑的基础支柱。：）

我如何说服同行认为算法很重要？

8 个答案: