Здравствуйте, blumenkraft, Вы писали:

Я бы этому человеку не доверил и Hello World писать.
И есть подозрение, что он не понимает, что такое TDD.

Здравствуйте, blumenkraft, Вы писали:

B>...он сказал что зарплата не соответствует таким извращениям, и что "за такие деньги TDD на проекте не будет."

Человек совершенно определенно не вкуривает ситуацию. TDD на проекте применяется в первую очередь для удобства самого программиста, во вторую — для уменьшения объема работ коллегам-тестерам и только в третью (если не в десятую) — для удовлетворения начальства/заказчика. Кончится все это его тем, что через какое-то время вместо того, чтобы кодить — он будет копаться в давно забытом коде в поисках сто лет назад посаженых там глюков. Причем скорее всего — за еще меньшие, нежели сейчас, деньги.

B>Недавно общался с коллегой, который упомянул что некоторые практики из своей работы исключает в принципе. Когда спросил "почему" он сказал что зарплата не соответствует таким извращениям, и что "за такие деньги TDD на проекте не будет." В связи с этим хотел спросить — еще кто-нть применяет подобный подход к работе? Хотелось бы услышать побольше про мотивацию подобного.

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

Одна нажежда — кризис выметет в-основном таких.

Здравствуйте, landerhigh, Вы писали:

L>Это не TDD, это какое-то черти что и сбоку бантик.
L>В моей практике TDD всегда лишь уменьшало время разработки.
TDD совсем не требует усилий? Или само собой происходит? Я думаю, что временные затраты есть в любом случае.
А время тестировщикам экономит модульное тестирование, которое часть TDD и может использоваться отдельно. Кстати, зачем экономить время тестировщикам, им же за работу деньги платят.

Здравствуйте, techgl, Вы писали:

T>Здравствуйте, landerhigh, Вы писали:

L>>Это не TDD, это какое-то черти что и сбоку бантик.
L>>В моей практике TDD всегда лишь уменьшало время разработки.
T>TDD совсем не требует усилий? Или само собой происходит? Я думаю, что временные затраты есть в любом случае.
TDD — это как рычаг. Приложив небольшие усилия, экономишь в Х раз больше.
Если TDD увеличивает время разработки, то кто-то что-то делает не так.

Здравствуйте, landerhigh, Вы писали:

T>>TDD требует затрат, не все тесты тривиальны и пишутся с закрытими глазами в пять минут.
T>>Если заказчик не хочет платить за это, то TDD ты будешь применять себе в убыток. Например, обговорили тебе срок и стоимость, ты знаешь, что без разработки тестов, ты уложишься в срок и деньги тебя устраивают. Говоришь при этом, что хочешь использовать подход TDD, но это увеличит время разработки.
L>Это не TDD, это какое-то черти что и сбоку бантик.
L>В моей практике TDD всегда лишь уменьшало время разработки.

это при одинаковом конечном уровне качества, в примере выше ситуация другая

B>Недавно общался с коллегой, который упомянул что некоторые практики из своей работы исключает в принципе. Когда спросил "почему" он сказал что зарплата не соответствует таким извращениям, и что "за такие деньги TDD на проекте не будет." В связи с этим хотел спросить — еще кто-нть применяет подобный подход к работе? Хотелось бы услышать побольше про мотивацию подобного.

1. Если деньги меня не устраивают, то я просто не буду работать в этой компании.
2. Если я всё-таки решаю работать, то работаю хорошо
3. Хотя, заметил за собой, что после хорошего подъёма зарплаты моя продуктивность возрастает примерно на 2-3 недели.

Здравствуйте, Odi$$ey, Вы писали:

L>>Это не TDD, это какое-то черти что и сбоку бантик.
L>>В моей практике TDD всегда лишь уменьшало время разработки.
OE>это при одинаковом конечном уровне качества, в примере выше ситуация другая
У меня, например, качество разработки бывает только одно. Плохо работать не умею. Более того, я лично не хочу иметь в своем послужном списке проекты, за которые мне было бы стыдно.

Здравствуйте, landerhigh, Вы писали:

L>>>Это не TDD, это какое-то черти что и сбоку бантик.
L>>>В моей практике TDD всегда лишь уменьшало время разработки.
OE>>это при одинаковом конечном уровне качества, в примере выше ситуация другая
L>У меня, например, качество разработки бывает только одно. Плохо работать не умею. Более того, я лично не хочу иметь в своем послужном списке проекты, за которые мне было бы стыдно.

значит твой ответ на subj — нет, а у techgl — да, во втором случае TDD удлиняет сроки разработки

Здравствуйте, landerhigh, Вы писали:

L>TDD — это как рычаг. Приложив небольшие усилия, экономишь в Х раз больше.
Кто-то ведь будет писать тесты? Кто-то будет продумывать архитектуру так, чтобы сначала писать тест для модуля, а потом сам модуль и чтобы это работало.

