Работая в сфере ИТ, волей-неволей замечаешь огромное количество ошибок в различном программном обеспечении. Будь то ошибки мировых вендоров Microsoft, или же в прикладных бизнес-решениях фирмы 1С, или же в хваленных Apple с детской фатальной ошибкой "1 января 1970". Что уж говорить про небольшие компании с небольшим штатом программистов?
Насколько ошибки в ПО являются естественным процессом? Давайте разберёмся. Всё ниже является исключительно авторским мнением, в том числе классификация, возможность применения теории конечного автомата, наблюдения.
Не так давно Samsung заявил о запуске сервиса Samsung Pay, а наличие у меня часов Samsung Gear 3 открывало мне новое баловство — оплачивать покупки прикосновением часов к терминалу. Не знаю какие трудности произошли при производстве продукта, но первые версии программы мне не позволяли произвести настройку. Лишь с выпуском нескольких релизов я смог использовать сервис.
Все производители делают ошибки в области программного обеспечения, какими бы они крупными и сертифицированными не были.
Умственный труд программистов постоянно требует нововведений. Они должны применять современные технологии для того, чтобы обеспечить бизнес-идею инвесторов и мечтателей. Информация и технологии очень быстро устаревают и поэтому программисту требуется быть на передовой, словно первопроходцу-исследователю преодолевать заросли в тайге, засушливые пустыни, ледяные торосы.
Сколько полегло исследователей в попытке пройти сложные маршруты: Г. Седов, Р. Скотт, В. Беринг... О чём это я?
Программист работает с новыми, не проторенными технологиями, в которых легко делать ошибки. Баги есть как в поставляемых модулях внешних разработчиков, так и в их применении в собственном ПО.
Ошибки и Теория конечного автомата
Давайте обратимся к теории конечного автомата. В своё время в институте приходилось применять данную методику как в программировании контроллеров, так и в построении систем управления.
Но что, если на базе теории показать сложность программной разработки и легкость возникновение ошибок. Например, постановка прикладной задачи — реализовать автоматический переход к статусам в заказе покупателя.
Представим стандартный граф конечного автомата производственного предприятия с состояниями:
- Расчет
- К производству
- В производстве
- Готово
- Завершён
События конечного автомата:
- a — устанавливается менеджером после подтверждения покупателем;
- b — устанавливается начальником производства, оценив производственные мощности и возможность выполнения;
- c — устанавливается работником склада в момент поступления на склад;
- d — устанавливается менеджером при поступлении денег и передачи груза;
- e — устанавливается менеджером вручную.
Описан тривиальный процесс. В конкурентной борьбе необходимо применять все современные возможности и, конечно, отправка смс заказчику была бы неплохим плюсом, а, возможно, уже и обязанностью. А как вы помните, изначальная задача — автоматизировать процесс. Например, грузчик принимает с помощью сканера штрихкода выпускаемый товар, а система шлёт sms покупателю: «Готово, приезжайте».
Это обычная задача, но для проектировщика здесь скрыто много нюансов. Например, произвели продукцию, а часть оказалось браком. Какое состояние должно быть? Учли? Заказчик приехал покупать, но при осмотре решил отказаться от части продукции - завершён или отменён? По ошибке отменили заказ, а надо вернуть в производство.
Мы не рассматриваем сложные примеры, когда может быть сборный груз, множество мест хранения и много состояний, но и в данной простой задаче многие проектировщики ПО допускают ошибки. Любая автоматизация требует аналитического подхода — прорабатывать переходы, о которых постановщик задачи не догадывается. В реальной жизни предприятия для приведенного выше процесса количество переходов гораздо больше.
Чем функциональнее ПО, тем больше ошибок. Тестировщик помогает, но не всегда — он не знаком с предметной областью так, как проектировщик.
Я для себя определил, что построение графа статусов на базе теории конечного автомата позволяет объемно взглянуть на решаемую задачу.
Помню, ко мне обратился Финансовый директор с просьбой разработать систему депремирования сотрудников. Учет поручений всех сотрудников вёлся в 1С: Документооборот (ДО), учёт рабочего времени в 1С: Управление производственным предприятием (УПП). Если сотрудник просрочил важную задачу, то его лишали премии на Х%. Для этого сверяем время завершения задачи в ДО, получаем данные сотрудника по табелю за период из УПП и определяем место запятой в «казнить нельзя помиловать».
Хорошо, но количество переходов между состояниями (согласно теории ограничения систем) возросло настолько, что пришлось ответить на десятки внеплановых сценариев, по которым система депремирования становится нерабочей. Например:
Соблазн введения такой системы был велик, ведь чем больше отожмёт зарплаты у сотрудников, тем лучше он купит машину себе на Новогодние праздники по результатам года. Поэтому для реализации этой задачи были сделаны десятки доработок 1С с учётом всех переходов.
Процедура тестирования программного обеспечения давно отлажена и стандартизирована. Но массовые продукты всё равно постоянно выпускают релизы с исправлением ошибок. Примеры:
- WordPress
- 1С: Комплексная автоматизация 2
Можно ли выпустить Функциональное ПО без ошибок? Нет, таких случаев не наблюдалось.
Связь экономики и технических знаний в области ошибок
Можно ли минимизировать ошибки? Однозначно. Их количество нелинейно снижается соответственно затраченному времени на их поиск и устранение. Время означает затраты. Существует 2 причины поекращения поиска ошибок — потеря экономического эффекта на дальнейший поиск и потеря технических знаний на их устранение.
Идеально, когда они располагаются рядом на оси «требуемых ресурсов». Это означает гармонию между экономической моделью вашего бизнеса и качеством выпускаемого вами ПО.
Например, стоит задача разработать программное обеспечение для бортового компьютера нового самолёта. Учитывая колоссальное количество параметров и функций в физике полёта нельзя допустить остановку отладки ПО из-за потери финансирования. Результат будет печальный.
Если значительно раньше наступает точка «потери технических знаний», значит требуется повышать стандарты качества и профессионализм разработчиков.
При всём при этом останутся «ошибки-ниндзя», которые скроются от всех тестов и обнаружатся лишь пользователями.
Вес ошибок
Вес каждой ошибки разный. В целом, я делю их на 4 вида.
Критическая ошибка. Останавливает работу бизнеса (для учетных систем), оборудования, сервиса. Таких ошибок быть не должно. Присутствие таких «багов» говорит о слабой технической стороне разработчика (в том числе, методов тестирования).
Например, я скачал активно продвигаемую программу в Google Play Маркет. Сразу при запуске произошла ошибка.
Важная непреодолимая ошибка
Это не останавливает работу, но приводит к неточному результату, который невозможно поправить пользователем вручную.
Я проложил маршрут в г. Подольск. На одном участке навигатор проложил очень странный маршрут (пробки он не объезжает, ремонта и перекрытия дороги нет). Эта ошибка не критична и я могу продолжать использовать программу, но внести изменения нет.
Важная преодолимая ошибка
Например, расчёт себестоимости в бизнесе крайне важен, но сложен в силу решения многомерной системы уравнений с множеством неизвестных. Происходят ошибки, в том числе, как и писалось выше, в поставляемых модулях вендоров.
Расчет себестоимости даёт только конечный результат, который строится на череде предыдущих расчетов, и если на какой-то итерации произошла ошибка, то итог будет неправильный.
В программе 1С выводилась такая ошибка расчета себестоимости. Пользователь мог (естественно, путём экспериментов) её устранить — перепровести документы. В заявленных возможностях метода РАУЗ это не надо делать, но не на практике.
Замечания
Это всё остальное. Например, приходит мне сообщение от Добродела, а ссылка неработающая. Сразу видно что тестирование не проводилось.
Анализ своих ошибок в качестве резюме
Вспоминая все свои ошибки в качестве программиста и руководителя проекта, могу выделить следующие причины их появления:
- Проблема сказанного и услышанного. Как помните проекции цилиндра, где одна круг, а другая прямоугольник. В итоге говорим про одно требование, а понимаем по-разному.
- Ограничение глубины мышления. У каждого человека есть свой уровень и если дальнейшее углубление не формализовывать (не делать заметки на листке или в коде программы), то можно попасть на функциональный разрыв.
- Не придание важности элементу кода. Написал, и даже не сомневался, что это неправильно. В лучшем случае, это выливается в неоптимальный код.
- Неполное знание средств разработки функций. Нас хоть и учили, что задача инженера работать со справочной документацией, но опыт помогает минимизировать общение с книгой.
