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

130

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

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

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

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

Обновить:

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

оборота
источник
20
Возможно, пусть они протестируют приложение на виртуальном ПК!
Марк С
209
Я потерял дар речи, что это даже вопрос. Как это может привести к чему-либо кроме медленного развития и плохого морального состояния?
Fosco
76
Разработать на современном уровне. Тест на худшей машине, которую вы можете найти.
Адам
14
Очищает ли пол с помощью зубной щетки, а не швабры? Конечно, в конце концов. Оператор швабры не может заметить грязь на расстоянии 150 см, а оператор зубной щетки - на расстоянии 30 см. Не пытайтесь с большим полом.
2010 г.
13
Примечание для себя: никогда не работай на MakerofThings7
Б

Ответы:

234

Абсолютно

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

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

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

Джей Биверс
источник
85
Мне понравился сарказм. +1
Теренс Понсе
8
Вице-президенты и выше часто общаются в чистом виде: смысл встречи в том, чтобы играть в гольф пьяным. Когда вы достигаете действительно высокого уровня, вы можете опьянеть и играть в гольф, когда выбираете страны, в которые вы хотите вторгнуться, и с кем заключать контракты на полную защиту.
Дэн Розенстарк
1
Я не вижу сарказма здесь. +1
FinnNk 30.10.10
376

Ответ (я буду смелым и скажу) всегда

NO .

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

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

peterchen
источник
10
Не могу проголосовать больше, чем один раз, хотя я бы хотел. У меня есть устаревший компьютер, на котором я работаю, и время, необходимое VS2010 для выполнения некоторых задач (например, открытия проекта), может быть довольно раздражающим.
rjzii 21.10.10
108
Можете ли вы сделать не очень большой и жирный?
р Ганнибал Лектер
4
Приемочные испытания, которые вы проводите, должны охватывать требования к производительности. Должны быть требования к производительности. Если вы не тестируете производительность, то ваш тестер называется клиентом (и вы берете с него деньги).
Тим Уиллискрофт
2
Я полностью согласен. Предоставление разработчику более медленных машин на самом деле не приведет к созданию лучшего кода. Разработчик будет разочарован машиной, и у него всегда будет некоторое беспокойство. Это делает код хуже, и они не могут сосредоточиться, когда все застрянет. Видите, у одного будет IDE, такой как Eclipse, скажем, 2 книги в формате PDF, 2 веб-браузера, один для запуска-отладки (в случае веб-разработки), запущенный сервер и музыкальный проигрыватель;) Дайте ему медленную машину и он поцелует тебя на прощание.
1
Нет ответа неверно. Правильный ответ Нееееееееееееет!
Пекка 웃
70

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

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

оборота БлэрХиппо
источник
Мне нравится идея использовать KVM со старым ПК для тестирования. Однако, в зависимости от проекта, разработчикам может быть неудобно устанавливать последние сборки на медленную машину каждый раз, когда они выпускают новую сборку.
Аль Кроули
4
Еще одна вещь, которую стоит рассмотреть, - дать им учетную запись как минимум на втором компьютере, который не имеет прав администратора.
Дэвид Торнли
43

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

Вонко вменяемый
источник
1
хе-хе, чем дольше, тем лучше!
Newtopian
33

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

о. Нейт
источник
кто ... подожди минутку. Если бы компиляция была быстрой, это больше было бы невозможно: xkcd.com/303
gbjbaanb
32

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

Евгений Брикман
источник
27

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

user6015
источник
26

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

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

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

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

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

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


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

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

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

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

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

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

Боб Мерфи
источник
+1 даже тридцать минут могут быть очень скромной оценкой в ​​некоторых кругах.
Джастин
20

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

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

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

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

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

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

EntropyFails
источник
«Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла». При проектировании чего-либо, стоит подумать 2 минуты о 3%.
Keyo
15

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

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

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

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

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

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

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

Я предполагаю, что многие разработчики имеют нездоровый уровень адреналина. Да, я нашел способ вернуть некоторое разочарование всем ожидающим:
офисный сервер sql (запуск консоли управления) arcgis (запуск и использование) acrobat reader (запуск) agresso (используя, по крайней мере, в качестве веб-приложения) Windows (смотрит и использует, ну я еще не пробовал 7). NET веб-страниц (загрузка)

и так далее

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

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

оборота Никлас Авен
источник
Этот. Этот. ЭТО. ТАК МНОГО ЭТОГО. Это всегда было моим самым большим разочарованием в программном обеспечении. Люди тратят больше времени, пытаясь усовершенствовать интерфейс, чем на самом деле наплевать на удобство использования. Одним из примеров этого является Android против Blackberry. Android выглядит лучше и может делать больше, но Blackberry гораздо приятнее (и быстрее) в использовании, чем Android, по крайней мере, на мой взгляд.
Kcoppock
1
Я полностью согласен с аргументом о том, что сейчас программное обеспечение работает так же быстро, как и 20 лет назад, примерно с теми же функциями. Но заставить разработчиков работать на 20-летнем оборудовании не поможет решить проблему. Если компания, создающая программное обеспечение, не инвестирует в юзабилити и / или тестирование производительности, разработка на более медленном оборудовании только ухудшит ситуацию. Это совершенно иная дискуссия, для которой голова программиста - не единственный достойный получатель заслуженного шлепка за голову.
Newtopian
10

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

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

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

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

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

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

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

