在速度较慢的机器上开发优化是否过早?

也就是说,您应该在可用的最快机器上开发。是的,任何慢下来的东西都会带来刺激,并鼓励你纠正慢下来的问题,但代价很高:

当你分心时,等待程序编译会让一堆bug、潜在问题和修复从你的脑海中消失。等待一个对话框加载,或一个查询完成,同样会打断您。

即使你忽略了这一影响,你仍然得到了后面陈述的真相——早期的优化会让你在原地打转,破坏已经运行的代码,猜测(通常准确度很低)事情可能陷入困境的地方。首先要正确地设计代码,你可以忘记优化,直到它有机会适应一点,在这一点上,任何必要的优化都是显而易见的。

如果您的测试数据在一个表中只有几百行,那么您的数据库将缓存所有数据,并且您永远不会发现写得不好的查询或不好的表/索引设计。如果您的服务器应用程序不是多线程服务器,那么在对500个用户进行压力测试之前,您不会发现这一点。或者如果应用程序在带宽上出现瓶颈。

优化是“一件好事”,但正如我对那些对如何更好地实现它有各种想法的新开发人员所说的,“我不在乎你多快给我错误的答案”。先把它做好,然后在发现瓶颈时加快速度。一个有经验的程序员将从一开始就合理地设计和构建它。

此外,他们还会拿出一个经典的程序员借口——“但它运行缓慢,因为我们特意选择了速度较慢的计算机,当我们部署它时,它将运行得更快。”

我想这将取决于你在制作什么,以及目标受众是什么。

如果您正在开发桌面应用程序或该领域的其他应用程序,那么可以在您想要的任何机器上开发,然后对其进行调优,使其在所需的min spec硬件上运行。类似地,如果您正在开发内部软件,公司想要购买的机器可能有一个最小规格。在这种情况下,在快速的机器上开发(以减少开发时间和成本),并根据min-spec进行测试。

最重要的是,在最快的机器上进行开发,并在最少或精确的硬件上进行测试。

我已经看到足够多的程序员因为他们的机器比大多数用户快得多而受到严重但意想不到的问题的影响。但是,我也看到同样的问题发生在数据上。代码在一个小数据集上测试,然后在一个大数据集上“崩溃”。

开发和部署环境中的任何差异都可能是意外问题的根源。

尽管如此,由于编程既昂贵又耗时,如果最终用户运行的是过时的设备,那么更好的解决方案是在测试时处理它(并安排一些早期测试,只是为了检查可用性和时间)。

为什么仅仅因为担心遗漏一个潜在的问题就让你的程序员瘫痪?这不是一个明智的发展战略。

保罗。

您的最终用户将使用什么平台? 我可以放下自行车吗?如果我这样做会发生什么?

我同意大多数人的观点,最初的开发应该在最快或最有效的机器上完成(不一定是同一台机器)。但是要运行测试,请在您的目标平台上运行它,并经常和尽早地进行测试。

当您的开发周期接近“今天”时,您的开发机器应该接近客户机的当前“平均”速度。

大多数时候,我运行的是调试构建,这已经足够慢了。

我认为这是一个合理的概念(但可能是因为它对我有用)。

如果我的开发人员工作站速度太快,我发现我没有充分地思考想法,因为在重新生成软件映像或将其下载到目标时几乎没有时间损失。我想说,至少有一半的下载是不必要的,因为我只记得在调试代码之前错过了一些东西。

对于服务器应用程序,我认为最好使用(远)性能较低的硬件进行测试。两个或四个磁芯,而不是十六个(或更多)。1.6GHz istdo 2.8。这个名单还有很多。服务器通常是系统架构中的一个瓶颈,这是因为每个人都在与它交谈。在您开始为它开发(服务器)应用程序之前,这已经是很久以前的事了。