Это - преждевременная оптимизация для разработки на медленных машинах?

Думаю, это будет зависеть от того, что вы делаете и какова целевая аудитория.

Если вы пишете программное обеспечение для фиксированного оборудования (скажем, консольных игр), используйте оборудование (по крайней мере, тестовое оборудование), подобное или такое же, как то, на котором вы будете развертывать.

Если вы разрабатываете настольные приложения или что-то в этой области, затем разработайте на любой машине, которую вы хотите, а затем настройте ее для работы на желаемом оборудовании с минимальной спецификацией. Точно так же, если вы разрабатываете собственное программное обеспечение, скорее всего, будет минимальная спецификация для машин, которые компания хочет купить. В этом случае разрабатывайте на быстрой машине (чтобы сократить время разработки и, следовательно, затраты) и тестируйте в соответствии с этой минимальной спецификацией.

В итоге, разрабатывайте на самой быстрой машине, которую вы можете получить в руки, и тестируйте на минимуме или точное оборудование, которое вы

Это должна быть вики сообщества, так как это довольно субъективно и нет «правильного» ответ.

Тем не менее, вы должны развиваться на самой быстрой машине, доступной вам. Да, все, что медленнее, вызовет раздражение и побудит вас исправить замедление, но только по очень высокой цене:

Ваша продуктивность как программиста напрямую зависит от количества вещей, которые вы можете держать в голове, и всего, что замедляет вашу работу. процесс или вообще препятствует вам, увеличивает количество времени, которое у вас есть для удержания этих идей в краткосрочной памяти, что увеличивает вероятность того, что вы забудете их и вам придется их заново изучать.

Ожидание компиляции программы позволяет множество ошибок, потенциальных проблем и исправлений, которые вылетят из вашей головы, когда вы отвлечетесь. Ожидание загрузки диалога или завершения запроса прерывает вас аналогичным образом.

Даже если вы проигнорируете этот эффект, вы все равно поймете истину более позднего утверждения - ранняя оптимизация заставит вас гоняться за собой по кругу, ломая код, который уже работает, и угадывать (часто с плохой точностью), где что-то может застрять. Прежде всего, правильно спроектируйте свой код, и вы можете забыть об оптимизации, пока она не успокоится на некоторое время, после чего любая необходимая оптимизация станет очевидной.

из любви к Кодду, используйте инструменты профилирования, а не медленные машины разработки!

Следует избегать оптимизации, разве это не дало нам Vista? : p

Но если серьезно, это всегда вопрос компромиссов. Важные вопросы, которые стоит задать себе

Какую платформу будут использовать ваши конечные пользователи? Могу ли я отказаться от циклов? Что произойдет, если я это сделаю?

Я согласен с большинством в том, что начальная разработка должна выполняться на самой быстрой или наиболее эффективной (не обязательно на той же самой) машине, доступной вам. Но для запуска тестов запускайте его на своей целевой платформе и тестируйте часто и рано.

If you are programming on hardware that is close to the final test and production environments, you tend to find that there are less nasty surprises when it comes time to release the code.

I've seen enough programmers get side-swiped by serious, but unexpected problems caused by their machines being way faster than their most of their users. But also, I've seen the same problem occur with data. The code is tested on a small dataset and then "crumbles" on a large one.

Any differences in development and deployment environments can be the source of unexpected problems.

Still, since programming is expensive and time-consuming, if the end-user is running slow out-of-date equipment, the better solution is to deal with it at testing time (and schedule in a few early tests just to check usability and timing).

Why cripple your programmers just because you're worried about missing a potential problem? That's not a sane development strategy.

Paul.

Depends on your time to delivery. If you are in a 12 month delivery cycle then you should develop on a box with decent speed since your customers' 12 months from now will have better "average" boxes than the current "average".

As your development cycle approaches "today", your development machines should approach the current "average" speed of your clients' boxes.

I typically develop on the fastest machine I can get my hands on.

Most of the time I'm running a debug build, which is slow enough already.