Предоставляет ли разработчик более медленную машину разработки более быстрый /эффективный код? [закрыто]

Предположим, что я даю своим разработчикам кричащую быструю машину. VS2010 на основе WPF загружается очень быстро. Затем разработчик создает приложение WPF или WPF /e, которое отлично работает на его поле, но намного медленнее в реальном мире.

Этот вопрос состоит из двух частей ...

1) Если я даю разработчику более медленную машину, означает ли это, что полученный код может быть быстрее или эффективнее?

2) Что я могу сделать, чтобы дать моим разработчикам быстрый опыт IDE, давая «типичный» опыт выполнения?

Update:

Для записи я готовлю свой безобидный ответ руководству. Это не моя идея, и вы, ребята, помогаете мне исправлять ошибочные просьбы моего клиента. Спасибо, что дал мне больше боеприпасов и ссылки на то, где и когда нужно подходить к этому. У меня есть + 1 допустимые варианты использования, например:
- конкретные оптимизации программирования на стороне сервера
- тестовые лаборатории
- возможно, покупка лучшего сервера вместо верхней части линейных видеокарт

130 голосов | спросил 4 revs
makerofthings7
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

30 ответов


234

Абсолютно

Также верно, что руководители должны проводить все встречи в Pig-Latin. Это улучшает их коммуникативные навыки в целом, чтобы они были в невыгодном положении, когда говорили простые предложения. Им придется больше полагаться на выражения лица и язык тела, чтобы понять их суть, и все мы знаем, что это как минимум 70% всей коммуникации.

Финансовые директора должны использовать только счеты и мел. В противном случае они в конечном итоге слишком полагаются на «сырые данные» и недостаточно на их «ощущение кишки».

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
377

Ответ (я получу смелость и говорю) always

NO .

Разработайте лучшее, что вы можете получить в своем бюджете, и проверите в области спектра оборудования min-max, на котором вы будете развертывать.

Есть эмуляторы, виртуальные машины, настоящие машины с тестерами, которые могут проверить производительность, чтобы убедиться, что это фактор.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
70

1) Очень, очень маловероятно. Нет, , и ваши разработчики могут добавить что-то неприятное в ваш кофе, чтобы предложить его. Время, которое ваши разработчики тратят на ожидание компиляции кода или для того, чтобы IDE выполняла то, что он делает, или что-то еще, когда они тратят not , делая код лучше. Нарушает их ментальный поток. Не упускайте из виду проблему, и они будут гораздо эффективнее решать эту проблему.

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
43

Мне нравится длительное время компиляции. Это дает мне больше времени для работы над моим резюме.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
33

Это ужасная идея. Вы хотите, чтобы ваши разработчики были настолько продуктивными, насколько это возможно, что означает предоставление им максимально быстрой машины, поэтому они не сидят целый день, ожидая компиляции вещей. (Немного OT, но также помогает не блокировать доступ к потенциально полезным сайтам с помощью WebSense и т. П.). Если вам ограничено наличие пользователей, которые все еще используют технологию Stone-Age, тогда вам понадобится тестовая машина с аналогичными характеристиками, и не забудьте проверить рано и часто, чтобы убедиться, что вы не идете по неправильной дороге с точки зрения выбора технологий.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
32

Развитие должно проводиться в наилучшей окружающей среде, которая возможна. Тестирование должно проводиться в наихудшей возможной среде.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
27

Если бы мне дали медленную машину, я бы потратил свой день на оптимизацию процесса разработки, а не на оптимизацию моего кода. Итак: НЕТ!

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
26

Программисты встроенных систем постоянно сталкиваются с этим! И есть решение из двух частей:

  1. В ваших требованиях необходимо указать производительность X на оборудовании Y.
  2. Тестирование на аппаратном обеспечении Y и когда вы не получаете производительность X, ошибки в файлах.

Тогда не имеет значения, на каком оборудовании работают ваши разработчики.

Как только вы это сделаете, скажем, более быстрое оборудование может спасти ваших программистов полчаса в день или 125 часов в год. И скажем, они стоят 100 000 долларов в год с выгодами и накладными расходами (смехотворно низкими для Силиконовой долины), или 50 долларов в час. Это 125 часов * $ 50 /час составляет $ 6250. Поэтому, если вы тратите меньше чем $ 6250 в год на разработку аппаратного обеспечения для каждого программиста, вы экономите деньги.

