Философский вопрос

Философский вопрос: Нужно ли разработчику иметь мощный в аппаратном плане сервер, чтобы разрабатывать быстрые программы?
Девелопая на мощном сервере разработчик может и не понять, что его программа не оптимальна, что можно немного подумать и оптимизировать её. А вот если разработчика изначально загнать в "узкие аппаратные" рамки, то разработчик зачастую сразу будет сталкиваться с низкой производительностью программы и сразу будет задумываться о том как написать её более быстродействующей. Получится некая оптимизация на ходу ещё не написанной до конца программы.

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

У разработчика должна достаточно быстрая рабочая станция, чтобы не тормозила разработку. А ещё у него должны быть чёткие требования к производительности до начала проектирования.

А ещё у компании должен быть тестировщик с отдельным сервером, позволяющим эти требования проверить.

Это уже давно не философский вопрос, а организационный.

Одно дело, когда медленный сервер тормозит разработку, а другое дело, когда быстрый сервер создает иллюзию быстрой работы сервиса, хотя на самом деле сервис не оптимален.
Просто я зачастую слышу от разработчиков, что проще выделить аппаратные ресурсы, чем оптимизировать программу. Иногда это перерастает в проблему, когда программ становится несколько сотен. И все это из-за незнания разработчика, что он написал медленный сервис и нежелания его оптимизировать.
Загоняя разработчика в узкие аппаратные рамки, мы имеем недовольного и ворчащего разработчика со словами: "Почему я должен девелопать на етом г**не?", а на выходе мы на самом деле можем получить более быстрый и оптимизированный сервис.

Например у нас в работе есть и быстрые серверы для разработки и тестировщики с отдельным быстрым железом для нагрузочных тестов, но сервисы зачастую на выходе бывают далеко не "быстродействующими". Разработчик, передавая сервис на нагрузочные тесты, понятия не имеет быстрый он сервис написал или медленный. И нам (нагрузочному тестированию), приходится открывать глаза разработчику. А вот если бы в процессе разработки на слабом железе девелопер сам видел, что его сервис медленный, думаю - это бы его заставило задуматься и оптимизировать на ходу.

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

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

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

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

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

Полностью согласен с greesha. Пока ещё дебажить нужно, запускать юнит-тесты, чтобы они побыстрее проходили.

В общем, опять тестировщики не могут найти общий язык с разработчиками. :)

А виноват, как обычно, тот, кто организует процесс.

Самый быстрый сервер под разработку? - Ни в коем случае!

Самый медленный? - Вы своих людей уважаете хоть чуть?

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

Требования как правило есть, мы никогда не тестируем без требований. Только наличие требований не делает сами программы быстрее. Зачастую скорость работы программы подгоняется под требования путем увеличения выделяемых аппаратных ресурсов. Медленно работает сервис? Значит нужно купить ещё один мощный сервер, чтобы программа работала быстро... Иногда это оправдывается тем, что дешевле купить сервер, чем оплачивать много-много часов рабочего времени разработчика, который оптимизирует свое, ранее написанное медленное поделие. Так почему бы не писать быстро сразу?
В идеале разработчики должны писать быстрые программы, которые потребляют минимально возможное количество аппаратных ресурсов.
Меня все таки не покидает мысль о том, что быстрые и мощные сервера мешают разработчикам писать быстрые программы.
Для того чтобы начать думать над быстродействием своей программы разработчик сначала должен понять, что его программа работает медленно. Запуская программу на быстром сервере он никогда этого не поймет. Даем меньше проца - программа тормозит - разработчик понимает медленность своего кода - начинает думать как его ускорить. Очевидно, что это сработает. Разубедите меня... :)

Я не знаю где вы увидели недопонимание между тестировщиками и программистами :)

Самый быстрый сервер под разработку? - Ни в коем случае!

Самый медленный? - Вы своих людей уважаете хоть чуть?

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

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

А может не стоит ограничиваться полумерами, выдавая им медленное старое оборудование, а?
Надо ещё отобрать все современные фреймворки, а также всякие там виртуальные джава- и дотнет-машины.
И пусть пишут на ассемблере! В крайнем случае на C.
Трудно, долго, дорого? Ничего, зато программы будут быстрые :)