luis.espinal
источник
1
Мы создавали программное обеспечение в течение последних 6 десятилетий, и у нас до сих пор возникают такие вопросы? - Я одобрил ваш ответ, но я призываю вас рассмотреть исходный вопрос с другой точки зрения. На самом деле, многие менеджеры не знают о преимуществах быстрых и мощных машин для своих разработчиков. Таким образом, с учетом этого, первоначальный вопрос, возможно, пытался разубедить таких менеджеров в нелепой идее, что медленные машины могут каким-то образом подтолкнуть разработчиков к созданию более быстрого и более эффективного кода.
Джим Г.
1
«2) Что я могу сделать, чтобы дать своим разработчикам быстрый опыт IDE, при этом предоставляя« типичный »опыт выполнения? Вы должны спросить об этом своих разработчиков». Я считаю, что это сайт программистов, а не сайт менеджеров. Он спрашивал разработчиков.
stimpy77
1
«Вы хотите построить автомобиль 4x4, который может работать в суровых условиях, под дождем, в грязи и во что бы то ни стало. Собираетесь ли вы разместить инженеров и сборочную линию под элементами, просто чтобы убедиться, что получившийся автомобиль сможет на них работать?» <<< люблю аналогию
stimpy77
6

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

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

bigtang
источник
8
Разработчики что сука? Ни за что ...
Jé Queue
6

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

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

альтернативный текст

Jé Queue
источник
3
Слепой программист? Это вообще возможно?
WernerCD
1
@WernerCD, я до сих пор пытаюсь представить себе силу ума, необходимую для отслеживания строк кода в моей голове.
Jé Queue
3
Да, большинство из нас пишут серверное программное обеспечение ... +1
goodguys_activate
@ MakerOfThings7, дай мне больше серверного оборудования в любое время по сравнению с моим локальным компьютером, потрать $, где это должно быть (но дай мне большой монитор :)) У меня нет проблем с моим десятилетним Dell Latitude CPx, который является дисплеем для больших систем в DC
Jé Queue
4
Может быть, слепой программист может использовать дисплей Брайля?
Antsan
5

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

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

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

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

Дэмиен
источник
5

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

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

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

Майк Гласспул
источник
5

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

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

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

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

Дэвид Курнапо
источник
+1 Но я должен не согласиться с некоторыми моментами. Я также купил нетбук, но заметил, что скорость - это не проблема, а маленький размер экрана. 1 ГГц достаточно быстр для небольших проектов на ходу, но 1024x600 слишком мало.
Джо Д
4

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

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

Билл
источник
4

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

JohnL
источник
+1: на самом деле это приведет к большему количеству ошибок, потому что они не будут выполнять столько испытаний, и они не будут использовать дополнительные инструменты, такие как профилировщики. - Отличный момент. Давайте не будем забывать альтернативные издержки, связанные с медленной разработкой машины.
Джим Г.
4

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

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

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

Лоренцо Стелла
источник
5
Скажи, что - купи действительно хороший компьютер, и я
поменяюсь с тобой
4

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

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

Имейте в виду, что это не выдуманные цифры.

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

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

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

полосы
источник
Вообще говоря, что в вашей сборке, чтобы это заняло так много времени? Это связано с процессором или диском (что является узким местом). Будет ли это проблемой, если что-то вроде TFS сделало сборки для вас?
goodguys_activate
1
Вам понадобится половина рабочего дня, чтобы выпить чашку кофе? Вы должны работать на правительство.
Finnw
I / O привязан к медленной машине. Тем не менее время от времени ввод-вывод ограничен на быстрой машине, но это скорее узкое место в процессоре. Нынешняя система сборки не любит работать более чем с одной библиотекой одновременно, поэтому некоторые ЦП и ввод-вывод остаются на полу, когда осталось менее 8 файлов для компиляции в любом данном подпроекте. Что касается кофе, я мог бы пить его быстрее, но я стараюсь ограничить его потребление, поэтому, если я выпью его быстрее, мне понадобится еще одно простое занятие.
Полосы
3

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

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

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

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

user6041
источник
3

Я собираюсь остановить тенденцию и здесь.

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

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

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

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

Джон Смайт
источник
7
Ключевым моментом здесь является «тест», живая система не должна загружать толстую раздутую IDE, запускать серверную часть локально, а не на выделенном оборудовании, запускать почту, офис и т. Д. Вам нужен высокопроизводительный компьютер, чтобы просто запустить dev среда в большинстве языков сегодня.
Билл Липер
3

Аппаратное обеспечение дешевле, чем время разработки.

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

Брайан
источник
3

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

addictedtoswdev
источник
2

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

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

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

Пол Натан
источник
2

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

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

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

user1249
источник
Не забывайте о преимуществах быстрого жесткого диска: codinghorror.com/blog/2009/10/…
Джим Дж.
2

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

Тьерри Лам
источник
2

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

user6043
источник
2

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

Mentifex
источник
2

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

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

Мэтью Рид
источник