Performance 如何向上司解释代码/资源优化很重要？

啊哈，每一次都是如此令人沮丧

我们的托管公司有一个专用服务器，每次我必须写下一个新的应用程序（或添加到一个已有的应用程序），我都会“浪费”一些时间来优化许多行为的代码（减少db查询、优化db结构、减少bandwith等），这取决于应用程序应该做什么

很明显，问题不在于我写了糟糕的代码然后重新编译，而在于项目完成后，我总能找到一些可以做得更好的东西

每次，如果我的老板发现我这么做，他都会说‘你在浪费时间！如果应用程序需要更多的资源，我们会购买更多的RAM、更多的CPU或更多的bandwith！'

什么是最好（也是最简单）的方式来解释优化仍然很重要，而不是那么容易或自动升级（生产！）服务器的硬件

---

编辑：我说的不仅仅是数据库优化，而是应用程序的每一个方面

在下次移动/升级服务器时都要做详细的记录和时间表，并对由此产生的每一分钟工作（包括之后几周内的事情）进行约定。然后你会有确凿的证据证明升级是昂贵的，而优化有助于推迟投资

在目前的情况下，您可能可以使用基准测试和统计数据来做一些事情，比如“如果没有我的优化，服务器的容量将达到90%，用户数为X。通过我的优化，我们可以在获得新机器之前满足Y个用户的更多需求。”

---

另一方面，优化和过度优化之间的界限很窄。虽然编写不浪费资源的代码是一项很好的技能，应该是一项人权，但如今RAM和磁盘空间非常便宜。优化也会使代码更复杂，更难为其他人维护。当您控制自己的硬件时，代码优化可能并不总是首要目标。

等待，直到购买RAM和CPU变得比花钱优化代码更昂贵。那你就有理由了。

很可能你真的在浪费时间。你在大学里学到的大多数优化在商业世界里都是无关紧要的。我建议专注于那些优化，你可以量化为什么你的优化值得你公司的钱（你花的时间就是他们花的钱）。

如果你使用的是关系数据库（并且你不使用琐碎的应用程序）。。。。您不能编写错误的数据库查询。因为您使用的是一个红色的gate标记，所以我假设您在SQL server上。如果您在SQL Server数据库服务器上设计了一个糟糕的模式（包括查询），当您开始获得中等流量时，您将被迫以可怕的方式进行扩展。一旦你获得了高水平的流量，你就会被搞砸，需要聘请一位非常昂贵的顾问/DBA来解决这一混乱局面

我想说的是，即使SQL是声明性的，而且您似乎不必关注性能——它实际上并不是这样工作的。您必须在设计数据模型时牢记其使用方式

---

如果您正在应用程序代码中编写业务逻辑。。。这没什么大不了的——如果性能成了问题，您可以用更少的麻烦来解决后者。如今，大多数业务逻辑都是无状态的（尤其是在基于web或基于web服务的情况下）这意味着你可以在这个问题上扔掉更多的机器——如果不是比这更难的话。

每当某件事情需要比提前完成重构所需要的时间更长的时间时，请确保你的老板知道它。

优化通常只是浪费时间，更重要的是优化可维护性：

- keep the code simple (see: KISS)
- move duplicate code into functions (see: DRY)
- optimize comments (as few comments as possible, as many as necessary)
- remove unused code

---

这些更改不一定会影响程序的速度，但它们减少了实施更改和修复错误所需的时间，因此它们具有真正的业务价值，因为它们节省了昂贵的开发人员时间。

如果您必须解释为什么需要优化，那么您已经走上了低获胜率的道路。不幸的是，最好的论据是当性能成为一个明显的问题时（例如，客户抱怨）-这会让人们坐起来倾听，如果他们经常对此感到耳痛。通常情况下，解决方案可能是向其扔硬件是最好/最便宜的解决方案

然而，对我来说，性能很重要，当在高可扩展系统上工作时，您需要花时间进行优化。它至少应该在您开发过程中出现在您的脑海中，并且在开发过程中会有很多东西被吞没（而不是在您完成之后，再回到优化）

e、 g.
-如果我的数据库有100000000条记录而不是100000条，会发生什么？（您可以很容易地愚弄SQL Server，使其认为表中的记录比实际记录多，以查看对执行计划的影响）

如果你对优化持积极态度（我个人认为这是很好的），那么你需要试着给你的老板一个真实世界的意义。e、 g.“如果我们通过减少页面大小来优化我们的网站，我们每个月可以节省x数量的带宽，为我们节省xx很多钱”

---

你必须小心微优化，因为你可以在奶牛回家之前进行微优化，以获得低得多的收益。

在我看来，这不是一个说服需要进行优化的案例（根据你老板的回答，你不会赢得这场斗争），还有一种情况是，总是将重构时间构建到您的估算中。

您是否有应用程序的性能目标？免费容量、响应时间、带宽使用情况等