Для начала нужно иметь хотя бы 5 человек которые бы работали совместно над одной задачей относительно продолжительное время. Или?

Для начала надо определить проблемы, с которыми вы хотите бороться. Чтобы найти решение именно для этих проблем. И пытаться продать это решение руководству.

В один момент я "разбираюсь" только с одним модулем и все сообщения "сидят" внутри одной программы.

Во-во. Типичный ответ на вопрос "а почему ты не посмотрел что точно такое же сообщение уже бросает другой модуль".Хм... Или мы под шиной сообщений понимаем разные вещи. Я думал у вас модули друг с другом общаются сообщениями.

А вот что вы под " все сообщения "сидят" внутри одной программы" имели в виду я, честно говоря, не понял.

Есть интерфейс - декларация и должна быть имплементация.

Имплементция меня не интересует. Их может быть 1 а может быть 100. Когда декларируешь интерфейс об имплементациях не думаешь.

И наоборот - а если быне было интерфейса, код из класса, его имплементирующего, что, изчез бы? Код был бытак или этак. Так что в решении с контрактом (интерфейсом) вы добавили 1 файл. Сам интерфейс.

точно также как и на тучи интерфейсов.

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

сорри, C# как то незаслужено забыт Можно было еще и форт или Ruby вспомнить

Под сями я имел в виду все - от ansi c до c# и objetive c.

Форт с руби... Тогда уж питон. Да и пыхыпы их обоих делает в разы. А так можно и смолтолк, хаскел и смл вспомнить. Свои 0,0001% они имеют.

А если наоборот, тогда как?

----

Тогда не ТДД.

По крайней мере реализация требований написанных тестов может быть не на ООП-языке...

Тогда не ТДД.

Да ты шо, как же без него можна Это так круто, что вначале тесты.

Ладно фиг с ним...

Вот у меня есть допустим требование: начало процесса измерения должно обеспечиваться нажатием кнопки старт

Не доходит как тест на это написать, какой результат он должен проверять?

Для начала надо определить проблемы

никак не пойму почему они должны быть на первом месте? Что это меняет?

Допустим, хотим улучшим качество кода и документации, вы указывали что одно из преимуществ.

Следующее то все равно будет - а что тебе для этого надо?

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

"а почему ты не посмотрел что точно такое же сообщение уже бросает другой модуль"

А другой модуль не может в принципе бросать такое же сообщение, а если сообщение и совпадает, например "ошибка", то реакция все равно может быть другой.

Или мы под шиной сообщений понимаем разные вещи

Я не искал определения, но судя по тому что здесь написано, почти совпадает

https://studopedia.ru/9_122535_shina-soobshcheniy.html

Я думал у вас модули друг с другом общаются сообщениями

А к модулю нет другого пути или послать ему сообщение или подписаться на его сообщения. Константы еще разрешено пользовать определенные в "заголовке" модуля

А вот что вы под " все сообщения "сидят" внутри одной программы" имели в виду

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

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

Про такое не слышал

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

Так что в решении с контрактом (интерфейсом) вы добавили 1 файл

совершенно верно, из-за этого и получается минимум 2х "классов"

под с-ями я имел в виду все - от ansi c до c# и objetive c.

как то сложно до этого додуматься. Я бы ожидал от вас какого то понятия типа "процедурные языки"

Не доходит как тест на это написать, какой результат он должен проверять?

-----

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

Только не спрашивай меня как оно определит нажатие физической кнопки,,, :)

Я уже пытался привести примеры.

С примерами у тебя не получилось ;)

Когда был проект "с тестами" был специальный "ночной тест" на пару часов вроде, а может и больше, уже не помню.

Тесты в этом проекте не были юнит-тестами. Это было все что угодно, интергационные или системные тесты, но не юнит-тесты. Юнит-тесты быстрые. Всегда. Если юнит-тест долго исполняется, то это с вероятностью 99% не юнит-тест и с вероятностью 1% - плохой тест (и его надо переделать)

А если не существует понятия "выпустил интерфейс"?

Тогда ты пишешь либо самую первую версию, либо в стол.

Есть проекты А,Б,С которые используют "стандартную" либу Х (забудем даже что их имеется несколько взаимосвязанных)
Продукты "меняются" очень неравномерно А довольно часто, Б реже, а С раз в пару лет может быть. Соответственно Х может меняться довольно часто.
Есть одно важное требование - А,Б,С должны компилироваться в любой момент времени без ошибок и не требовать повторного тестирования.
Решения?