А может не стоит ограничиваться полумерами, выдавая им медленное старое оборудование, а?
Надо ещё отобрать все современные фреймворки, а также всякие там виртуальные джава- и дотнет-машины.
И пусть пишут на ассемблере! В крайнем случае на C.
Трудно, долго, дорого? Ничего, зато программы будут быстрые :)

Вы конечно утрируете, но, как мне кажется, тема не лишена смысла :)

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

У нас поступают следующим образом:
Разработчикам ставят сильные машины (ну еще бы, у них столько всего открыто одновременно).
Тестерам на класс пониже.
А уж что стоит у заказчика.. бывает и очень слабое железо.
У нас приложение клиент-сервер.
Со стороны клиента тестеры выявляют слабые места.
Со стороны БД- есть специальные программы, которые оценивают "тяжесть" запросов.
Эти запросы детектятся и передаются обратно в разработку на оптимизацию.
Оставшееся пишет заказчик.

Рабочая машина дева однозначно должна быть как можно более мощной, другое дело, что запускать скомпилированные программы можно и на более слабой машине. Или есть такое прикольное решение, Add-on VS для VMWare - то есть ты из VS можешь запустить свою программу на вмварьке, а уж как обрезать память или место самой ВМварьки решать разработчику.. правда сразу скажу, сам такое не практиковал.. видел "одним глазком"

У нас поступают следующим образом:
Разработчикам ставят сильные машины (ну еще бы, у них столько всего открыто одновременно).
Тестерам на класс пониже.
А уж что стоит у заказчика.. бывает и очень слабое железо.
У нас приложение клиент-сервер.
Со стороны клиента тестеры выявляют слабые места.
Со стороны БД- есть специальные программы, которые оценивают "тяжесть" запросов.
Эти запросы детектятся и передаются обратно в разработку на оптимизацию.
Оставшееся пишет заказчик.

На ваш взгляд, если бы у ваших разработчиков под БД стояли не такие сильные машины, как сейчас стоят, могло бы это повлиять на уменьшение количества "тяжелых" запросов к БД, которые вы в последствии отлавливаете при тестировании на стороне заказчика?

Рабочая машина дева однозначно должна быть как можно более мощной, другое дело, что запускать скомпилированные программы можно и на более слабой машине. Или есть такое прикольное решение, Add-on VS для VMWare - то есть ты из VS можешь запустить свою программу на вмварьке, а уж как обрезать память или место самой ВМварьки решать разработчику.. правда сразу скажу, сам такое не практиковал.. видел "одним глазком"

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

Медленно работает сервис? Значит нужно купить ещё один мощный сервер, чтобы программа работала быстро... Иногда это оправдывается тем, что дешевле купить сервер, чем оплачивать много-много часов рабочего времени разработчика, который оптимизирует свое, ранее написанное медленное поделие. Так почему бы не писать быстро сразу?

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

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

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

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

Так у вас ведь есть тестовый сервер, на котором вы обнаружили проблему! Посадите возле него разработчика, пусть попользуется и поймёт.
Низкая производительность - это только одна из проблем. Дав разработчику медленное оборудование, вы действительно забудете об этой проблеме, потому что её заслонит куча других.

Медленно работает сервис? Значит нужно купить ещё один мощный сервер, чтобы программа работала быстро... Иногда это оправдывается тем, что дешевле купить сервер, чем оплачивать много-много часов рабочего времени разработчика, который оптимизирует свое, ранее написанное медленное поделие. Так почему бы не писать быстро сразу?

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

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

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

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

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

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

Так у вас ведь есть тестовый сервер, на котором вы обнаружили проблему! Посадите возле него разработчика, пусть попользуется и поймёт.
Низкая производительность - это только одна из проблем. Дав разработчику медленное оборудование, вы действительно забудете об этой проблеме, потому что её заслонит куча других.

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

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

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

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

Замедление разработки.
Пропущенные разработчиком баги из-за удлинения итерации (не командной, а личной итерации разработчика).
"Оптимизация" тех частей, которые в реальности оптимизировать не надо.
Уход разработчика из-за невыносимых условий работы, наконец. :)


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

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

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

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