SCRUM. У кого на работе считают, что используют?
Даже есть CI нет, тесты все равно нужны
ага и после каждого изменения я буду запускать все тесты. 
Без CI можно запустить раз после всех изменений в сложной части.
Но опять таки от типа проекта сильно зависит.
Если ты какой-то интерфейс переименовал или поменял сигнатуру какой-то функции
для этого вообще не нужно менять тесты, они изменятся автоматом
"то на это должны быть веские основания" почему? Было например "Anzahl" стало "Count", либо просто буква не та.
это контракт, которым описываются правила передачи данных (aka просто набор интерфейсов)
Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений.
для тестирования, скажем, декодера, никакие данные никуда передавать не нужно.
Это уже интересно, а как проверить, что будет делать наш декодер если ему придет дата 29 февраля в любой год например?
ООП TDD
ссылочку тогда мона? Чтобы и наследование заранее сделать и все прочее что там для объектов нужно.
Ну значит оно будет прописано после того, как станет выяснится, что "так не понятно".
Но до этого мы уже написали пару десятков тестов, что с ними делать?
ага и после каждого изменения я буду запускать все тесты.
Конечно! А как может быть иначе? :) Я перед каждым коммитом запускаю все тесты локально. Благо, что юнит-тесты исполняются очень быстро :)
для этого вообще не нужно менять тесты, они изменятся автоматом
Ну это совсем не обязательно.
"то на это должны быть веские основания" почему? Было например "Anzahl" стало "Count", либо просто буква не та.
Потому что в случае, если ты уже выпустил интерфейс, то изменение сигнаруры ведет к потере обратной совместимости. Не знаю как у тебя на работе, а я уже очень много раз сталкивался с тем, что начальство хотело выкатить фикс, но при этом не хотело устанавливать новую версию. И тогда надо было заменить 1-2 dll'ки простым copy-paste.
Я уж не говорю о случаях, когда одна и тебя библиотека используется несколькими продуктами - это еще более распростаненный use-case.
Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений.
Зря она у вас в мусорке :) Эта парадигма позволяет использовать модули как блэк боксы и комбинировать их по необходимости. Например заменять один модуль (связь с реальным COM портом) другим (например сгенерированным NSubstitute'ом).
Это уже интересно, а как проверить, что будет делать наш декодер если ему придет дата 29 февраля в любой год например?
А в чем проблема? Делаешь 2 теста:
1) создаешь экземпляр декодера и пишешь в него 29 февраля 2020г. Получаешь ответ и проверяешь правильность ответа.
2) создаешь экземпляр декодера и пишешь в него 29 февраля 2018г. Получаешь ответ и проверяешь правильность ответа.
Все.
ссылочку тогда мона? Чтобы и наследование заранее сделать и все прочее что там для объектов нужно.
Не понял, ссылочку на что?
Но до этого мы уже написали пару десятков тестов, что с ними делать?
Изменение в требованиях - это достаточно веская причина для того, чтобы изменить тесты.
Странная у нас беседа получилась...
- А расскажите-ка чойта эта скрам такое?
- ...
- Не, это мне не нужно
- Бывает
- Не, ну все же о нём говорят, а мне не нужен. А где нужен-то? А что даст?
- Вот тут и тут нужен, даёт то-то и то-то.
- Ой, что-то вы мне рассказываете... Такого не может быть потому что я такого представить не могу и не видел никогда. Да и у нас такого нет и мы обходимся.
У вас всё хорошо, проблем никаких, все проекты завершаются в срок и все требования выполняются. Радуйтесь! И ничего не меняйте! Я такого пока что не видел. Лично вам на вашей работе скрам не нужен.
Странная у нас беседа получилась...
может для вас и странно а для меня было полезно - спасибо.
Если раньше сомнения терзали, то теперь точно знаю, что действительно скрам был не нужен.
И если раньше подобные объявления мог читать, то сейчас сразу отбрасываю
"arbeitest Du in agilen Entwicklungsprojekten...Starke Mitwirkung in agilen Ritualen und Prozessen"
проблем никаких
Существующие проблемы не решатся скрам методикой
Конечно! А как может быть иначе?
Очень даже может быть иначе. Так как нет однозначных решений для всех ситуаций. Я уже пытался привести примеры.
Когда был проект "с тестами" был специальный "ночной тест" на пару часов вроде, а может и больше, уже не помню.
Потому что в случае, если ты уже выпустил интерфейс, то изменение сигнаруры ведет к потере обратной совместимости.
А если не существует понятия "выпустил интерфейс"?
Я уж не говорю о случаях, когда одна и тебя библиотека используется несколькими продуктами
еще одна интересная тема.
Есть проекты А,Б,С которые используют "стандартную" либу Х (забудем даже что их имеется несколько взаимосвязанных)
Продукты "меняются" очень неравномерно А довольно часто, Б реже, а С раз в пару лет может быть. Соответственно Х может меняться довольно часто.
Есть одно важное требование - А,Б,С должны компилироваться в любой момент времени без ошибок и не требовать повторного тестирования.
Решения?
Эта парадигма позволяет использовать модули как блэк боксы и комбинировать их по необходимости
Надоели разлапистые дубы, если понятно о чём речь. А также раздумья как передать инфу из модуля А в модуль Б - так как они не имеют и не должны иметь "прямой связи".
Все тоже самое можно делать и с "новым" модулем + то что имплементацию можно менять как угодно, неизменным остается только "ид" команды и ее значение.
Структура всех модулей идентична и каждый поддерживает стандартный минимальный набор команд. То бишь разработчику достаточно разобраться с одним модулем чтобы понять, где что искать в остальных.
Одно ограничение - нет "истинного" реал тайм обмена между модулями и/или системой. Но для нас это 1-2% когда действительно надо.
Был на одном проекте любитель интерфейсов. Практически все классы имели "зеркальный" интерфейс, вся иерархия классов почти дублировалась иерархией интерфейсов и т.п. и т.д.
А в чем проблема? Делаешь 2 теста:1) создаешь экземпляр декодера и пишешь в него
никакие данные никуда передавать не нужно
проблема в этом - bold & italic
Хотя теперь понял - речь о физической передаче данных.
Но тут проблема простая - юнит тесты работают, а система все равно сбоит.
Не понял, ссылочку на что?
на ООП TDD. Как начав с тестов получить структуру классов.
Изменение в требованиях - это достаточно веская причина для того, чтобы изменить тесты.
Ага, если раньше можно было было выбросить только "код", то теперь оттестированный код с тестами.
Существующие проблемы не решатся скрам методикой
Кто знает. Вы проблем с процессом разработки не озвучивали.
Это парадигма давно в мусоре у нас валяется. Есть модуль и есть список сообщений. ... А также раздумья как передать инфу из модуля А в модуль Б - так как они не имеют и не должны иметь "прямой связи".
Ааа.. Вы хотите сказать что вы используете шину сообщений? А определение формата сообщений разве не сравним с определением интерфейса?
Вы проблем с процессом разработки не озвучивали.
Так если методика в принципе неприменима.
Давайте подсчитаем, команда 5 человек + 1 ПО + 1 СМ=7. Ладно считаем ПО где то, что то совмещает, СМ в команде. Минимум 5. То есть каждый день тикает 5х оплата.
Проект допустим 25 ч/д, сделает ли команда его за неделю? А если проект на неделю то будет ли он готов за день?
А если два проекта идут одновременно? Один нужно сдавать в Японии, другой в Америке. Берем вторую команду или пусть первая переключается? Кто будет на сдаче проекта и как оперативно решать возникающие проблемы? А что делать если софт работает только исключительно возле устройства которое занимает метров 20 квадратных и расположено оно на другой фирме. Причем для позвонить нужно часто выходить из зала где расположено устройство.
А параллельно еще несколько проблем от клиентов по старым проектам. Кто их должен решать?
Вы хотите сказать что вы используете шину сообщений?
Можно и так определить.
А определение формата сообщений разве не сравним с определением интерфейса?
Параллелей можно проводить много. Сообщение это просто POCO объект.
на ООП TDD. Как начав с тестов получить структуру классов.
-----
Во-первых, терминология, не "на ООП TDD", а TDD в ООП реализации.
Во-вторых, TDD не требует именно ООП. TDD требует чтобы были изложены требования к функциональности и для этих требований был наработан код, выполняющий проверку выполнения этих требований. Все. Как будет выполнятся реализация - не TDD не регламентирует.
Нет, вы рассказываете про проблемы, которые могут произойти если будете использовать скрам и которые вы сами себе выдумали.
Я говорил о проблемах которые у вас есть сейчас. Пока что выглядит так, что их у вас нет.
Параллелей можно проводить много. Сообщение это просто POCO объект.
А интерфейс это просто интерфейс. У вас всё тот же контракт. Просто описаный не интерфейсом а разными классами сообщений. Надо сказать что с EventBus-ом тесты писать даже проще чем с интерфейсами.
А вот что с EventBus-ом плохо так это скалируемость. В смысле роста числа классов сообщений. Сначал их 10, через год 100. Никто нигде не описывает для чего он ввёл сообщение TemperatureIncrement. И мы погрязаем в 2-х антипаттернах:
1. Неправильное повторное использование сообщений.
Разработчик добавляет функцию в управляющий гуй - "изменение температуры срабатывания тревоги". Ему как-то надо от гуя передать модулю мониторинга новое значение. Он находит сообщение TemperatureIncrement и радостно его использует. Конечно же, не тратя н-цать часов на то чтобы проверить а где оно используется сейчас, а кто и при каких условиях его бросает. В результате, модуль получающий сообщение от датчика температуры, видит повышение и кидает TemperatureIncrement, который радостно обрабатывается мониторингом и вместо того, чтобы бить тревогу, просто увеличивает порог срабатывания. Примерно понятно в чем проблема?
2. Дублирование сообщений.
Порывшись в классах сообщений, и не догадавшись что P12RsSig5V это то, что ему нужно, программист делает новое сообщение DoorOpened (которое и посылается когда на 12-м пине повышается напряжение до 5 вольт).
В результате половина приложения ловит старый P12RsSig5V, другая - DoorOpened. И выяснение почему у нас отрытие одной двери обрабатывается так, а другой - этак становится очень увлекательным занятием.
Да, я понимаю, у вас такого никогда не было и не будет, потому что над проектами работает один человек 1-2 месяца.
У вас всё тот же контракт
Это есть смотреть с одной маленькой стороны. Модуль имеет еще все что нужно ему для работы
А вот что с EventBus-ом плохо так это скалируемость.
Не люблю я все эти названия. Академики много чего напридумывают, чтобы было о чем на лекциях рассказывать.
Модуль имеет одну функциональность которая не имеет тенденции к увеличению.
Разработчик добавляет функцию в управляющий гуй - "изменение температуры срабатывания тревоги". Ему как-то надо от гуя передать модулю мониторинга новое значение.
Совершенно другой подход.
Если у меня есть модуль управления температурой и тревогу должен посылать именно этот модуль, то ему добавятся в настройки "температура срабатывания тревоги" и сообщение "тревога - температура выше порогового уровня". Теперь любой модуль (главная прога это тоже модуль) подписанный на сообщения "температурного модуля" может получить это сообщение.
>делает новое сообщение DoorOpened
не может быть отдельного сообщения такого типа - это все статус устройства
И выяснение почему у нас отрытие одной двери обрабатывается так, а другой - этак становится очень увлекательным занятием.
А при интерфейсах такого не будет....
А при интерфейсах такого не будет....
Теоретически может быть. Практически система должна быть просто гигантская. Просто вместо 100 сообщений у нас (грубо, обычно как-то меньше получается) 10 интерфейсов с 10-ю методами.
С сообщениями хорошо работать когда у вас система динамическая, при работе меняется. Модули запускаются и выгружаются.
Не люблю я все эти названия. Академики много чего напридумывают, чтобы было о чем на лекциях рассказывать.
Действительно, все лишь бы грантов набрать. Насколько удобнее общаться когда никто не понимает что же оппонент имеет в виду!
Просто вместо 100 сообщений у нас (грубо, обычно как-то меньше получается)
Если модуль имеет 100 сообщений это просто "неправильный" модуль на него слишком много чего возложено, больше 10-ти я даже и не упомню.
10 интерфейсов с 10-ю методами
минимум 20 различных файлов со своей иерархией.
Как я уже говорил, не может быть одного универсального решения на все случаи жизни. Если бы кто раньше мне сказал, когда я был на одном проекте, вот смотри какое удобное решение Х, мы его практически во всех проекта используем - Я бы спорил с ним до упада, потому как это решение совсем не годилось бы для моего тогдашнего проекта.
И смотрел бы на это решение именно с позиций текущего и предыдущего проектов и оно бы реально казалось полнейшим Г.
Насколько удобнее общаться когда никто не понимает что же оппонент имеет в виду
Это уже как говорится, другой конец палки.
Если есть что то, похоже на что то известное, то совсем не обязательно, что это что то будет точно соответствовать тому что определяется известным. 
А что конкретно неправильно, потому как это по идее должны быть первые вопросы руководства если я приду с идеей - а давайте-ка мы скрам попробуем везде говорят замечательная штука.
Так вы ничего руководству не продадите. Вы должны приходить и говорить - смотрите, у нас есть проблема 1 и 2. Их обе обещает решить скрам, засчёт того-то и того-то. Может, попробуем у насего внедрить?
А разбирать вымышленные проблемы мне, честно говоря, неинтересно. Скрам вам не нужен, помогать вам не надо. А самоутверждаться "я могу найти решение для любой проблемы" не надо мне. Мне реальных хватает. Как объяснить двум программистам, никогда не писавших сложных проектов на мейвене, что в сложном проекте очень удобно разбивать на мелкие модули... У них проблем-то нет, вернее они сними никогда не сталкивались.
Если модуль имеет 100 сообщений это просто "неправильный" модуль на него слишком много чего возложено, больше 10-ти я даже и не упомню.
Я не говорил про модуль, посылающий 100 сообщений. Я про суммарные 100 сообщений. 20 модулей, каждый от 3 до 7. В сумме чтобы правильно писать нам надо помнить про все 100 сообщений. Чтобы не дублировать. А если мы эти сообщения через что-то внешнее персылаем, вроде MQ сервера, то тут и за форматом следить придется.
минимум 20 различных файлов со своей иерархией.
Это на каковском языку? Или это в визуальной студии такие ужасы? Но вообще не важно. Хоть по 5 файлов на интерфейс. Нам их править очень редко надо. Слышали такое - "код пишется один раз а читается 100"?
Как я уже говорил, не может быть одного универсального решения на все случаи жизни.
Я это все к чему. Объявлять всю парадигму программирования с контрактом (с интерфейсами) валяющейся в мусорке и замененой лучшей - шиной сообщений - в корне неверно. На тучи сообщений уже накалывались. Не раз и не два. Интерфейсы не отомрут никогда, уж больно концепт удобный. Есть несколько языков именно с таким принципом - все всем сообщения кидают. Но почему-то пишут почти все на сях, яве и скриптах.
P.S. дебажить Objective C это лютый трындец.
Так вы ничего руководству не продадите.
Что бы кому то что то продать нужно хотя бы верить, что он это может купить.
Для начала нужно иметь хотя бы 5 человек которые бы работали совместно над одной задачей относительно продолжительное время. Или?
В сумме чтобы правильно писать нам надо помнить про все 100 сообщений.
ладно, даже откидывая то что и в сумме сотня не наберется - зачем мне помнить все сообщения от всех модулей? В один момент я "разбираюсь" только с одним модулем и все сообщения "сидят" внутри одной программы.
Я не решаю задачи общего плана для всех случаев жизни. Есть конкретная область применения и конкретные задачи.
Это на каковском языку?
По идее на любом. Есть интерфейс - декларация и должна быть имплементация. Можно засунуть и в один физический файл, но смысла это никак не меняет
Объявлять всю парадигму программирования с контрактом (с интерфейсами) валяющейся в мусорке и замененой лучшей - шиной сообщений - в корне неверно.
Я же не предлагал всем сделать такую замену. И еще непонятно, что лично Вы под этим подразумеваете. "Отдельно стоящие" интерфейсы никуда не исчезают, сервисы как на них базировались так и останутся. А вот работа с "деревом" на уровне проекта меняется. Модуль больше не представлен интерфейсом от которого "растет" куча других.
Раньше действительно все "модули" были базированы на интерфейсах и было все замечательно до поры до времени. И в других типах проектов возможно так и останется. Но только не в тех что требуются сейчас.
На тучи сообщений уже накалывались.
точно также как и на тучи интерфейсов. Всего должно быть в меру.
почти все на сях, яве и скриптах.
сорри, C# как то незаслужено забыт
Можно было еще и форт или Ruby вспомнить