В планах создателей — возможность отправлять краткие сообщения, с помощью которых пользователи смогут уведомлять своих родных и друзей о своём здоровье.
Кто и по какой причине предпочтет отправлять через вас если есть мессенджеры, звонки и смс?
Насколько я понимаю, разные реализации означает выполнение разных требований. Вы не можете в произвольной программе заменить аллокатор и надеяться на то, что код будет гарантированно работоспособен.
Соответственно, эти требования могут быть выражены через тесты.
Но опять же TDD это юниты не завязанные на внутреннюю структуру. Хотя бы потому что для того чтобы знать внутреннюю структуру функций перехода код этих функций перехода уже должен быть.
Тесты мне больше напоминают не доказательство теорем, а экспериментальную проверку гипотезы. А TDD — создание хорошей теории по набору экспериментов — минимальной и покрыващей все случаи (ну и разработку дополнительных экспериментов для проверки теории)
Вторая только показывает или можно попользоваться?
Какой у меня опыт заказа, не было ли в прошлом такого, что через три года обнаруживается что я (или они) упустил что-то важное и результат не совсем тот, который я имел ввиду?
Я вообще не представляю как так можно работать, если вы, конечно, не троллите.
Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями. Либо у вас какая-то специфическая ниша, либо вы чего-то не замечаете, либо вы тролите.
С моей точки зрения это все требует соображалки. Поиски баги — особенно.
А у вас есть вообще какие-о метрики по качеству найма? Если есть, поделитесь пожалуйста. По-быстрому не получается найти.
Кто и по какой причине предпочтет отправлять через вас если есть мессенджеры, звонки и смс?
Насколько я понимаю, разные реализации означает выполнение разных требований. Вы не можете в произвольной программе заменить аллокатор и надеяться на то, что код будет гарантированно работоспособен.
Соответственно, эти требования могут быть выражены через тесты.
Я могу посмотреть в реализацию, но написать тесты так, чтобы они не зависели от реализации.
Например, если я вижу непокрытую ветку, я могу добавить тест на то внешнее поведение, которое она реализует.
А с чего вы решили что юнит тестирование делается по методу черного ящика?
А не тем какие взаимодействия со внейшней средой были в прошлом?
А внутренние состояния определяются чем?
Не должен — должна быть идея этого кода.
Эээ как вы определяете юнгит тесты и бранч тесты? Я нашел только определение бранч тестинга, и TDD, как мне кажется, неплохо на него ложится.
Тесты мне больше напоминают не доказательство теорем, а экспериментальную проверку гипотезы. А TDD — создание хорошей теории по набору экспериментов — минимальной и покрыващей все случаи (ну и разработку дополнительных экспериментов для проверки теории)
Это как?
Это при нормальных названиях, тестах и кодревью? У меня другой опыт.
Ой где же я могу посмотреть сигнатуры методов кроме как в документации?
Вторая только показывает или можно попользоваться?
Какой у меня опыт заказа, не было ли в прошлом такого, что через три года обнаруживается что я (или они) упустил что-то важное и результат не совсем тот, который я имел ввиду?
Вы ж сами недавно писали, что чем больше фич тем лучше. Продукт с большим количеством фич вытесняет продукт меньшим.
Эээ. Все ваши рассуждения относятся только к ядрам или к продуктам в целом тоже?
Можно ли где-то увидеть ченджлог того, что вы называете ядром Parasolid?
А как получается что у парасолид есть новые фичи в новых версиях?
Если все что вы рассказываете верно, я представляю ченджлог так:
....
Тогда почему все выбирают неправильно оценивать?
Я вообще не представляю как так можно работать, если вы, конечно, не троллите.
Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями. Либо у вас какая-то специфическая ниша, либо вы чего-то не замечаете, либо вы тролите.
А результат планирования кому-то нужен? Что происходит если план не соответсвует факту? Кто-то страдает от этого?