А есть ли "баги" вообще? Не в каком-то конкретном приложении, а существуют ли они в принципе как самостоятельный отдельный элемент в процессе разработки и сопровождения программ?
Сейчас я склоняюсь к мысли что "баги" - это просто основательно прижившееся слово для обозначения некоторых ситуаций в сопровождении программ. Причем про какие-то ситуации говорят "это баг", а про какие-то очень похожие почему-то не говорят...
Со стороны пользователя в программа либо помогает в решении его задач, либо не помогает и пользователь либо использует ее либо не использует. Или имеет место некоторое промежуточное состояние, когда программа помогает, но не всегда и не в любых задачах. Такая ситуация порождает трафик отзывов о программе от пользователя к разработчику: клиент не чувствует себя счастливым с этой программой, однако отказ от использования программы еще больше ухудшит ситуацию. Или клиент просто "чует", что программа может лучше/больше помогать ему в работе и пытается донести эту возможность до разработчика.
Вот в этом трафике и применяется ярлык "это баг". Но на самом деле является ли конкретная ситуация "багом" или нет не имеет значения. Имеет значение только взаимовыгодное сотрудничество пользователя и разработчика программы: пользователь хочет сократить свои расходы или даже получать прибыль при использования программы, а разработчик просто хочет что-то кушать, где-то жить, кормить семью, оплачивать ипотеку и кредит на машину.
Программы обычно довольно сложны и имеют огромное количество сценариев использования, при этом очень большая часть этого теоретического множества сценариев может быть вообще не рассмотрена разработчиком и не востребована пользователем. Или очень редко востребована. Или не принципиальна.
С другой стороны, некоторая часть сценариев может быть очень важна для пользователя, но также и очень сложна в технической реализации. Или реализация не будет адекватно работать на современном уровне технического оборудования. Для разработчика такая работа означает сокращение прибыли за единицу его физического времени, ведь на создание этого кода уйдет очень много времени, в программе почти ничего не изенится для большой части клиентов, а у него семья/ипотека/кредит и разработчик может начать поиски других источников доходов.
У пользователя точно такая же ситуация с семьей/кредитом/ипотекой, только надежды свои он возлагает на программу: она позволит ему заработать больше, поэтому ему очень важно добавление функционала ХХХ, расширение УУУ и особенно работа функционала NNN именно таким образом как ему требуется. И пользователь начинает писать "баги"...
У пользователя точно такая же ситуация с семьей/кредитом/ипотекой, только надежды свои он возлагает на программу: она позволит ему заработать больше, поэтому ему очень важно добавление функционала ХХХ, расширение УУУ и особенно работа функционала NNN именно таким образом как ему требуется. И пользователь начинает писать "баги"...
Вот таким естественным образом и регулируется существование сотрудничества: из трафика отзывов разработчик выделяет наиболее важные для клиентов различия между ожиданиями от программы и ее фактическими возможностями и вносит изменения для устранения различий. Т.е. пока обеим сторонам это выгодно.
При таком раскладе возможна ситуация, когда по программе обнаружено (пользователями, разработчиками и внутренним отделом тестирования) много "явно неправильно" работающих сценариев и зарегистрировано множество "багов". Такой процесс работы можно описать используя слово "задача" вместо слова "баг" и работать над ними в определенном порядке (важность/срочность/сложность/количество пользователей и др).
Комментариев нет:
Отправить комментарий