Сообщений в теме: 34

[SALar]

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

Считаем:
клавиатура+мышь - $200-300
мониторы - $2000
стол 160-200х80 см от - $200
тумбочка $100
кресло от $300
всяко разна мелочевка вроде подставки (или кронштейны) под мониторы, канцелярию и прочее - от $100

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

А еще под рабочее место нужно заплатить аренду (расчет делаю для Москвы)
8 кв м * $50 = $400 в месяц
плюс места общего пользования (переговорки, кухни, коридоры ...)

итого порядка $1000 в месяц


Нужно ли уменьшать производительность программиста, покупая системник не за $1000 , за 600?

Справедливости ради нужно отдельно рассмотреть обеспечение серверами, но это уже другой вопрос.

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

Этап обследования. Берем ГОСТ 34.602, и заполняем раздел "характеристики окружающей среды". Характеристики компьтерного парка заказчика, разрешения мониторов (любопытно смотрится софт, разработанный под 1200х1024 на очень популярном ныне мониторе 1600х900), каналы связи, возможные протоколы прикладного уровня, один или много часовых поясов,... Это делается ДО кодирования.

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

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

[ligreen]

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

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

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

[Clauster]

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

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

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

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

[ligreen]

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

Согласен, но почему-то этого не происходит, не думают... :(

[LeshaL]

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

Согласен, но почему-то этого не происходит, не думают... :(

И вы считаете, что дав медленную машину для отладки недумающий разработчик начнет думать? Бросьте. Будет реже отлаживаться и время выполнения задач возрастёт.
Да и вам уже по-моему всё объяснили тут не один раз (про требования, про ненужность итд). А вы все одно и тоже твердите.

[Фрося]

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

Согласен, но почему-то этого не происходит, не думают... :(

(в другой интерпретации все нижеизложенное уже озвучивалось. Я уж примеры просто привожу)
А есть ли какие-то требования у разработчиков ПО насчет - как именно быстро должно работать/реагировать?
Если - нет, то чего об этом думать-то?
У меня вон - программа Архива КД открывает документ Word не сильно большой столько времени, что кофия успеешь напиться.
Разработчик на смерть стоит -- ну и пейте! Не критично! С конструкторской документацией нормально работает, ну а Word-овские документы - можно и подождать!

В принципе - разработчик прав. Ему никто требований таких не ставил. Ну чего уж - как получилось.

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

[SALar]

Согласен, но почему-то этого не происходит, не думают... :(

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

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

[Clauster]

А вы все одно и тоже твердите.

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

[LeshaL]

А вы все одно и тоже твердите.

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

Одна из техник assertive communications. Честно-честно.

[ligreen]

В итоге, как я понял, из 3-х вариантов:
1) да, для разработки быстрых программ нужен быстрый сервер
2) нет, для разработки быстрых программ не нужен быстрый сервер
3) "мощность" сервера девелоперов не влияет на скорость работы разрабатываемой программы

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

[ligreen]

Согласен, но почему-то этого не происходит, не думают... :(

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

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

Вот я бы ситуацию с Титаником немного по другому интерпритировал. Медленный сервер для разработки может быть не детскими совочками для кочегаров, а достаточно большой по размерам айсбергом, при столкновении с которым корабль не получил бы пробоину, но удар был бы слышен лицам ЛДПР и они бы задумались, а не стоит ли нам сбавить обороты или же вернуться в порт...

[nhuber]

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

[ligreen]

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

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

[VLana]

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

[nhuber]

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

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