在编程活动中，比性能更重要东西是什么？-CSDN博客

本文链接：https://blog.csdn.net/hebhljdx/article/details/140263116

我们在进行技术问题讨论的时候，经常会涉及到这个问题。许多开发者对性能优化非常着迷，甚至许多人养成了“唯性能至上”的思维方式，甚至成为一种“政治正确”的事情，容易考虑许多非主流的技术方案来提高性能。

本文希望说明一个观点：性能当然重要，但是还有比性能更重要的要素，在没有做好这些要素的时候，我们切勿对性能进行过早或过度的优化。

笔者曾经参与的一个项目踩的坑就是这个经验的正例。在一次技术方案评审中，一个开发者设计出了一种高性能列表控件，通过一系列特殊的规则和设计，实现了支持大量列表的高性能控件。由于采用了这个控件用作核心功能的基础，后来这个控件引发了一系列的BUG，导致我们项目几乎因此延期。现在开发计划重写一个新列表控件，老的列表控件放在哪不动，小Bug也不改了，因为谁都不敢动了。

为了更好地说明这个问题，笔者借一本书经典著作来阐述这个观点。

《The Elements of Programming Style》由Brian W. Kernighan和P. J. Plauger共同编写，首次出版于1974年。Brian W. Kernighan参与了Unix操作系统和AWK编程语言的开发，同时也是C编程语言的早期核心开发者。P. J. Plauger是是C语言标准化的核心委员，他们都是编程界的技术泰斗。
这本书强调了清晰、简洁和可读性在编程中的重要性，并提供了大量的代码示例和反面教材来说明怎样写出更好的代码，是最早对编程实践做出深入思考的书籍之一。能引领读者学习如何写出简洁、高效和优雅的程序。这本书对性能有以下观点和原则：

先做对, 再做快（Make it right before you make it faster.）
在追求代码的执行效率之前，应确保代码的正确性。正确性是软件的基础，如果程序不能正确执行其预期的任务，那么它的速度无关紧要。因此，在进行任何性能优化之前，首先要保证程序按照预期工作，且没有逻辑错误或缺陷。
先使其可靠, 再让其更快（Make it fail-safe before you make it faster.）
可靠性指的是软件在各种条件下都能稳定运行。如果一个技术优化技术方案破坏了程序的鲁棒性，那么则要非常谨慎地进行考虑。在提高性能之前，应确保程序能够优雅地处理错误、异常和边缘情况，确保系统的稳定性和数据安全。
先把代码弄干净, 再让它变快（Make it clear before you make it faster.）
清晰的代码是指易于理解和维护的代码。在追求更快的性能前，应该确保代码结构清晰、命名恰当、逻辑分明。清晰的代码更容易被其他开发者理解，也更容易识别出潜在的性能瓶颈和改进点。
别为一丁点“性能”就牺牲掉整洁（Don’t sacrifice clarity for small gains in “efficiency.”）
有时候，微小的性能提升可能需要复杂的代码更改，这会降低代码的清晰度和可维护性。这个原则建议我们权衡性能提升和代码清晰度之间的关系，不应该为了获得极小的性能提升而牺牲代码的整洁性。长远来看，保持代码的可读性和可维护性比短期的性能提升更为重要。
让你的编译器做简单的优化（Let your compiler do the simple optimizations.）
现代编译器非常强大，它们能够自动进行许多优化，比如消除冗余代码、优化循环、内联函数等。开发者应该专注于编写清晰、简洁的代码，而将那些简单的性能优化交给编译器去做。这样可以避免手动优化导致的复杂性，同时利用编译器的专业能力来提升程序性能。
结语：

这些原则提醒我们性能优化应该在不牺牲代码质量的前提下进行，软件的许多要素都是紧密耦合的，一个项目不可能在没有良好的可维护性的情况下能实现优秀的性能表现。
笔者曾经经历一个项目，性能表现在竞品中垫底。这是由于项目不重视性能导致的吗？不是的，而是项目代码质量低到一定程度，这没有必要的情况下没人敢优化了。

除此之外，现代软件的性能优化已经有足够好用的工具帮助我们找出性能瓶颈，编码阶段首先应该先处理好可靠和可维护性的问题，最后再用工具得出性能数据再进行有针对性的进行优化可以达到事半功倍的效果。

当然，在实际的技术方案设计过程中，需要考虑的因素有许多，对于经验丰富的开发者，能很好地平衡时间、成本、质量、性能等多方面要素，可以在有限的资源里获得最优解，不过要展开这个话题又是另一个故事了。