Любая метрика является, всего лишь, вспомогательным индикатором. Точно так-же, покрытие всех функциональных требований не гарантирует того, что ПО ведет себе в соответствии с ожиданиями.
woooody прав. Для того, что бы говорить о покрытии кода тестами, нужно обязательно уточнять какая именно метрика используется. Если интересно — вот достойное описание различных видов метрик покрытия кода. Но… их тоже нужно применять в зависимости от того, что вы собственно разрабатываете. Вот рекомендации.
я стараюсь сделать так, чтобы пользователю описание типа было не видно
Я не совсем понял как Вы это делаете.
Если интерфейсная функция принимает указатель на структуру в качестве параметра, Вы просто декларируете это как foo( void * )? Я просто не сталкивался с такой потребностью.
Спасибо.
Ребят, а можно ли объяснить (в принципе) необходимость или потребнсть в хорошем дизайне?
Меня иногда просто де-мотивируют вопросы коллег-программистов из серии «А зачем так усложнять?».
Опускаются руки.
Просто как вариант.
Если гарантированно, что писатель один, а читателей сколько угодно, то см. «Non-blocking Write Protocol» в Real-Time Systems: Design Principles for Distributed Embedded Applications. Решается одной atomic переменной, как указал HaronK
Формат данных не важен (очередь, стек, и т.п. — просто блок данных)
Как разработчик — согласен на 100%
Но, как правило, это очень дорого. Если предварительно не ограничить скоуп тестирования метриками покрытия кода/требований, то тестирование не закончится никогда.
ТовариСЧи, ну это же пиз… ц какой-то. Я прошу прощения у всех Хабро-Жителей за такие слова. Но других просто нет. Заминусуйте, если того «требует кодекс». boldachev, восхищаюсь Вашим терпением, последовательностью в изложении аргументов и целеустремленностью.
Лично мне, как сама статья, так и комментарии ТС, как то:
Я знаю, что ограничение на отношение объект-класс существует во всех моделлерах. Но именно это ограничение не позволяет дать мне определение некоторых объектов нашего мира.
напоминают старый анекдот:
Развод в Одессе.
Судья:
— Почему Вы с ней хотите развестись?
— Она меня не удовлетворяет.
Голос из зала:
— Подумаешь, пол-Одессы удовлетворяет, а его нет.
Отсюда и вопрос к maxstroy: При разработке каких систем (конкретно, пожалуйста, с примерами) Вы уперлись в принципиальную невозможность решить поставленную перед Вами задачу? И как предлагаемая Вами концепция позволила преодолеть эти трудности?
P.S.
Устраиваясь на новую работу, я придумал новый вопрос для собеседования.
Мне кажется, что Вы не в том положении, что бы задавать вопросы. Слушайте, слушайте, и еще раз слушайте. Каждое новое собеседование — это способ обнаружить пробелы в Ваших знаниях.
Но это содержит очевидные минусы: лёгкость совершить опечатку, генерирует повторяющийся код, неудобочитаемость и сложность сопровождения.
Все зависит от опыта. Опытный Си-разработчик напишет так, что все «очевидные минусы» будут отсутствовать. А начинающий — и «простенький класс» реализует с достаточным количеством минусов.
Язык то тут причем? Тут надо что бы руки не под циркуль были заточены (это я конечно грубо, но суть такова).
Совсем недавно были мысли сделать нечто подобное, но все варианты «авторегистрации» с использованием препроцессора не выдержали критики.
Основной аргумент — трудности при отладке. Плюс проблемы с «Go to definition».
Мне показалось это важным, поэтому было принято решение оставить ручную регистрацию.
woooody прав. Для того, что бы говорить о покрытии кода тестами, нужно обязательно уточнять какая именно метрика используется. Если интересно — вот достойное описание различных видов метрик покрытия кода. Но… их тоже нужно применять в зависимости от того, что вы собственно разрабатываете. Вот рекомендации.
а «dotnet new -t web» не проще?
Behave for Python
Большое спасибо.
Я не совсем понял как Вы это делаете.
Если интерфейсная функция принимает указатель на структуру в качестве параметра, Вы просто декларируете это как foo( void * )? Я просто не сталкивался с такой потребностью.
Спасибо.
Меня иногда просто де-мотивируют вопросы коллег-программистов из серии «А зачем так усложнять?».
Опускаются руки.
Если гарантированно, что писатель один, а читателей сколько угодно, то см. «Non-blocking Write Protocol» в Real-Time Systems: Design Principles for Distributed Embedded Applications. Решается одной atomic переменной, как указал HaronK
Формат данных не важен (очередь, стек, и т.п. — просто блок данных)
ПаЦтаЛом :D
Да и в целом, отличная легкая статья. Читается на одном дыхании.
Спасибо.
Как разработчик — согласен на 100%
Но, как правило, это очень дорого. Если предварительно не ограничить скоуп тестирования метриками покрытия кода/требований, то тестирование не закончится никогда.
boldachev, восхищаюсь Вашим терпением, последовательностью в изложении аргументов и целеустремленностью.
Лично мне, как сама статья, так и комментарии ТС, как то:
напоминают старый анекдот:
Развод в Одессе.
Судья:
— Почему Вы с ней хотите развестись?
— Она меня не удовлетворяет.
Голос из зала:
— Подумаешь, пол-Одессы удовлетворяет, а его нет.
Отсюда и вопрос к maxstroy: При разработке каких систем (конкретно, пожалуйста, с примерами) Вы уперлись в принципиальную невозможность решить поставленную перед Вами задачу? И как предлагаемая Вами концепция позволила преодолеть эти трудности?
P.S.
Мне кажется, что Вы не в том положении, что бы задавать вопросы. Слушайте, слушайте, и еще раз слушайте. Каждое новое собеседование — это способ обнаружить пробелы в Ваших знаниях.
Все зависит от опыта. Опытный Си-разработчик напишет так, что все «очевидные минусы» будут отсутствовать. А начинающий — и «простенький класс» реализует с достаточным количеством минусов.
Язык то тут причем? Тут надо что бы руки не под циркуль были заточены (это я конечно грубо, но суть такова).
Каждый инструмент имеет свое назначение.
Основной аргумент — трудности при отладке. Плюс проблемы с «Go to definition».
Мне показалось это важным, поэтому было принято решение оставить ручную регистрацию.
Ведь «запилить» WordPad online — это еще не значит сделать Office, хотя работы тоже предостаточно.