Вот что вы должны сказать своему руководству.

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


Добавлено 24 октября:

У моего бывшего работодателя была эта теория, и это помогло им опорочить около 100 миллионов долларов.

Это японский конгломерат, который использовался для найма программистов в Японии, Корее и Китае. Люди там круты с использованием дерьмового оборудования для разработки, 13-часовые рабочие дни, спят на своих столах и не имеют жизни. Поэтому они поняли, что когда они приобрели известную компанию Silicon Valley, чтобы сделать ОС на базе ОС на базе Linux, эти глупые калифорнийцы, которые хотели современную экипировку, были просто пьяными примадоннами и на самом деле не имели для этого веских оснований (например, производительности).

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

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

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
20

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

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

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

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

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

Я вижу ваш вопрос, говоря: «Могу ли я заставить своих разработчиков оптимизировать ранние, предоставив им плохие машины для разработчиков, но все же получить хороший код?» И ответ - нет.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
15

Интересное чтение, все эти ответы.

Но я думаю, что большинство людей, отвечающих здесь, не имеют смысла. Вопрос, как я читал, не является (по крайней мере) тем, что действительно дает разработчикам P1, чтобы сделать более быстрый код.

Дело в том, что сегодня много программного обеспечения так же медленно или даже медленнее, чем программное обеспечение, которое мы использовали в прошлом тысячелетии, несмотря на гораздо более мощные компьютеры. Судя по ответам, большинство разработчиков не понимают этого намека. Это очень очевидно в веб-приложениях. Этот сайт является очень хорошим исключением, но многие сайты имеют первую страницу в 1 мб. Что я могу ожидать для загрузки? Я не знаю. Я думаю, что это связано с тем, что разработчик не знает о том, что пользователь не должен тратить на это время, или даже хуже платить, если вы платите за мб. Дело в том, что на всех этих веб-страницах даже нет изображений с высоким разрешением. Часто это просто какой-то дерьмовый код, доставленный из некоторой среды разработки. Ну, конечно, это не дерьмовый код, я думаю, но он не дает мне никакой пользы.

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

Несколько недель назад я начал работать с ноутбуком с 1995 года. Windows 3.x быстро и быстро запускается. В базе данных я должен получить некоторые данные от запуска до того, как ключ ввода будет полностью выпущен (почти как минимум).

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

Я должен сказать, что, по-моему, разработка Linux лучше справляется с этим. Распределения Linux на протяжении многих лет были довольно далеко впереди окон даже в причудливости с множеством глазных конфет, таких как анимированные окна. Дело в том, что они, несмотря на это, работали на компьютерах сегодня и даже вчера. Не только на ультрасовременном оборудовании.

К настоящему моменту я думаю, что у многих разработчиков есть нездоровый уровень адреналина. Да, я нашел способ отбросить разочарование от всех ожидающих впереди:
офис sql-сервер (пусковая консоль управления) arcgis (запуск и использование) Acrobat Reader (запуск) agresso (используя, по крайней мере, веб-приложение) окна (смотря и использую, ну я еще не пробовал 7) .net (загрузка)

и т. д.

Я чувствую себя хорошо: -)

Приветствия
Никлас

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
10
  

1) Если я дам разработчику более медленный   Это означает, что   полученный код может быть быстрее или больше   эффективным?

Мы занимаемся разработкой программного обеспечения в течение последних 6 десятилетий, и у нас все еще есть такие вопросы. Похоже, еще одна попытка отрезать углы. Не обижайтесь, но давайте, вы думаете, этот вопрос даже логичен? Подумайте об этом в этих условиях (если можете): вы хотите построить автомобиль 4x4, который может работать в суровых условиях, дождь, грязь, что угодно. Собираетесь ли вы поместить своих инженеров и сборочную линию под элементы, чтобы убедиться, что результирующий автомобиль может работать на них?

Я имею в виду, Иисус Христос! Существует разработка и есть тестирование. Тестирование выполняется в другой, более жесткой среде, или разработчик знает, как собрать тестовую кровать в своей собственной среде, подходящей для стресс-тестирования. Если он не может, замените его лучшим разработчиком.

  

2) Что я могу сделать, чтобы дать моим разработчикам   быстрый опыт IDE, давая   «типичный» опыт выполнения?

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