Решение - не нарушать обратную совместимость.

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

Что нужно, чтобы все это работало:

1) Нужен контроль за версиями релизов библиотеки Х.

2) Нельзя изменять существующие контракты.

3) Можно добавлять новые контракты.

А также раздумья как передать инфу из модуля А в модуль Б - так как они не имеют и не должны иметь "прямой связи".

Если между модулами А и Б нет прямой связи, то ничего не надо передавать из А в Б ;) Что-то ты тут пытаешься мудрить ;)

Был на одном проекте любитель интерфейсов. Практически все классы имели "зеркальный" интерфейс, вся иерархия классов почти дублировалась иерархией интерфейсов и т.п. и т.д.

Ну заставь дурака богу молиться ;)

Но тут проблема простая - юнит тесты работают, а система все равно сбоит.

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

Как начав с тестов получить структуру классов.

TDD описывает использование контрактов. Что там у тебя за структура классов - никто не знает. Но при этом, используя TDD разработчик вынужден заранее продумать как используемые интерфейсы, так и структуру классов. Более того, при написании теста все эти интерфейсы и классы автоматически проверяются на понятность и простоту использования.

Ага, если раньше можно было было выбросить только "код", то теперь оттестированный код с тестами.

Конечно! Так же как если ты писал этот код по Pflichtenheft, то вместе с кодом придется тебе выкидывать текст из Pflichtenheft, апдейтить Wiki и бог знает какие еще действия, чтобы обновленные код соответствовал существующей документации.

никак не пойму почему они должны быть на первом месте? Что это меняет?

Это меняет отношение к предлагаемому новшеству. На "а давайте сделаем ещё лучше!" вы в 99,9% получите ответ "а зачем?".

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

Допустим, хотим улучшим качество кода и документации, вы указывали что одно из преимуществ.

Следующее то все равно будет - а что тебе для этого надо?

Ну если вы ко мне с таким придёте и в ответ на "что тебе для этого надо" скажете "скрам!" - я вас выгоню. Может не ссаными но тряпками.

Есть менее болезненные способы поднять качество кода, не перестраивая отношение к разработке. Введите для начала обязательные code review и, например, настройте статический анализ кода. Поднимите CI которое будет гонять юнит тесты после каждой правки. Начните мерять покрытие кода тестами. И те де и те пе.

-----

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

Ну, видимо, наличие отсутствия процесса до нажатия кнопки

И что мне это даст? А если процесса нет?

Тесты в этом проекте не были юнит-тестами - Юнит-тесты быстрые. Всегда.

Странная у вас логика. Если я тестирую например функцию y=f(a,b,c) - это будет юнит тест или нет?

А если функция вычисляется от нескольких секунд до нескольких минут это быстро или нет.

А если каждый параметр вариируется с шагом 0.5 или с шагом 0.01 будет разница или нет?

Тогда ты пишешь либо самую первую версию, либо в стол.

Может тогда определимся с понятием "выпустил интерфейс"?

Решение - не нарушать обратную совместимость.

и тогда все будет шоколадно?

что ты понимаешь под "не требовать повторного тестирования"?

Проект "А" был оттестирован 3 года назад, теперь мне его надо просто компильнуть по новому, заказчик имя фирмы поменял.

1) Нужен контроль за версиями релизов библиотеки Х.

Git подойдет? Плавно переходим к сопутствующей проблеме.

Либа Х лежит в репо1, проект С в репо2 нужна одна новая ветка, так как менятся будет и то и другое

2) Нельзя изменять существующие контракты.

А если нужно тогда как? делать новые интерфейс IAbc2?

Если между модулями А и Б нет прямой связи, то ничего не надо передавать из А в Б

заказчику объяснить сможете отчего его хотелку нельзя сделать?

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

примерчик мона? Простейший пример, есть прога, нужно ввести число А и Б, по нажатию кнопы получить сумму. Все должно происходить "на экране" - "визуально"

и бог знает какие еще действия

И что все удается держать синхронно?

Это меняет отношение к предлагаемому новшеству.

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

А вот предложение "а давайте исправим проблему, из-за которой мы в прошлом году 2-х заказчиков потеряли"

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

Потерять заказчика можно только из-за цены.

скажете "скрам!" - я вас выгоню. Может не ссаными но тряпками.

