Я перескакиваю в пересказе на несколько глав вперед. Одно время, я забросила конспектирование, и только отмечала в книге интересные места. так вот, я добралась до главы, которая меня очень взволновала. И хочу ее не только запомнить, но и переосмыслить.
Итак, Макконнелл перечисляет некоторые из характеристик качества ПО, внешние:
Самое прикольное, что в этом списке есть требования, прямо противоречащие друг другу. Т.е. общего понятия качественного ПО не существует. Нужно для каждого проекта искать те характеристики качества, которым он должен удовлетворять. Автор даже предлагает таблицу, которая показывает, как разные показатели качества взаимодействуют между собой.
Контроль качества ПО - это планомерная и систематическая программа действий, призванная гарантировать, что система обладает желаемыми характеристиками.
Одна из эффективных методик повышения качества ПО - явное определение целевых внешних и внутренних характеристик. Контроль качества должен быть явным. Тестирование лишь один аспект контроля качества. Качество ПО повышается и от неформальных, и от формальных обзоров кода.
Макконелл привел таблицу эффективности обнаружения дефектов. Выводы из этой таблицы меня поразили. Я давно читала книгу про разработку через тестирование, и была уверена, что если бы могла легко протестировать автоматически визуальную часть приложения, в ней было бы меньше ошибок. Но оказалось, что блочное тестирование дает шанс выявить в среднем 30% ошибок. И что самыми хорошими результатами обладали формальные инспекции кода, моделирование, формальные инспекции проекта. По эффективности их обошло только масштабное (более чем в 1000 организаций) бета-тестирование. Вот так вот интересно.
Разные программисты находят разные дефекты - меня все время это удивляло на работе. Как так получалось, что у меня программа работает замечательно, а как только ею пользовался кто-то другой она выдавала ошибки.
Чтение кода способствует нахождению дефектов интерфейса, а функциональное тестирование - нахождению дефектов управляющих структур. Интересно. Но эту вещь я не проверяла.
Методики поиска дефектов лучше применять в комбинации. Одни методики помогут обнаружить одни дефекты, а другие - еще некоторые.
Я задумалась, почему мои институтские программы были хуже, чем рабочие. Скорее всего, дело было не только в том, что на учебу я тратила меньше времени. А еще и в том, что учебный код у меня никто не смотрел. И соответственно, внутри там было все хуже, чем в рабочем коде.
Итак, Макконнелл перечисляет некоторые из характеристик качества ПО, внешние:
- корректность;
- практичность;
- эффективность;
- надежность;
- целостность;
- адаптируемость;
- правильность;
- живучесть.
- удобство сопровождения;
- гибкость;
- портируемость;
- возможность повторного использования;
- удобочитаемость;
- тестируемость;
- понятность.
Самое прикольное, что в этом списке есть требования, прямо противоречащие друг другу. Т.е. общего понятия качественного ПО не существует. Нужно для каждого проекта искать те характеристики качества, которым он должен удовлетворять. Автор даже предлагает таблицу, которая показывает, как разные показатели качества взаимодействуют между собой.
Контроль качества ПО - это планомерная и систематическая программа действий, призванная гарантировать, что система обладает желаемыми характеристиками.
Одна из эффективных методик повышения качества ПО - явное определение целевых внешних и внутренних характеристик. Контроль качества должен быть явным. Тестирование лишь один аспект контроля качества. Качество ПО повышается и от неформальных, и от формальных обзоров кода.
Макконелл привел таблицу эффективности обнаружения дефектов. Выводы из этой таблицы меня поразили. Я давно читала книгу про разработку через тестирование, и была уверена, что если бы могла легко протестировать автоматически визуальную часть приложения, в ней было бы меньше ошибок. Но оказалось, что блочное тестирование дает шанс выявить в среднем 30% ошибок. И что самыми хорошими результатами обладали формальные инспекции кода, моделирование, формальные инспекции проекта. По эффективности их обошло только масштабное (более чем в 1000 организаций) бета-тестирование. Вот так вот интересно.
Разные программисты находят разные дефекты - меня все время это удивляло на работе. Как так получалось, что у меня программа работает замечательно, а как только ею пользовался кто-то другой она выдавала ошибки.
Чтение кода способствует нахождению дефектов интерфейса, а функциональное тестирование - нахождению дефектов управляющих структур. Интересно. Но эту вещь я не проверяла.
Методики поиска дефектов лучше применять в комбинации. Одни методики помогут обнаружить одни дефекты, а другие - еще некоторые.
Я задумалась, почему мои институтские программы были хуже, чем рабочие. Скорее всего, дело было не только в том, что на учебу я тратила меньше времени. А еще и в том, что учебный код у меня никто не смотрел. И соответственно, внутри там было все хуже, чем в рабочем коде.
Комментариев нет:
Отправить комментарий