Но для того, чтобы развлечь вопрос, дайте своим разработчикам (если у вас хорошие разработчики), хорошие инструменты и хорошее оборудование, лучшее, что вы можете себе позволить. Затем настройте самую низкую общую базовую среду, в которой должно работать ваше программное обеспечение. Это , где должно проводиться тестирование. Гораздо лучше инженерная практика состоит из тестовой среды , которая отличается от среды разработки (предпочтительно той, которая позволяет выполнять стресс-тестирование).

Если ваши разработчики хороши, они должны были сообщить об этом вам (при условии, что вы их спросили.)

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
6

В результате получается множество разработчиков bitchin. Этот материал достаточно прост, как есть, давайте не будем делать хуже.

Я бы запретил вам использовать аналогичное оборудование для ваших пользователей в тестовой или QA-среде, чтобы выкидывать любые проблемы с производительностью. Это хорошая идея.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
6

Я подниму норму и скажу «ДА» И ТОЛЬКО, если они пишут серверное программное обеспечение. Смех все, что вы хотите, но самая эффективная команда, которую я когда-либо видел, - это группа парней Perl с терминалами Wyse. Это было в конце 1990-х годов, это был университетский магазин для отпусков, и они писали программное обеспечение пространственного грида (которое в основном просто вычисляет). Однако они говорили с некоторыми относительно мощными поздними модельными RS /6000.

Просто чтобы добавить интерес к мероприятию, там был слепой программист. Я был очень впечатлен.

alt text

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
5

Это неплохая идея, но вы хотите, чтобы ваши разработчики имели быструю среду программирования.

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

Некоторая настройка процесса сборки VS может сделать развертывание в тестовом поле нормой с удаленной отладкой.

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
5

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

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

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
5

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

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

Во-вторых, все медленнее означает, что вещи, которые вы, возможно, захотите сделать на быстрой машине (скажем, 1 минута), на самом деле не справляются на медленной машине из-за ленивости и т. д. Это вопрос стимула .

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
4

Точка 1, НЕТ! Студия предназначена для работы на достойных машинах, и это требование становится более мощным с каждой версией. Вы можете заблокировать некоторые версии студий, если вы включите intellisense и используете один ядро ​​без HT.

В точку # 2 есть некоторые функции в проектах тестирования, которые позволяют дросселировать некоторые ресурсы. Они не идеальны, но они есть. VPC или низкоспециализированные изображения VM для довольно хорошей работы и для ограничения. У меня были пользователи, которые сидели на плохих машинах, чтобы периодически тестировать их, чтобы они могли видеть последствия тех функций, которые они запросили.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
4

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
4

Я думаю, что это интересный вопрос, и я бы не пошел на «нет», что бы быстро. Мое мнение таково: это зависит от того, о какой развивающейся команде мы говорим. Пример: если вы возглавляете группу, которая работает для ежегодного конкурса программирования ICFP, возможно, иметь хорошие результаты после небольшого количества времени разработки в кластере HPC, не обязательно означает, что найденное вами решение является хорошим. То же самое можно сказать, если вы пишете какой-то научный или численный алгоритм: на вашем старом AMD Duron 600 МГц с 64 Мб памяти вы вынуждены быть осторожны с тем, как вы делаете это, и это может повлиять даже на некоторые разработки выбор.

С другой стороны, умный программист /ученый /все равно должен быть осторожным. Но я обнаружил, что записываю некоторые из своих лучших кодов, когда у меня не было компьютера во ВСЕХ, и мне приходилось делать заметки на бумаге. Это может не относиться к крупным проектам с огромными фреймворками, когда необходима среда IDE.

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
4

Я работаю над пакетом, который занимает около часа, чтобы построить на моей 8-ядерной машине 8G (полная чистая сборка). У меня также есть относительно низкий ноутбук, на котором я тестирую. Низкий ноутбук не справляется с двумя полными сборками за один рабочий день.

Я более продуктивен на быстрой машине с некоторым преднамеренным тестированием на ноутбуке или должен ли я делать все свои сборки на ноутбуке?

Имейте в виду, что это не заполненные номера.

Это сфальсифицированная демоверсия, в которой мне обычно не нужно делать чистую сборку каждый день (я могу много тестировать на одном модуле), но даже частичные сборки показывают примерно разницу в величине компиляции /link.