Вот для этого я хотел список минимальных "требований" для скрама

Поднимите CI которое будет гонять юнит тесты после каждой правки

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

Начните мерять покрытие кода тестами.

Был такой бзик на одном проекте.

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

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

И не совсем понятно какие технические проблемы вас интересуют. С чем бороться хотите?

Это в принципе не может быть из-за софта ... Хотя без софта это всего лишь груда металла.

Имхо тут противоречие... Вы уж определитесь.

Потерять заказчика можно только из-за цены.

А если вы к назначенному сроку софт не сделаете? Заказчик удовлетворится грудой металла? А стоимость разработки софта на цену проекта не влияет?

Как вы это себе представляете для Х проектов? Постоянно подключать новые проекты и отключать старые?

Нет, постучите в бубен и оно само всё сделается. Конечно подключать новые и отключать старые. Непонятно почему вас это пугает. У вас что, по 300 новых проектов в день появляется?

Был такой бзик на одном проекте.

Вот-вот. Тут бзик, там не надо, тут зачем это. У вас идеальная разработка идеальных проектов, которые не надо тестировать, не надо документировать и вообще - из-за софта заказчиков не потеряете, так что можно даже эти идеальные проекты вообще не делать. Вам скрам противопоказан.

И вообще скрам придумали учёные чтобы было что преподавать, на самом деле он никому не нужен и нигде не помогает. Как TDD и всё остальное, что вы в данный момент не используете.

это будет юнит тест или нет?

-----

Нет,

Если я тестирую например функцию y=f(a,b,c) - это будет юнит тест или нет?

Может будет, а может и нет. Зависит от того, что именно происходит в этой функции.

Пусть a - канал связи (не важно, Ethernet или COM), b - массив данных, с - количество данных, которые надо передать, y - результат передачи.

Так вот, если ты для a передашь реальные канал связи, то это уже совершенно точно никакой не юнит-тест.

А если функция вычисляется от нескольких секунд до нескольких минут это быстро или нет.

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

А если каждый параметр вариируется с шагом 0.5 или с шагом 0.01 будет разница или нет?

Не понял, какое влияние на функцию оказывают изменяющиеся параметры? Что именно ты хочешь тестировать?

Может тогда определимся с понятием "выпустил интерфейс"?

Выпустил интерфейс - это значит, что библиотека/сборка, в которой находится интерфейс получила свою версию и была прошла через release процесс (процесс этот на всех фирмах разный).

и тогда все будет шоколадно?

Как минимум решит большую часть проблем.

Проект "А" был оттестирован 3 года назад, теперь мне его надо просто компильнуть по новому, заказчик имя фирмы поменял.

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

Git подойдет?

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

Либа Х лежит в репо1, проект С в репо2 нужна одна новая ветка, так как менятся будет и то и другое

Ты про разделение ответственности что-нибудь слышал? Либа Х, очевидно, является компонентой для проекта С. Значит работа должна выстраиваться так:

1) проект С создает требования для либы Х

2) либа Х реализует эти требования, производит тестирование по требованиям и выпускает (делает release) версия X.Y.1

3) проект С берет выпущенную версию либы Х и делает свои изменения.

В принципе, можно подойти к этому процессу не так строго и разрабатывать параллельно, т.е. проект С может базироваться на nightly build'е либы Х... но разработка либы Х все равно остается независимым от проекта С процессом. В то время как разработка проекта С зависит от либы Х. Короче говоря, либа Х как была в своем репо1, так и остается, также как и проект С и нет ни одной причины сливать их в одну ветку.

А если нужно тогда как? делать новые интерфейс IAbc2?

Например так. В шарпе можно добавлять новые функции без изменения имени интерфейса.

заказчику объяснить сможете отчего его хотелку нельзя сделать?

Я не понимаю проблемы. Если между А и Б нет никакой связи, то, соответственно, нет и информации. Т.е. либо делается связь, либо объясняешь почему эту связь нельзя сделать. В чем тут проблема?

примерчик мона? Простейший пример, есть прога, нужно ввести число А и Б, по нажатию кнопы получить сумму. Все должно происходить "на экране" - "визуально"

Примерчик чего? Примерчик тестирования функции, которая считает сумму?

Я бы сделал такое приложение на WPF. Соотвественно мне нужно было бы 1) ModelView (которое не надо было бы тестировать в виду отсутствия логики) 2) односторонний конвертер string to int (2 теста) и 3) модель с 1 функцией (для суммы одного теста будет достаточно). Для того, чтобы проветить, что все работает можно было бы сделать системный тест, который бы запускался ночью и кликал бы в нужные места.

