Это не баг, это — фича! Или все-таки баг?

Неработающая программа обычно приносит меньше вреда, чем та, что работает плохо. (с) Дейв Томас, автор книг о программировании и тестировании ПО

В предыдущем посте затронул тему ошибок в пользовательском интерфейсе. А сегодня разберемся, какие еще факапы возникают при разработке программ, и что с ними делать. В частности, речь пойдет об 1С. Пост без сложных терминов — для тех, кто не очень в теме.

Забавное наблюдение в стиле «спасибо, Кэп»: если программа работает корректно, никто не акцентирует на этом внимание. А зачем? Она ведь так и должна работать. Другое дело, если возникают ошибки! Это сразу всех расстраивает выводит из себя.

Ошибки можно разделить на явные и неявные.

📍 Явные бесят пользователей больше всего. Это когда программа вылетает, появляются непонятные сообщения. В общем, добавьте сюда все, что мешает работать. Я такие ошибки называю «хорошими», потому что их сразу видно. Программа вылетела с сообщением: «проблема в девятой строке кода»? Так это замечательно – мы уже знаем, где искать, значит, быстро пофиксим. Нажимаете кнопку, а ничего не происходит? Тоже неплохо, надо «ткнуть носом» спеца, он все исправит (но это не точно).

📍С неявными все сложнее. Программа, на первый взгляд, работает четко, но делает не то, что нужно. Еще хуже, если она иногда делает не то, что нужно, а чаще работает нормально. То есть, обычно 2+2 = 4, а потом раз — и внезапно 5! Это так называемые «плавающие» ошибки. Очень неприятные, поверьте. Стоит только ослабить контроль...

Древняя мудрость гласит: не бывает программ без ошибок, бывает мало тестирования. Что надо делать?
❗ Тестировать программисту при разработке.
❗ Тестировать при приемке (это должен сделать постановщик задач).
❗ Тестировать тестировщику (хотя во вселенной 1С тестировщики — это экзотика).
❗ Выполнять автоматическое тестирование. Это целая отрасль знаний, но во вселенной 1С применяется редко (знаю, тут есть несколько мнений: если не согласны с моим, приглашаю в комментарии).
‼ Бонусом — совет пользователям, которые начинают работать с новым функционалом: относитесь к нему с подозрением. 🙂

Кстати, есть еще одна ошибка, которая багом не считается. Она, пожалуй, самая неприятная. Это когда вы разработали замечательную программу с красивым и удобным интерфейсом. И работает она как надо. Но… это не та программа. ☹️

Как такое получается?
– Постановщик задачи берет на себя роль архитектора, хотя не обладает компетенциями. Об этом писал здесь.
– Участники проекта не коммуницируют. Постановщик описал задачу, а разработчик что-то неправильно понял. Или постановщик о чем-то не сказал, а разработчик, вместо того чтобы уточнить, додумал сам (и сделал неправильно).

Что делать?
– Больше общаться в команде. Есть новое ТЗ? Пусть тот, кто его написал, и тот, кто будет по нему работать, обсудят все детали.
– Устраивать демонстрации промежуточных результатов. Так можно заметить, что программист делает что-то не то, прежде чем станет слишком поздно.

А у вас есть уникальные методы создания софта без багов? Поделитесь в комментариях! И не забывайте о реакциях: так я пойму, что контент интересен.

#мнение_о_важном