John Ousterhout最喜欢的说法–建筑系统的宝贵经验和建议

John Ousterhout is a professor of Deparment of Computer Science from Stanford University. One recent project he is working on is the RAMCloud, a “new class of storage, based entirely in DRAM, that is 2-3 orders of magnitude faster than existing storage systems”. He posts his “Favorite Sayings” on his homepage. These sayings are precious experience and advice for building systems and developing software and they deserves really careful reading.

John Ousterhout是斯坦福大学计算机科学系的教授。 他正在研究的一个最新项目是RAMCloud ，“一种完全基于DRAM的新型存储，比现有存储系统快2-3个数量级”。 他在他的主页上张贴了他的“ 最喜欢的话 ”。 这些谚语对于构建系统和开发软件是宝贵的经验和建议，值得我们认真阅读。

Some quotations that I found especially invaluable:

我发现一些特别有价值的报价：

关于性能优化： ∞ (About performance optimization: ∞)

Most real-world programs run plenty fast enough on today’s machines without any particular attention to performance. The real challenges are getting programs completed quickly, ensuring their quality, and managing the complexity of large applications. Thus the primary design criterion for software should be simplicity, not speed.

大多数现实世界的程序都可以在当今的计算机上以足够快的速度运行，而无需特别关注性能。 真正的挑战是如何快速完成程序，确保其质量以及管理大型应用程序的复杂性。 因此，软件的主要设计标准应该是简单性，而不是速度。

If you try to optimize the performance of an application during the initial construction you will add complexity that will impact the timely delivery and quality of the application and probably won’t help performance at all; in fact, it could actually reduce the performance (“faster” algorithms often have larger constant factors, meaning they are slower at small scale and only become more efficient at large scale). … So, don’t worry about performance until the application is running; if it isn’t fast enough, then go in and carefully measure to figure out where the performance bottlenecks are (they are likely to be in places you wouldn’t have guessed). Tune only the places where you have measured that there is an issue.

如果您尝试在初始构建过程中优化应用程序的性能，则会增加复杂性，这会影响应用程序的及时交付和质量，并且可能根本无法改善性能。 实际上，它实际上可能会降低性能（“更快”的算法通常具有较大的恒定因子，这意味着它们在小规模时速度较慢，而在大范围时效率更高）。 …因此，在应用程序运行之前，不必担心性能； 如果速度不够快，则请仔细测量以找出性能瓶颈所在的位置（它们很可能位于您可能不会猜到的位置）。 仅调整您认为有问题的地方。

关于直觉和分析： ∞ (About intuition and analysis: ∞)

Intuition is a wonderful thing. Once you have acquired knowledge and experience in an area, you start getting gut-level feelings about the right way to handle certain situations or problems, and these intuitions can save large amounts of time and effort. However, it’s easy to become overconfident and assume that your intuition is infallible, and this can lead to mistakes.

直觉是一件奇妙的事情。 一旦您掌握了某个领域的知识和经验，便会开始对处理某些情况或问题的正确方法有直觉，这些直觉可以节省大量的时间和精力。 但是，很容易变得过分自信，并认为您的直觉是无误的，这可能会导致错误。

One area where people frequently misuse their intuition is performance analysis. Developers often jump to conclusions about the source of a performance problem and run off to make changes without making measurements to be sure that the intuition is correct (“Of course it’s the xyz that is slow”). More often than not they are wrong, and the change ends up making the system more complicated without fixing the problem.

人们经常滥用直觉的领域之一就是绩效分析。 开发人员经常跳出有关性能问题根源的结论，然后在不进行测量以确保直觉正确的情况下做出更改（“当然，xyz太慢了”）。 它们常常是错误的，而更改最终会使系统变得更加复杂，而无法解决问题。

关于事实和概念： ∞ (About facts and concepts: ∞)

… before you can appreciate or develop a concept you need to observe a large number of facts related to the concept. This has implications both for teaching and for working in unfamiliar areas.

……在欣赏或发展一个概念之前，您需要观察与该概念相关的大量事实。 这对于教学和在陌生领域的工作都有影响。

关于解决问题： ∞ (About problem fixing: ∞)

Don’t ever assume that a problem has been fixed until you can identify the exact lines of code that caused it and convince yourself that the particular code really explains the behavior you have seen. Ideally you should create a test case that reliably reproduces the problem, make your fix, and then use that test case to verify that the problem is gone.

除非确定问题的确切代码行并说服自己特定代码确实可以解释您所看到的行为，否则请不要以为问题已得到解决。 理想情况下，您应该创建一个能够可靠地重现问题的测试用例，进行修复，然后使用该测试用例来验证问题是否消失。

关于软件项目进度： ∞ (About software project progress: ∞)

My rule of thumb is that when you think you are finished with a software project (coded, tested, and documented, and ready for QA or production use) you are really only 50-75% done. In other words, if you spent 3 months in initial construction, plan on spending another 4-8 weeks in follow-up work. One way to minimize this problem is to get your new software in use as soon as possible. If you can create a skeletal version that is still useful, get people trying it out so you can find out about problems before you think you’re finished.

我的经验法则是，当您认为完成软件项目（编码，测试和记录并准备进行质量检查或生产使用）时，实际上只完成了50-75％。 换句话说，如果您花了3个月的初期建设时间，请计划再花4-8周的时间进行后续工作。 最小化此问题的一种方法是尽快使您的新软件投入使用。 如果您可以创建仍然有用的骨架版本，请让人们尝试一下，以便在您认为自己还没有完成之前就找出问题。

关于软件改进： ∞ (About software improvement: ∞)

No software is ever gotten right the first time. The only way to produce high-quality software is to keep improving and improving it. There are 2 kinds of software in the world: software that starts out crappy and eventually becomes great, and software that starts out crappy and stays that way.

第一次没有正确的软件。 制作高质量软件的唯一方法是不断改进和改进。 世界上有2种软件：一开始就糟透了，最终变得很棒的软件，以及一开始就糟透了，并保持这种状态的软件。

其他一些： ∞ (Some others: ∞)

The only thing worse than a problem that happens all the time is a problem that doesn’t happen all the time

比一直发生的问题更糟的是，并非一直发生的问题

… if you admit that you don’t know the answer, or that you made a mistake, you build credibility. People are more likely to trust you when you say that you do have the answer, because they have seen that you don’t make things up.

…如果您承认自己不知道答案，或者您犯了一个错误，那么您将建立信誉。 当您说自己有答案时，人们更有可能信任您，因为他们已经看到您没有做好准备。

Coherent systems often have advantages of efficiency, which is why humans gravitate towards them. … Unfortunately, coherent systems are unstable: if a problem arises it can wipe out the whole system very quickly.

连贯的系统通常具有效率的优势，这就是为什么人们倾向于它们。 …不幸的是，连贯的系统是不稳定的：如果出现问题，它会很快擦除整个系统。

Enjoy the full “Favorite Sayings” on John Outsterhout’s homepage.

在John Outsterhout的主页上享受完整的“ 最喜欢的说法”。

翻译自: https://www.systutorials.com/favorite-sayings-by-john-ousterhout-precious-experience-and-advice-for-building-systems/