Как измерить качество программного продукта
Здесь вы решаете неправильную проблему.
Ваша актуальная проблема заключается не в сильных слабых ссылках, а в том, как можно улучшить ваше решение. Ваша проблема не в , как достичь , но в , чего вы добиваетесь (хотите достичь) .
Чтобы напрямую задать ваши вопросы в первую очередь:
- "TContainedObject (FObj2) .Free;" немного пахнет, но у меня нет лучшего решения, так как мне нужно использовать интерфейс для ссылки на TObject2 (продуктивный код содержит несколько наследований с этой целью). Любые идеи по его очистке?
Здесь вы не можете многое сделать. Вы должны называть
FreeнаFObj2, потому чтоTContainedObjectне управляемый сам класс.
- вы легко забываете объявить все ссылки между двумя классами как слабые и ..
Здесь вы ничего не можете сделать. Он поставляется с территорией. Если вы хотите использовать ARC, вам нужно подумать о круговых ссылках.
- аналогичная проблема начинает подниматься с большим количеством классов: с TObject3, на который ссылается одна и ссылается на другую: память протечь. Я мог бы справиться с этим, позволив ему спуститься с TContainedObject, но с устаревшим кодом это может быть непростой задачей.
Вы тоже не можете много сделать. Если ваш дизайн действительно то, что вы хотите иметь, тогда вам просто придется иметь дело со своими сложностями.
Теперь вернемся к тому, почему у вас возникают проблемы в первую очередь.
То, что вы хотите достичь (и вы сделали это с вашим примером кода), поддерживает целостность всей иерархии объектов, захватывая любые ссылки на объекты внутри этой иерархии.
Чтобы перефразировать, вы имеете
FormиButtonна нем, и вы хотите сохранитьFormживым, что-то содержитButton(посколькуButtonсам не будет функционировать). Затем вы хотите добавитьEditк этомуFormи снова сохранить все живое, если что-то схватитEdit.У вас здесь мало вариантов.
- Держите этот сломанный дизайн и живите с вашим решением, потому что у вас слишком много кода, и изменения будут болезненными. Если вы это сделаете, имейте в виду, что это в конечном счете сломанный дизайн и не пытайтесь повторить его где-либо еще.
- Если у вас есть иерархия, где
TObject1является корневым классом, который содержит все остальное, то рефакторируйте его и наследоватьTObject2изTInterfacedObject, чтобы иметь свой собственный подсчет ссылок и не захватывать ссылки наFObj2. Вместо этого возьмите экземпляр rootTObject1и передайте это, если вам действительно нужно.- Это вариация второго подхода. Если
TObject1не является корневым классом, создайте дополнительный класс-оболочку, содержащий все экземпляры, которые вам нужны, и передайте их.Последние два решения далеки от совершенства, и они не имеют дело с факт, что у вас, вероятно, есть классы, которые слишком много или похожи. Но как бы ни был плохой код, он даже не приближается к вашему текущему решению. И со временем вы можете медленно менять и улучшать эти решения гораздо проще, чем с помощью вашего текущего.
7 ответов
Я не думаю, что можно когда-либо действительно оценивать количество ошибок в приложении. Если Вы не используете язык и процесс, который позволяет формальные доказательства, Вы никогда не можете действительно быть уверены. Ваше время, вероятно, лучше проведено, настраивая процессы для уменьшения ошибок, чем попытка оценить, сколько Вы имеете.
Одна из самых важных вещей, которые можно сделать, имеют хорошую команду QA и хорошее отслеживание объекта работы. Вы не можете делать полное регрессионное тестирование каждый раз, но если у Вас есть список изменений, Вы сделали к приложению начиная с последнего выпуска, затем Ваши люди QA (или человек) могут сфокусировать свое тестирование на частях приложения, которые, как ожидают, будут затронуты.
Другой вещью, которая была бы полезна, являются модульные тесты. Чем больше Вашей кодовой базы Вы покрыли, тем более уверены можно быть, что изменения в одной области не сделали непреднамеренно влиял на другую область. Я нашел это довольно полезным, поскольку иногда я изменю что-то и забуду, что это влияло бы на другую часть приложения, и модульные тесты показали проблему сразу же. Переданные модульные тесты не гарантируют, что Вы ничего не повредили, но они могут помочь увеличить уверенность, которая изменяется, Вы делаете, работают.
Кроме того, это немного избыточно и очевидно, но удостоверьтесь, что у Вас есть хорошее программное обеспечение отслеживания ошибок.:)
Вопрос состоит в том, кто требует, чтобы Вы предоставили статистику.
Если это - нетехнические люди, фальсифицируйте статистику. "Фальшивкой" я имею в виду, "предоставляют любому неизбежно бессмысленные, но вещественные числа" вида, который Вы упомянули.
Если это - технические люди без фона CS, им нужно сказать о проблеме остановки, которая неразрешима и более проста, чем подсчет и классификация остающихся ошибок.
Существует много метрик и инструментов относительно качества программного обеспечения (покрытие кода, цикломатическая сложность, кодируя инструкции и инструменты, осуществляющие их, и т.д.). На практике, какие работы автоматизируют как можно больше тесты, имеющие тестеры - люди делают как можно больше тестов, которые не были автоматизированы и затем молятся.
Я думаю, сохраняя это простым, лучший способ пойти. Категоризируйте свои ошибки серьезностью и обратитесь к ним в порядке уменьшающейся серьезности.
Таким образом, можно передать возможную сборку высшего качества (количество значительных остающихся ошибок - то, как я измерил бы качество продукта, в противоположность некоторой сложной статистике).
Большинство гибких методологий обращается к этой дилемме довольно ясно. Вы не можете протестировать все. И при этом Вы не можете протестировать его бесконечное количество раз перед выпуском. Таким образом, процедура должна полагаться на риск и вероятность ошибки. Оба риска и вероятность являются численными значениями. Продукт обоих дает Вам число RPN. Если число - меньше чем 15, Вы поставляете бету. Если можно понизить его меньше чем до 10, Вы поставляете продукт и продвигаете ошибку быть зафиксированной в будущем принимающем права лице.
Как вычислить риск?
Если это - катастрофический отказ затем, это - 5, Если это - катастрофический отказ, но можно обеспечить работу вокруг затем, это - число меньше чем 5. Если ошибка уменьшает функциональность затем, это - 4
Как вычислить вероятность?
можно ли воспроизвести его каждый раз, когда Вы работаете, это - 5. Если работа вокруг обеспеченного все еще заставляет это разрушать затем меньше чем 5
Ну, мне любопытно знать ли кто-либо еще использующий эту схему и стремящийся знать их milage на этом.
Какой длины часть строки? В конечном счете, что делает качественный продукт? Ошибки дают некоторый признак да, но много других факторов включены, покрытие Модульного теста является ключевым фактором в IMO. Но по моему опыту основным фактором, что эффекты, можно ли продукт считать качеством или нет, является хорошее понимание проблемы, которая решается. Часто то, что происходит, 'проблема', которую продукт предназначен для решения, не понята правильно, и разработчики заканчивают тем, что изобрели решение проблемы, которую они имеют, излагают в деталях в их голове а не настоящей проблеме, таким образом 'ошибки' сделаны. Я - убежденный сторонник повторяющейся Гибкой разработки, тот способ, которым продуктом постоянно является доступ против 'проблемы', и продукт не отклоняется к далеко от его цели.
Вопросы я слышал wer, как я оцениваю ошибки в своем программном обеспечении? и что методы я использую, чтобы гарантировать, что качество хорошо?
Вместо того, чтобы проходить полный курс, вот, пара подходов.
Как я оцениваю ошибки в своем программном обеспечении?
Запустите с истории, Вы знаете, сколько Вы нашли во время тестирования (надо надеяться), и Вы знаете, сколько было найдено после факта. Можно использовать это, чтобы оценить, насколько эффективный Вы при нахождении ошибок (DDR - Дефектный Процент раскрытых преступлений является одним названием этого). Если можно показать, что в течение некоторого последовательного периода времени, DDR последователен (или улучшающийся), можно обеспечить некоторое понимание качества выпуска путем предположения количества дефектов после выхода, которые будут найдены, после того как продукт выпущен.
Какие методы я использую, чтобы гарантировать, что качество хорошо?
Анализ первопричины Ваших ошибок укажет на Вас на определенные компоненты, которые являются ошибочными, определенными разработчиками, которые создают содержащий ошибки код, то, что недостаток в полных требованиях приводит к реализации, не соответствующей ожиданиям и т.д.
Обзорные совещания проекта для быстрой идентификации, что было хорошо, таким образом, те вещи могут быть повторены и что было плохо и находит способ не сделать их снова.
Хотелось бы надеяться, они дают Вам хорошее начало.Удачи!
Кажется, что согласие состоит в том, что акцент должен быть сделан поблочному тестированию. Отслеживание ошибок является хорошим индикатором качества продуктов, но, только точно как Ваша тестовая команда. При использовании поблочного тестирования, оно дает Вам измеримую метрику покрытия кода и обеспечивает регрессионное тестирование, таким образом, Вас можно уверить, что Вы ничего не повредили с прошлого месяца.
Моя компания полагается на тестирование системы/степени интеграции. Я вижу много дефектов, представляемых, потому что существует отсутствие регрессионного тестирования. Я думаю "ошибки", где реализация разработчиком требований отклоняется от видения пользователя, вид отдельной проблемы, которая как Dan и указанный rptony лучше всего решается Гибкими методологиями.