性能与可读性

阅读这个问题我发现这是(注意引号)"代码"来解决问题(顺便说一下,这是perl).

100,{)..3%!'Fizz'*\5%!'Buzz'*+\or}%n*

显然这是一个没有真实的智力实例(我希望永远不会在我生活中的真实代码中看到它),但是,当你必须做出选择时,你何时牺牲代码的可读性才能获得性能？你是否只是应用常识,你是否总是作为最后的手段？你有什么策略？

编辑:对不起,看到答案我可能已经表达了严重的问题(英语不是我的母语).我不是说你编写代码后的性能与可读性,我在你写之前也会问.有时你可以通过制作一些较暗的设计或提供一些会使你的课程变暗的属性来预见未来的性能提升.您可能决定使用多个线程或仅使用一个线程,因为您期望这些线程可以提供的可伸缩性,即使这会使代码更难以理解.

在我认为性能可能成为问题的情况下我的流程:

让它起作用.

讲清楚.

测试性能.

如果存在有意义的性能问题:重构速度.

请注意,这不适用于更高级别的设计决策,这些决策在以后更难以更改.

我总是从我能想到的最易读的版本开始.如果性能是一个问题,我重构.如果可读版本难以概括,我重构.

关键是要进行良好的测试,以便重构很容易.

我认为可读性是代码中最重要的问题,尽管正常工作紧随其后.

可读性是最重要的.使用现代计算机,只有最苛刻的应用程序中最密集的例程需要过多担心性能.