Что нужно работодателю и за что отвечает п

[ssoft]

Так как достаточно много комментариев в теме http://www.prog.org.ru/topic_24027_15.html о том что необходимо работодателю от программиста и наоборот, я предлагаю обсудить это здесь.

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

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

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

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

Эти ответы как бы снимают с него всякую ответственность за качество.

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

[Bepec]

Моё скромное ИМХО:

1) Работодателю нужен результат. И точка. Его не волнует такая проблема как совместимость, стоимость поддержки и прочая, ибо до него на этом этапе эти слова пустой звон.
2) Программисту нужно чёткое задание от и до. Программисту нужна связь с работодателем и/или его менеджером. Программисту в результате нужна галочка о выполненной работе и бонус в виде денег
3) Этот пункт должен описываться в договоре. Либо на словах в каждом конкретном случае Универсальных запросов не существует.

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

4) Чистый более-менее код + комментарии в непонятных местах. Придерживаться одного стиля программирования. В общем стандартные требования + опять таки оговоренные в договоре

PS а хороший программист сделает так, чтобы добавление нового функционала в ужас не превращались

[Igors]

Интересная тема, но почему в "Говорилке"? Ладно

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

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

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

А чего Вы "ждете"? Чтобы некто дал Вам какие-то формулы, а Вы их реализовали (и ни за что не отвечали).

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

Так такой пассивный реализатор работодателю неинтересен  

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

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

Беда только в том что готового-то НЕТУ и/или найти его непросто. Освежив в памяти законы Ньютона Вы вероятно обнаружите что здесь они никак не помогут. Открыв физику жидкостей Вы вероятно тоже уйдете ни с чем. Через 4-5 дней гугления Вы начинаете понимать что топчетесь на месте. А время идет..  

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

[ssoft]

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

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

Я так понимаю в данном случае нужно придумать что-то похожее на движение капель, желательно простое. Да, нужно копать. Эта уже научная работа, а не программирование.

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

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

[Igors]

Я так понимаю в данном случае нужно придумать что-то похожее на движение капель, желательно простое. Да, нужно копать. Эта уже научная работа, а не программирование.

Вы всегда берете "слишком широко"  Нет, движения не требуется, нужно только деформировать капли так чтобы они свисали под действием силы тяжести (ну как красивые сиськи). Наибольшая трудность - учесть что капли могут сливаться друг с другом. Ну и у пользователя есть параметр gravity (мять сиськи больше/меньше). Конечно никакой научной работой здесь не пахнет, рядовой 3D эффект.

[Bepec]

"А давай вот так - хм, сиськи интересные".

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

[ecspertiza]

я то полагал тут про потребности заказчиков и разрабов. А тут про сиськи Когнитивный десонанс наступает.

[Bepec]

Это ж говорилка.

Вон к тому ж вроде в гимпе имелся где то аддон для создания капель. И вполне реалистичный. Коды посмотреть можно

[Igors]

я то полагал тут про потребности заказчиков и разрабов. А тут про сиськи Когнитивный десонанс наступает.

Нет ничего плохого в использовании выразительной аналогии. А если уж умничаете, то пишите правильно "диссонанс" 

Вон к тому ж вроде в гимпе имелся где то аддон для создания капель. И вполне реалистичный. Коды посмотреть можно

У игровых программ другие цели/задачи, и вряд ли там уместно создавать hi-resolution капли. Там и на character полигонов кот наплакал, абы шустрее бегало. А здесь качество/разрешение нужны довольно высокие (на аттаченной картинке они явно недостаточны). Чего-то там "подмазать текстурой" не выйдет, это не ширпотреб.

По другому вопросу

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

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

[Old]

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

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

[Old]

По-Вашему выходит что я претендую на лавры сэра Исаака Ньютона

Конечно нет.

Беда только в том что готового-то НЕТУ и/или найти его непросто. Освежив в памяти законы Ньютона Вы вероятно обнаружите что здесь они никак не помогут. Открыв физику жидкостей Вы вероятно тоже уйдете ни с чем. Через 4-5 дней гугления Вы начинаете понимать что топчетесь на месте. А время идет.. 

На капли не действует сила земного притяжения? Или физика жидкостей это фейк? Или вы просто не умеете готовить эти знания?

Так происходит с большинством моих задач.

У большинства на этом форуме такие же проблемы.

Проблема-то может и простая (с теми же каплями - да наверняка)

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

Выбрать (а иногда и придумать) алгоритм у меня часто занимает не меньше, а иногда и больше времени чем "реализовать".

Ну это наши тяжелые будни.

[Igors]

На капли не действует сила земного притяжения? Или физика жидкостей это фейк? Или вы просто не умеете готовить эти знания?

Задача построить 3D модель капель деформированных под действием силы тяжести. Я (наивно) полагал что это вполне ясно из картинки

[Old]

Задача построить 3D модель капель деформированных под действием силы тяжести. Я (наивно) полагал что это вполне ясно из картинки

Нууу, а какой закон описывает силу тяжести?

[Old]

Смотрю интерес к теме капель пропал?

Что бы я смотрел:
1. Те самые законы Ньютона, которые никак здесь не помогут:
Гравитационные силы. Закон всемирного тяготения
Сила тяжести. Вес тела. Невесомость
Силы трения. Коэффициент трения

2. Физика жидкостей
Жидкость
Поверхностное натяжение
Вязкость

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

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

[Igors]

Смотрю интерес к теме капель пропал?

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

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

Ладно, рассмотрим как сделать "просто капли" которые могут сливаться (пока без всякой гравитации). Здесь используется фундаментальный алгоритм "marching cubes". Форма задается ф-цией Surface(х, y, z). Если ф-ция возвращает положительное значение - мы внутри поверхности, иначе снаружи. Отлавливая нули ф-ции мы строим полигоны/модель. Об этом был диссер еще в середине 80-х. Ф-ция может задаваться всяко-разно, для простоты полагаем что множеством точек в пр-ве + радиусами для каждой капли. Псевдокод

Код

C++ (Qt)
float Surface( const Point & pt ) 
{
 float sum = 0.0f;
 for (size_t i = 0; i < points.size(); ++i) {        // цикл по всем каплям
  float distance = (pt - points[i].mCenter).length();  // расстояние от точки до центра капли
  float factor = 1.0f - distance / points[i].mRadius;    // относительный радиус
  if (factor < 0.0f) continue;   // точка снаружи капли 
  sum += factor;                 // накапливаем              
 }
 return sum - viscosity;  
} 
 

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