我们的托管公司有一个专用服务器，每次我必须写下一个新的应用程序（或添加到一个预先存在的应用程序），我会“丢失”一段时间来优化许多行为的代码（减少数据库查询，优化数据库结构，减少带宽等），具体取决于应用程序应该做什么。
显然，关键不在于我编写错误代码然后重建它，只是在项目完成后，我总是发现可以做的事情更好。
每次，如果我的老板抓住我这样做，他会说'你在浪费你的时间！如果应用程序需要更多资源，我们会购买更多RAM，更多CPU或更多带宽！'。
最好（也是最简单）的方法是什么，以解释优化仍然很重要，这不是那么容易或自动升级（生产！）服务器的硬件？
编辑：我不仅仅谈论数据库优化，而是谈论应用程序的每个方面
答案 0 :(得分：14)
你真的在浪费时间。您在大学或大学学到的大多数优化在商业世界中都是无关紧要的。我建议您专注于那些可以量化的优化，为什么您的优化值得您公司的资金（您花费的时间是他们花的钱）。
答案 1 :(得分：8)
尝试优化代码时，您需要遵循优化周期。没有捷径。
从你的帖子看起来听起来并不像你做过1或2，所以你跳过了3和4，因为你不知道做到这一点，并且现在盲目地磕磕绊绊地试图优化无论你认为什么需要优化。
所以从你所说的话来说，我必须同意你的老板。你是在浪费时间。或者至少你没有遵循足够的过程来证明其他方面，这基本上是相同的。
答案 2 :(得分：6)
下次进行服务器移动/升级时，请保留详细的说明和时间表，以及从中产生的每分钟工作的协议（包括几周后的事情）。然后你就会有确凿的证据证明升级是昂贵的，优化有助于延迟投资。
在目前的情况下，您可以使用基准测试和统计数据执行某些操作：“如果没有我的优化，服务器将以90％的容量使用X个用户。通过我的优化，我们可以满足在我们必须购买新机器之前，Y用户更多。“
另一方面，优化和过度优化之间的界限很薄。虽然编写不浪费浪费资源的代码是一种很好的工艺并且应该是一项人权，但RAM和磁盘空间现在非常便宜。优化还会使代码更复杂，并且更难以维护其他代码。当您控制自己的硬件时，代码优化可能并不总是最重要的目标。
答案 3 :(得分：4)
您是否有应用程序的性能目标？可用容量，响应时间，带宽使用等。如果没有它们，您将发现很难证明为什么需要进行改进。在人们花钱之前，你需要能够量化问题。
如果申请已满足要求，那么你的老板可能是对的。
为了确保未来客户的预留容量，您（和您的老板）可以设置一个威胁，以便一旦性能达到调查问题所需的一定百分比。这是您请求/推送/执行优化的时间，因为他将意识到问题以及无所事事的风险。如果您可以推荐一些更改来纠正比硬件成本低的问题，那么希望他能同意让您这样做。当然反过来仍然适用。如果硬件升级的总成本更便宜，那么这可能是更好的选择。
答案 4 :(得分：3)
等到购买RAM和CPU变得比支付优惠代码更贵。那你有一个案例。
答案 5 :(得分：2)
在改进软件与改进硬件之间存在一个收支平衡点。对于桌面系统，一个好的门槛是购买时间：
如果该机器出现故障，您可以在一小时内到达下一个商场购买替代品吗？
只要你能回答是，优化是徒劳的 - 也许是对未来的投资，但这真的是你的决定吗？
网站的类似规则可能是“获得新托管合同需要多长时间？”
这并不完美，它只涵盖了可扩展性的一个方面。我喜欢它，因为它是一个易于理解的外部技术问题。
当然，如果这个方面突然被消除，你应该有更多的材料。只需询问几个关键方案的公司/老板计划是什么有帮助。 - 例如DDOS攻击的应急计划，“匆忙事件”等。有一些数据支持，一些关键的故事（“foo在流行的夜间节目中提到，网络服务器在请求下崩溃，业务丢失，潜在客户激怒” ）很有帮助。
要意识到的关键是（假设仅根据您的描述），您有责任预见此类事件，并提供技术解决方案，但您不应负责做出这些决定。
另外，从你的老板那里得到一份书面声明：“停机五小时不成问题，让他们去处理重要事情！”是一个很好的CYA。
答案 6 :(得分：2)
与开发人员解释代码/资源优化不重要的方式大致相同......
我猜这个问题的出现是因为你衡量重要性的方法与他的不同......
他的工作是关心金钱，并确保他从中得到“最大”...坦率地说，服务器比开发人员便宜......托管服务器比管理员便宜......丑陋的事实是的，很多人都这么认为......就个人而言，我认为PHP并不是应用程序性能关键部分的正确选择...也不是RMDBS ......但几乎每个托管服务器都运行PHP和MySQL商业客户更愿意拥有一个可以在任何地方运行的应用程序，基于众所周知的技术，结果是服务器端的PHP和MySQL ......世界是一个残酷的地方the truth is ugly ...现在说到你，你只有两个选择：
你的老板从他的角度来做正确的工作......你所做的是浪费公司资金，因为公司的目标不是编写漂亮且高度优化的代码......无论你的公司做什么，最终你只提供一个工具......并且工具的价值是通过它提供的与其所花费的资金相关的来衡量的......
如果你的优化在经济上是合理的，那么最简单的方法就是不再优化并等待你的老板来找你，要求加速......
我建议，你要么找新工作，要么专注于其他重要的事情：
这些目标对于软件项目的现在和未来都很重要（当涉及金钱时（特别是大胆的）...并且它们提供了在实际需要时进行优化的可能性 ...
这可能不是你想要的答案，但我希望它有所帮助......
答案 7 :(得分：1)
如果你在一个关系数据库（并且你没有使用普通的应用程序）....你负担不起编写错误的数据库查询。 由于您使用的是红门标记，我假设您使用的是SQL服务器。如果您在 SQL Server 上设计了一个错误的模式（包括查询），那么当您使用开始获得适度的流量，你将被迫以可怕的方式扩展。一旦你获得高流量，你将被搞砸 - 并且需要聘请一位非常昂贵的顾问/ DBA来解决混乱 - 与你的老板一起使用这个论点：D。
我想要得到的是即使SQL是声明性的，并且看起来你不必注意性能 - 它并没有真正起作用。您必须记住它的使用方式来设计您的数据模型。
如果您在应用程序代码中编写业务逻辑 ......那么无关紧要 - 如果性能成为问题，您可以更轻松地修复后者。如今，大多数业务逻辑都是无状态的（特别是如果它基于网络或基于Web服务）意味着你可以在这个问题上找到更多的机器 - 如果不是它只是更难一点。
答案 8 :(得分：1)
优化通常只是浪费时间，更重要的是优化可维护性：
- 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
这些更改不一定会影响程序的速度，但它们可以减少实施更改和修复错误所需的时间，因此它们具有真正的业务价值，因为它们可以节省昂贵的开发人员时间。
答案 9 :(得分：1)
如果您必须解释为什么需要优化，那么您已经处于低赢率路径。不幸的是，最好的论据是，在某种情况下，性能正在成为一个明显的问题（例如客户抱怨） - 这使得人们坐下来倾听，如果他们不断听到它的话。通常，解决方案可能是投掷硬件是最好/最便宜的解决方案。
但对我而言，性能非常重要，在高度可扩展的系统上工作时，您需要花时间进行优化。在你开发过程中，它至少应该在你的脑海中，并且在开发过程中可以吞噬很多东西（而不是在你完成之后，然后又回到优化之后）。
e.g。
- 如果我的数据库有100,000,000条记录而不是100,000条，会发生什么？ （您可以轻松地欺骗SQL Server，使其认为表中的记录比实际上有更多的记录可以看到对执行计划的影响）。
如果你主动优化（我个人认为这很好），那么你需要尝试为你的老板带来现实意义。例如“如果我们通过减少页面大小来优化我们的网站，我们可以节省x个月的带宽，为我们节省了多少钱。”
你必须要小心微观优化，因为你可以微量优化直到奶牛回家，效益低得多。
答案 10 :(得分：1)
你可以等到老板说“为什么这么长时间？”然后你可以说“嘿，老板，我们可以购买10倍的硬件，或者我可以花几天时间让它快10倍”。 Here's an example.
补充：如果你的老板说“嗯，你为什么一开始就放慢速度？”我可以毫不费力地解释他可以聘请上帝的右手程序员，并且首先编写的代码仍然有优化的空间。
答案 11 :(得分：0)
每当事情需要很长时间，如果提前完成重构，请确保你的老板听到它。
答案 12 :(得分：0)
国际海事组织，这不是一个说服需要进行优化的案例（并且基于你的老板的回应，你不会赢得这场斗争），更多的是总是在重构时间内建立你的估计。
答案 13 :(得分：0)
进行成本分析......
这需要我X小时，这意味着每个项目需要的数据存储量减少50％。基于我们每年平均使用100Gb空间进行2个项目，一年后节省Y，3年后节省Z.
粗略的例子，但它就足够了。
最终你和你的老板都错了......你认为代码必须快速（主要）来满足你的理想主义，他根本不关心他想要提供产品。