Итак, реальная проблема на моей медленной машине, типичная сборка достаточно длинная, чтобы я мог получить чашку кофе, а на моей более быстрой машине я могу только потягивать немного кофе.

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
3

Интересно, что я работал в стартапе, где мы закончили это. Я думаю, что это действительно сработало очень хорошо, но только из-за конкретной ситуации, в которой мы находились. Это был магазин mod_perl, где автоперегрузка класса фактически работала правильно. Все разработчики использовали vim в качестве своей IDE для выбора (или использовали какое-то программное обеспечение для удаленного редактирования). Конечным результатом было то, что очень мало (если есть) время было потеряно, ожидая кода для компиляции /перезагрузки /и т. Д.

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

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

После перезаписи вашего первоначального вопроса мне приходит в голову, что одна вещь, которая постоянно меня пугает, - это среды разработки, которые отличаются от производственных сред. Почему бы не использовать виртуальную машину для выполнения кода, которую вы можете испортить для выполнения, не затрагивая рабочую станцию ​​dev? В последнее время я использую VirtualBox /loving.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
3

Я тоже собираюсь поднять эту тенденцию.

Анекдот: Я работал в голландской фирме по разработке программного обеспечения, которая обновила 286 компьютеров до 486-х (да, я такой старый). В течение нескольких недель производительность всех наших внутренних библиотек снизилась на 50%, а ошибки увеличились ... Небольшое исследование показало, что люди больше не продумали сам код во время процесса отладки, но прибегли к «быстрому» следующему коду -> ; compile -> test -> исправить (код) и т. д. циклов.

Связано: когда я основал филиал для той же компании в США, я в конечном итоге нанял российских программистов, потому что они были использованы для ПК с меньшим количеством функций /меньшей мощности и были гораздо более эффективными кодовыми.

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

Следовательно ... Я считаю, что программисты должны быть вынуждены тестировать свои приложения на машинах, которые не превышают вычислительную мощность и аппаратные характеристики «Average Joe».

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
3

Оборудование менее дорогостоящее, чем время разработки.

Большинство узких мест находятся в базе данных не на клиентском ПК, но это не оправдывает тестирование на медленнее, чем разработчик. Используйте инструменты тестирования для проверки оптимизации.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
3

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

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
2

Это интересная мысль (предоставление разработчикам медленной машины может привести к их оптимизации).

Тем не менее, решение обрамляется в лучшую сторону - задает время отклика в требованиях к программам и имеет доступную для тестирования машину младшего класса.

Кроме того, если у вас действительно есть компилятор /язык для whiz-bang, он может разработать различные способы генерации кода и выбрать лучший. Этому поможет только более быстрый компьютер.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
2

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

Вещи, которые вы, возможно, захотите рассмотреть, чтобы избавиться от антивируса на сборке дисков! Это только замедляется и может быть чрезвычайно сильным фактором замедления.

Возможно, вы захотите, чтобы разработки развивались на Linux, если это было возможно. Инструменты там намного лучше для всех видов дополнительных задач (просто grep для чего-то в файле и т. Д.). Это также избавляет от антивируса.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
2

Мой MacBook Pro на работе несколько лет. Между Linux и Windows (чтобы проверить IE quirks) vms, а также несколько веб-браузеров и терминалов открываются, OSX spinning wheel показывает много. Угадайте, что я делаю, когда он вращается, я сижу и жду. В этом случае медленная машина замедляет производительность.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
2

Для многих приложений проблема заключается в том, что разработчики тестируют с наборами данных реального мира, прежде чем они будут выполнены. Для интерактивных приложений потребуется базовый тестовый компьютер /VM.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
2

Я работаю на медленной машине Windows95, и это позволяет мне эффективно писать искусственный интеллект MindForth в Forth и на JavaScript.

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37
2

Запрашивая программистов, должны ли программисты получать хорошее оборудование, нравится спрашивать толстяка, нравится ли ему еда. Я знаю, что это субъективный обмен, но все же ... вопрос стоит нас спрашивать? : P

Я сказал, что я согласен с большинством: НЕТ .

ответил 15 +04002010-10-15T05:40:37+04:00312010bEurope/MoscowFri, 15 Oct 2010 05:40:37 +0400 2010, 05:40:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132