Но опять же TDD это юниты не завязанные на внутреннюю структуру. Хотя бы потому что для того чтобы знать внутреннюю структуру функций перехода код этих функций перехода уже должен быть.
Тесты мне больше напоминают не доказательство теорем, а экспериментальную проверку гипотезы. А TDD — создание хорошей теории по набору экспериментов — минимальной и покрыващей все случаи (ну и разработку дополнительных экспериментов для проверки теории)
Вторая только показывает или можно попользоваться?
Какой у меня опыт заказа, не было ли в прошлом такого, что через три года обнаруживается что я (или они) упустил что-то важное и результат не совсем тот, который я имел ввиду?
Я вообще не представляю как так можно работать, если вы, конечно, не троллите.
Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями. Либо у вас какая-то специфическая ниша, либо вы чего-то не замечаете, либо вы тролите.
Т.е. все занимаются самообманом в отношении планирования.
Пункт "надо лучше оценивать" имхо слишком общий — это постановка проблемы, а не результат ретры. Обычно на ретрах рекомендуется выбрать какой-то эксперимент, чтобы на следующей ретре оценить его результаты. Типа "сравнить точность метода вчерашней погоды на готовых данных".
Се́кта (сред.-в. лат. secta — школа, учение, от лат. sequor — следую) — понятие (термин), которое используется для обозначения религиозной, политической, философской или иной группы, иногда отделившейся от основного направления и противостоящей ему, или указания на организованную традицию, имеющую своего основателя и особое учение[1][2]
Я могу найти нечто общее между сектой и agile. Как и практически между сектой и любым другим направлением мысли.
Да и другие люди тоже бывают "java guru", "C# pundit" и прочее. Религия — достаточно частая метафора.
Я могу посмотреть в реализацию, но написать тесты так, чтобы они не зависели от реализации.
Например, если я вижу непокрытую ветку, я могу добавить тест на то внешнее поведение, которое она реализует.
А с чего вы решили что юнит тестирование делается по методу черного ящика?
А не тем какие взаимодействия со внейшней средой были в прошлом?
А внутренние состояния определяются чем?
Не должен — должна быть идея этого кода.
Эээ как вы определяете юнгит тесты и бранч тесты? Я нашел только определение бранч тестинга, и TDD, как мне кажется, неплохо на него ложится.
Тесты мне больше напоминают не доказательство теорем, а экспериментальную проверку гипотезы. А TDD — создание хорошей теории по набору экспериментов — минимальной и покрыващей все случаи (ну и разработку дополнительных экспериментов для проверки теории)
Это как?
Это при нормальных названиях, тестах и кодревью? У меня другой опыт.
Ой где же я могу посмотреть сигнатуры методов кроме как в документации?
Вторая только показывает или можно попользоваться?
Какой у меня опыт заказа, не было ли в прошлом такого, что через три года обнаруживается что я (или они) упустил что-то важное и результат не совсем тот, который я имел ввиду?
Вы ж сами недавно писали, что чем больше фич тем лучше. Продукт с большим количеством фич вытесняет продукт меньшим.
Эээ. Все ваши рассуждения относятся только к ядрам или к продуктам в целом тоже?
Можно ли где-то увидеть ченджлог того, что вы называете ядром Parasolid?
А как получается что у парасолид есть новые фичи в новых версиях?
Если все что вы рассказываете верно, я представляю ченджлог так:
....
Тогда почему все выбирают неправильно оценивать?
Я вообще не представляю как так можно работать, если вы, конечно, не троллите.
Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями. Либо у вас какая-то специфическая ниша, либо вы чего-то не замечаете, либо вы тролите.
А результат планирования кому-то нужен? Что происходит если план не соответсвует факту? Кто-то страдает от этого?
Всех нужных и не нужных?
Т.е. все занимаются самообманом в отношении планирования.
Пункт "надо лучше оценивать" имхо слишком общий — это постановка проблемы, а не результат ретры. Обычно на ретрах рекомендуется выбрать какой-то эксперимент, чтобы на следующей ретре оценить его результаты. Типа "сравнить точность метода вчерашней погоды на готовых данных".
Конечно. Я согласен.
Я могу найти нечто общее между сектой и agile. Как и практически между сектой и любым другим направлением мысли.
Да и другие люди тоже бывают "java guru", "C# pundit" и прочее. Религия — достаточно частая метафора.
А как вы планируете? По идее "метод вчерашней погоды" должен колебания привести к среднему.