S>мы делаем гуано-автомобили, а немцы для которых такая логика является дикостью — делают отличные машины, живут хорошо и много зарабатывают.

Вообще-то, русские еще лучше живут и намного больше зарабатывают. Просто... это 1% русских. За счет остальных 99%.
У нас очень большое социальное расслоение. А работаем мы не хуже немцев.

S>ЗЫ: А еще не рассказывайте нам о послевоенной разрухе в Германии, они номинально свое производство не теряли и квалифицированных кадров тоже (скажем так почти). И военные действия на их территории по времени велись очень мало.

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

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

С этим согласен.

SD>Вообще-то, русские еще лучше живут и намного больше зарабатывают. Просто... это 1% русских. За счет остальных 99%.
SD>У нас очень большое социальное расслоение. А работаем мы не хуже немцев.

Хуже, уж извините за печальную истину.

Здравствуйте, blumenkraft, Вы писали:

B>Недавно общался с коллегой, который упомянул что некоторые практики из своей работы исключает в принципе. Когда спросил "почему" он сказал что зарплата не соответствует таким извращениям, и что "за такие деньги TDD на проекте не будет." В связи с этим хотел спросить — еще кто-нть применяет подобный подход к работе? Хотелось бы услышать побольше про мотивацию подобного.

Может я что-то не понимаю, но это позиция быдла-неудачника.

Здравствуйте, techgl, Вы писали:

VD>>Категорически не согласен с такой позицией. Ему платят за работу 40 часов неделю. Эти 40 часов в неделю настоящий профи будет работать максимально качественно. Сроки на задачу оговариваются отдельно, две недели — код, три недели — с юнит-тестами, месяц полное покрытие, и тд.
T>Что, если только первый вариант? Сказать заказчику "до свидания" и остаться без денег? Он то найдет себе исполнителя, без "закидонов" в виде TDD.
T>Это не значит, что TDD плохой, просто некоторые заказчики считают это "заумью", "закидонами". "Ты мне сделай, чтобы работало".

Имеет полное право. Либо ты убеждаешь заказчика в том, что в этом случае продукт будет выполнен более качественно, а он либо соглашается платить за качество, либо не соглашается, либо делаешь так, как это устраивает заказчика. Если тебя не устраивает делать работу за два дня, там где нужна неделя на качественное выполнение, ты всегда можешь отказаться от сотрудничества с этим заказчиком. Что не так?

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

Здравствуйте, Odi$$ey, Вы писали:

OE>значит твой ответ на subj — нет, а у techgl — да, во втором случае TDD удлиняет сроки разработки

Пусть удлиняет. Чем дольше делаю — тем больше заплатят. Речь идет о работе по трудовому договору с оплатой за часы, а не за результат.
Поэтому я сильно сомневаюсь что человек, о котором идет речь в исходном посте, хоть как-то беспокоится по поводу сроков. Его позиция — именно поменьше напрягаться.

Здравствуйте, blumenkraft, Вы писали:

B>Недавно общался с коллегой, который упомянул что некоторые практики из своей работы исключает в принципе. Когда спросил "почему" он сказал что зарплата не соответствует таким извращениям, и что "за такие деньги TDD на проекте не будет." В связи с этим хотел спросить — еще кто-нть применяет подобный подход к работе? Хотелось бы услышать побольше про мотивацию подобного.

Просто лентяй. Или выбрал неправильную профессию.
А зарплатой только оправдывается.

Здравствуйте, FDSC, Вы писали:

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

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

Недавно общался с коллегой, который упомянул что некоторые практики из своей работы исключает в принципе. Когда спросил "почему" он сказал что зарплата не соответствует таким извращениям, и что "за такие деньги TDD на проекте не будет." В связи с этим хотел спросить — еще кто-нть применяет подобный подход к работе? Хотелось бы услышать побольше про мотивацию подобного.

Видимо, ему трудно использовать TDD. Некоторые вещи тратят не только время, но и ресурсы психики. В моей практике много раз было когда сильно могущие люди не хотели, например, проводить презентации или семинары — потому что "мычать под слайды" им ранг не позволит, а нормальная презентация на 50 человек — это значительное напряжение психики. Либо молоко и деньги за вредность, либо используйте того кто этим профессионально занимается .

С другой стороны, нананимая специалиста на конкретную должность подрозумевается что он профессионал и работа по специальности либо не тратит у него ресурсы психики, либо тратит незначительно. Нанимая программиста уровня lead, лично я бы удивился если бы он сказал что "использовать шаблонную магию мне напряжно, давайте я лучше покопипастю немного? И нотация какая-то жесткая, напряжно переучиваться... Да и фреймворк у вас чуток модифицированый — может я лучше по старинке на MFC?" . Но это все на собеседовании быстро выявляется простыми вопросами и обговаривается отдельно

TMU>Хуже, уж извините за печальную истину.

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