И что все удается держать синхронно?

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

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

Вообще то я никого на форумах ни к чему не принуждаю

Меня интересуют "технические проблемы" скрама....

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

А если вы к назначенному сроку софт не сделаете?

Такого не может быть в принципе - он может работать не совсем так или даже вылетать но для этого и есть inbetriebnahme.

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

А стоимость разработки софта на цену проекта не влияет?

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

Непонятно почему вас это пугает

Временем и бессмысленностью, Зачем мне "СИ проект" на неделю или месяц?

на самом деле он никому не нужен и нигде не помогает

Это вы уже по гиперболе пошли - у нас метод "необходимой достаточности", что происходит у других я и пытаюсь понять.

Вообще то я никого на форумах ни к чему не принуждаю

Это вам так кажется.

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

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

Как-то так.

Такого не может быть в принципе - он может работать не совсем так

Круто. А если робот - манипулятор вместо того, чтобы брать коробочку, будет фигячить по ней кулаком это тоже "работает не совсем так"? :)

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

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

Нормальный робот без обвязки, установки и наладки не стоит ничего. Вернее стоит отрицательную сумму. Которую надо потратить чтобы его утилизировать. Потому что использовать не получится. А так, железо может стоить от 3 тысяч до пары сотен миллионов (интересно, сколько все эти марсоходы стоили...) В зависимости от офигиарда параметров. А что?

Временем и бессмысленностью, Зачем мне "СИ проект" на неделю или месяц?

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

что происходит у других я и пытаюсь понять.

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

Зависит от того, что именно происходит в этой функции.

скажем так - некая математическая функция. Все параметры вещественные числа.

Я таких функций еще ни разу не встречал.

Это не страшно, я тоже много чего не встречал. Гляньте хотя бы время вычисления "функций" класса NP или даже тригонометрическую функцию вызовите достаточное число раз.

я уверен, даже сложные расчеты можно поделить на части и протестировать отдельные элементы

У меня такой уверенности нет, но я не математик. Это они могут сказать возможно ли это и есть ли в этом смысл

Не понял, какое влияние на функцию оказывают изменяющиеся параметры?

http://nunit.org/docs/2.5/range.html

Так более понятно?

Выпустил интерфейс - это значит, что библиотека/сборка, в которой находится интерфейс получила свою версию

А если интерфейс находится в самом приложении тогда как? Или сборка предназначена исключительно для одного приложения?

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

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

Надо только придумать, как там отслеживать "релизнутые" версии, например ставить тэги

Это еще одна интересная проблема, особенно когда кто то успел "вклиниться". А как заказчик мне скажет прога с каким тэгом у него стоит?

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

Либа Х, очевидно, является компонентой для проекта С

либа Х является общей для Y проектов и если нужно делать серьезные изменения, то мы всегда делаем новую ветку.

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

Т.е. либо делается связь, либо объясняешь почему эту связь нельзя сделать. В чем тут проблема?

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

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

Примерчик чего? Примерчик тестирования функции, которая считает сумму?

нет, как написав вначале тесты я получу "классное" приложение. Никак не доходит смысл TDD подхода именно для создания приложения, а не кучи функций.

Соотвественно мне нужно было бы

А зачем мне для данного приложения MVVM?

Я сделаю "рыбу" - дополните? Просто интересно, я бы по другому делал. Но с WPF я начал относительно недавно.

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

Тогда зачем держать столько Доков.

А в чем же конкретно прелесть?

Но потом мы выяснили что у вас никакой необходимости его использовать нет

Я с самого начала именно это и сказал

А если робот - манипулятор вместо того, чтобы брать коробочку, будет фигячить по ней кулаком

Опять таки, подобного никак не может быть, по многим причинам. Начиная с той, что роботы мы не программируем. Но даже программисту робота нужно будет очень постараться, чтобы добавить подобную функцию.

вам не важно качество, документация, скорость разработки, возможность заменить программиста если один заболел или попал под машину

То бишь чудо скрам метод принесет это все на тарелочке с голубой каемочкой - так это нужно понимать?

Сложно понять что происходит у других в каждом втором предложении утверждая "так не бывает

А что, если я буду со всем соглашаться так я пойму быстрее?