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

IQ>>·>Если уж подходить предвзято — это не критерии. Да и вообще, мерж конфликтов сам по себе — сигнал плохо поставленного процесса разработки.
IQ>>))) Не ясно как можно избежать мерджа если хотя бы два программера пилят один и тот же проект.
·>Ну как-как... Как люди писали софт лет 20 назад? Только Вася может трогать DAO-классы. А ты, Петя, можешь трогать только Controller-классы, и не смей больше трогать DAO — опять всё поломаешь, если надо — обращайся к Васе, он всего через 3 недели из отпуска вернётся, у него найдётся время, наверное.

Вспоминаю детство увы такой подход несерьезный )))

IQ>>>>А обсуждать артефакты можно по емейлу. Создал пару excel spreadsheets и что ещё для счастья надо?!
IQ>>Можно, но тогда потеряется история. Да и искать артефакты в тоннах прочего коммуникационного хлама, у меня например плохо получается.
·>Зачем тебе история? Сиди пиши код.

Я в недоумении ))) я конечно не работаю на "больших проектах", но даже у меня на четверти change request аналитики делают более 5 изменений.

IQ>>>>TDD имхо не имеет вообще никаких критериев и имхо никак не может быть оценен.
IQ>>·>Он позволяет значительно сократить время от написания кода до его исполнения.
IQ>>)))Поправочка он может сократить, а может и не сократить ))) и вы никогда не обьясните как добиться первого и избежать второго.
·>Угу. И использование системы контроля версий может дать возможность мержить, а может и не дать. Попробуй помержь какие-нибудь файлы проектов или .rc в вижуал-студиях каких-нибудь...

))) я мержил все ))) ни один текстовый мерж не имеет ни шанса )))

>>>>>А так же предоставляет формальный способ коммуникации — код тестов это по сути исполняемая документация.
IQ>>Осталось определиться с критериями полноты и актуальности )))
·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?

))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.

Как измерить полноту? Хороший вопрос, вероятно по количеству обращений за пояснениями к заказчику... в случае если проект будет принят. Если он не принят значит обращений было не достаточно )))

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

IQ> ·>Ну как-как... Как люди писали софт лет 20 назад? Только Вася может трогать DAO-классы. А ты, Петя, можешь трогать только Controller-классы, и не смей больше трогать DAO — опять всё поломаешь, если надо — обращайся к Васе, он всего через 3 недели из отпуска вернётся, у него найдётся время, наверное.
IQ> Вспоминаю детство увы такой подход несерьезный )))
Работает же!

IQ> ·>Угу. И использование системы контроля версий может дать возможность мержить, а может и не дать. Попробуй помержь какие-нибудь файлы проектов или .rc в вижуал-студиях каких-нибудь...
IQ> ))) я мержил все ))) ни один текстовый мерж не имеет ни шанса )))
Для этого СКВ не обязательна!

IQ> IQ>>Осталось определиться с критериями полноты и актуальности )))
IQ> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.

IQ> Как измерить полноту? Хороший вопрос, вероятно по количеству обращений за пояснениями к заказчику... в случае если проект будет принят. Если он не принят значит обращений было не достаточно )))

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


IQ>> IQ>>Осталось определиться с критериями полноты и актуальности )))
IQ>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.

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

Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов.

И это я еще не беру в рассчет ошибки программера.

·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.

В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))

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

IQ>>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ>>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
IQ>·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
IQ>Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Непонятно. В этом случае пользователи будут ворчать, что программа делает не то, что надо. Конечно, тесты не могут гарантировать, что реализованный функционал работает как нужно пользователям. Тесты лишь проверяют, что новый функционал уже (до коммита кода) работает или существующий функционал всё ещё (после внесения изменений) работает.

IQ>Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов.
Это слишком абстрактно. Так не долго дойти до роли человека во Вселенной, смысле жизни, сущности всего.

IQ>И это я еще не беру в рассчет ошибки программера.
Да. Это хорошо решается другими техниками — парное программирование, ревью, написание тестов (по крайней мере некоторых из них) другими людьми.

IQ>·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
IQ>В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))
Мне просто довелось в такой команде поработать — одно удовольствие.
Бизнесу об этом и не надо знать, он просто может доверять девам, что они знают что делают для обеспечения качества.

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

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

IQ>>Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
·>Непонятно. В этом случае пользователи будут ворчать, что программа делает не то, что надо. Конечно, тесты не могут гарантировать, что реализованный функционал работает как нужно пользователям. Тесты лишь проверяют, что новый функционал уже (до коммита кода) работает или существующий функционал всё ещё (после внесения изменений) работает.

Вы все правильно говорите ))) Заказчик всегда будет ворчать, что функционал не работает так как ему надо ))) и пофиг ему на все юнит тесты.

IQ>>Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов.
·>Это слишком абстрактно. Так не долго дойти до роли человека во Вселенной, смысле жизни, сущности всего.

Возможно... на мой взгляд все предельно конкретно ))) и позволяет формировать верное отношение к вещам, а это имхо залог способности избегать самообмана.

IQ>>·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
IQ>>В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))
·>Мне просто довелось в такой команде поработать — одно удовольствие.
·>Бизнесу об этом и не надо знать, он просто может доверять девам, что они знают что делают для обеспечения качества.

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

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

IQ>·>Непонятно. В этом случае пользователи будут ворчать, что программа делает не то, что надо. Конечно, тесты не могут гарантировать, что реализованный функционал работает как нужно пользователям. Тесты лишь проверяют, что новый функционал уже (до коммита кода) работает или существующий функционал всё ещё (после внесения изменений) работает.
IQ>Вы все правильно говорите ))) Заказчик всегда будет ворчать, что функционал не работает так как ему надо ))) и пофиг ему на все юнит тесты.
Заказчику в общем-то на весь код пофиг.

IQ>>>Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода. Что уж тут говорить по поводу тестов.
IQ>·>Это слишком абстрактно. Так не долго дойти до роли человека во Вселенной, смысле жизни, сущности всего.
IQ>Возможно... на мой взгляд все предельно конкретно ))) и позволяет формировать верное отношение к вещам, а это имхо залог способности избегать самообмана.
Если обсуждать техническую реализацию (а тесты это часть её), то нужно опираться на ближайший источник требований — бизнес-требования. А откуда они берутся — не столь важно. Конечно, эти требования могут быть плохо сформулированы или не удовлетворять бизнес-задачам, но это проблема к тестам и вообще написанию кода не имеет никакого отношения.

IQ>>>·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
IQ>>>В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))
IQ>·>Мне просто довелось в такой команде поработать — одно удовольствие.
IQ>·>Бизнесу об этом и не надо знать, он просто может доверять девам, что они знают что делают для обеспечения качества.
IQ>Я не про то. Я намекал на то, что если бизнес на нашел времени сформулировать "тесты" как "валидные кейсы" то очень вероятно, что система ему нафиг не нужна.
Бизнес формулирует не тесты, а бизнес-требования в виде сценариев/историй, описывая неформальным документом. Это уже задача разработчиков формализовать требования в виде кода.