В программном обеспечении мы много говорим об ошибках. Откуда они берутся, как их избежать, как с ними бороться и т.д. это хорошо, но что на самом деле является ошибкой?
Я видел проекты, в которых было более сотни ошибок, каждая из которых хорошо документировалась и отслеживалась, но код все равно работал. Вчера я написал ошибку, из-за которой целый класс устройств перестал взаимодействовать с сервером. Как получилось, что сущности в обоих этих сценариях получили одинаковый ярлык?
Насколько они действительно похожи? Если вы говорите, что у задней двери сидит рептилия, и при этом имеете в виду загорающую игуану или велоцираптора, возившегося с дверной ручкой, вы действительно сказали что-то полезное?
То есть, конечно, может быть, таксономически эти существа похожи. Но это ничего не говорит нам о том, как мы должны действовать в ответ. Программная инженерия - это все о действиях. Мы пытаемся создавать продукты. Любые определения, которые мы используем, должны помогать нам в достижении этой цели.
Конечно, никто никогда не говорит о рептилиях. Биология предоставляет гораздо более конкретные пласты классификации. Дамы и господа, мы подошли к тезисному утверждению: Нам нужна более конкретная классификация программных ошибок, чтобы обрабатывать их должным образом.
Далее следует предложение о разделении ошибок на три категории и о том, как с ними работать.
Катастрофы
Катастрофы - это самые простые ошибки, о которых можно говорить и идентифицировать. Они определяются следующим образом: "Ошибка, из-за которой вы не можете выпустить следующий релиз вашего программного обеспечения".
Если вы обнаружите такую ошибку, развернутую в производстве, это обычно означает специальный релиз для ее исправления. Это все еще широкая категория, и она сильно зависит от типа системы, которую вы создаете.
Это может быть уязвимость в системе безопасности, неработающая основная функция, кнопки, которые на новом iPhone наполовину отходят от экрана, проблема пользовательского интерфейса, которая доводит ваших клиентов до психоза, и т.д. и т.п.
С катастрофами нужно бороться сейчас. Если устранение проблемы займет всего несколько часов, и вы не можете отправить продукт, не устранив ее, то нет причин не позаботиться о ней сейчас, пока она свежа в памяти.
Если вы не знаете, сколько времени займет исправление, вы должны работать над ним сейчас. Если вы не можете сказать, сколько времени займет исправление ошибки, а она должна быть исправлена до релиза, то вы не в состоянии даже сделать какую-либо оценку времени, когда вы сможете отправить следующую версию.
Вы уже утонули. Мертвые не работают над новыми функциями, они должны сначала пробить себе путь обратно на землю живых.
Придирки или Трещины
"Придирки " можно определить как "небольшие недостатки в вашем программном обеспечении, с которыми вы могли бы легко справиться".
Может быть, кнопка на передней панели веб-страницы не совсем правильно расположена на самом маленьком поддерживаемом размере экрана, может быть, вы можете ввести отрицательное число в поле, которое должно быть проверено на диапазон (предполагая, что это безвредно), число отображается с двумя десятичными знаками, когда второй десятичный знак может быть только нулевым, может быть, анимация запускается с опозданием в странных и редких обстоятельствах, и т.д., и т.п.
Придирки вредят общему виду и ощущению вашего продукта. Если их слишком много, они могут даже помешать загрузке страницы. Люди не доверяют программному обеспечению, которое "кажется" сломанным. Но этот класс ошибок может помешать поставке ПО только в совокупности.
Вы должны стараться поддерживать количество ошибок на низком уровне. Если их легко исправить, исправьте их, когда вы работаете в этой области кода по другим причинам. Если работа над проблемой без создания уникальной ветки противоречит политике вашей компании, нарушайте эту политику, пока кто-нибудь не скажет вам остановиться. Скорее всего, этого никогда не произойдет.
Если в вашей компании есть команда QA, то ваш бэклог наверняка полон недоработок. QA-команды считают, что их работа заключается в поиске ошибок. Это не их работа. Их работа такая же, как и ваша, - продавать продукт.
Вы можете простить им их замешательство, ведь у вас сложилось впечатление, что ваша работа заключается в написании кода. Но то, что QA находит недочеты, не является настоящей проблемой. Вы хотите знать о них, когда в удобное время вы должны искать способы их устранения. Проблема заключается в соотношении сигнал/шум.
Если QA заполняет вашу программу отслеживания проблем множеством придирок и несколькими катастрофическими ошибками, то вскоре оба класса начинают игнорироваться. Придирки следует определять отдельно от ошибок, иначе они могут больше мешать разработке, чем поддерживать ее.
Грибки
Когда мы переходим к третьей категории, вы можете найти повод обвинить меня в том, что я заново изобрел технический долг. И конечно, между техническим долгом и грибком есть много общего.
Я пытаюсь создать новую таксономию ошибок программного обеспечения. Некоторое повторение необходимо. Кроме того, я не хочу повторно использовать термин "технический долг". У него слишком большой багаж и слишком много слогов. Термины Грибок и Придирка ДОЛЖНЫ иметь меньше слогов, чем Катастрофа.
Грибок - это любой дефект в вашем коде, который будет расти со временем. Вы наверняка слышали: "Чем дольше мы ждем, тем сложнее будет исправить". Возможно, вы даже говорили это. Обратите внимание, что грибок никогда не может быть катастрофой. Грибок может быть или не быть придиркой. В результате мы получаем следующую схему:
Грибок не может быть Катастрофой, потому что с Катастрофами нужно бороться сейчас. У них не будет шанса вырасти в проблему. Придирки, конечно, могут быть грибком, потому что их легче исправить сейчас, чем потом. В некоторых обстоятельствах грибок не будет указывать на какие-либо видимые дефекты в вашем коде.
Если модуль кода трудно изменить, и вы ожидаете, что он будет меняться на протяжении всех итераций вашего программного обеспечения: это грибок. Одним из худших видов грибка являются архитектурные нарушения.
Нарушения архитектуры появляются всякий раз, когда вы можете реализовать функцию неправильно за десять минут, но можете реализовать ее правильно за неделю. Достаточно часто выбирать короткий путь, и вы можете столкнуться с таким количеством странных случаев и пересечений коммуникаций, что некоторые области вашей кодовой базы станут неработоспособными.
Нарушения архитектуры - одна из реальных причин, по которым компании со временем увязают в работе. Я напишу о них подробнее в будущем. В целом, "грибок" должен иметь более высокий приоритет, чем "придирки".
Если только Придирки не настолько многочисленны, что вы не можете осуществлять отгрузки, экономически выгоднее решать растущие, а не статичные проблемы. Как и в случае с Придиркой, вы можете допустить немного Грибков в ваш код.
Если это означает соблюдение сроков, которые приводят к недостижимым иначе продажам, это может иметь смысл в краткосрочной перспективе. Но "грибок" всегда рискован, даже если вы считаете, что срок службы вашего программного обеспечения подходит к концу. Этот мир усеян кодом, который люди считали отправленным на пенсию еще двадцать лет назад.
Заключение
В своей реклассификации я теперь разложил "баг" на три более полезные категории. Название этой статьи задает вопрос: Что такое баг? Мой ответ: Не стоит говорить об этом. Вот краткое описание новых категорий, о которых стоит поговорить.
- Катастрофы останавливают поставку программного обеспечения. Их нужно решать немедленно.
- Грибок - это любая проблема, которая растет с течением времени. С грибком следует бороться как можно скорее, он представляет собой средне- и долгосрочный риск для вашей кодовой базы.
- Придирки - это небольшие недостатки, которые влияют на качество программного обеспечения. Вы должны стараться сократить их количество и решать их оппортунистически. Если вы когда-либо обнаружите, что вы или ваша команда отводите определенный спринт или цикл разработки для решения придиркок, значит, вы слишком пассивны по отношению к ним.
Если ваша реакция на это - сказать: "Вообще-то ученые считают, что велоцирапторы были больше похожи на птиц, чем на рептилий". Знайте, что я отношусь к вам с презрением.
Автор: Marcus Haberling