Web разворачивается большими темпами. И на этом фоне число Web-разработчиков (как частников, так и компаний), так же стремительно растет. Однако при этом слишком мало внимания уделяется качеству разработки Web-систем. Почему-то считается, что почитать книжку по Web-программированию и полистать форум вполне достаточно для написания Web-системы. Как результат: ошибки в коде, дыры в безопасности, взломы, потери данных и т.д. Уж сколько раз твердили миру… но нет. Вот один из последних (но достаточно типичный) пример некачественного программирования.

Одна компания обратилась с жалобой, что на сайте заказов ночью (в 2-4 часов) удаляются несколько заказов. Проблему компания полностью возложила на службу поддержки и резервирования БД, поскольку у них «все коды много раз проверенные и выверенные».

Для подтверждения своих слов, компания создала тестовую таблицу (идентичную заказам), в которую дублировала все заказы, сделанные с сайта. И действительно, на следующее утро, в реальной таблице отсутствовало несколько заказов, имеющихся в дублирующей таблице. Интересно было в том, что удалены были не все заказы, а только некоторые из них.

При разборе web-логов и быстрого ознакомления с программными текстами очевидных «нестандартностей» выявлено не было. Ни каких cron-заданий не выполнялось, ни какой вредоносной активности замечено не было. По ночам делалась резервная копия БД, поэтому был проверен вариант возможных сбоев при резервировании. Однако никаких нарушений при резервировании БД не было выявлено. Но чудес не бывает, и некоторые ночные заказы действительно удалялись и компания теряла их (что их очень раздражало).

После более тщательного и детального изучения программной части системы заказов, были найдены ошибки (логические) в программных тестах. Взаимодействие в административной части проекта было построено через ряд GET-переменных: menu и submenu, первое из которых определяло функционал подсистемы (например, заказы), второй действие с ним (например, изменить или просмотреть).

if (isset($_GET[‘menu’])) {
$current = (int)$_GET[‘menu’];
} else {
$current = 2;
$_GET[‘menu’] = $current;
}

затем в программе оператором include_once включался файл «contents.php», где:

if (isset($_GET[‘menu’])) {
$menu = (int)$_GET[‘menu’];
} else {
$menu = 1;
}
if (isset($_GET[‘submenu’])) {
$current = (int)$_GET[‘submenu’];
} else {
$current = 1;
}

и далее в зависимости от переменных $menu и $current выполнялись необходимые действия. Нас интересовали (именно они были «выужены» из логов) menu == 31 и submenu ($current) == 2:

} else if($menu == 31){
if($current == 1) include_once «funcs/add_order.php»;
if($current == 2) include_once «funcs/edit_order.php»;
if($current == 3) include_once «funcs/view_order.php»;
if($current == 4) include_once «funcs/del_order.php»;
} else if ($menu == 32) {

Надо заменить, что заказ реально мог быть удален только из одного файла — funcs/del_order.php. Ни в каких других программных файлах удаления не было (и не могло быть). Что и вызывало недоумение, поскольку по процедурной логике в нашем случае включался файл funcs/edit_order.php ! Однако сразу насторожило использование конструкций if/if/if, вместо if/elseif/elseif, и прямое включение из них других файлов. Поэтому, внимательно изучив файл funcs/edit_order.php выяснилось наличие в нем следующего кода:

$current = (int)(date(«H») + 2);

что сразу расставило всё на свои места. Получалось, что при включении файла funcs/edit_order.php изменялась переменная $current. А поскольку все выполнялось не в локальном контексте, а в глобальном контексте, то это вызывало последующую проверку других if условий и, возможно, включение других файлов. Если административный скрипт выполнялся с 2 до 3 часов ночи, то переменная $current принимала значение равное 4, что приводило к включению файла funcs/del_order.php, который в свою очередь просто удалял заказ из системы.

Таким образом выяснилось, что халатность и некачественное программирование при разработке привело к потере реальных заказов и фактически реальных доходов. И виновата в этом точно не БД и ее сопровождение. Уж сколько раз твердили миру…

2 комментария

  • «число Web-разработчиков (как частников, так и компаний), так же стремительно растет. Однако при этом слишком мало внимания уделяется качеству разработки Web-систем. Почему-то считается, что почитать книжку по Web-программированию и полистать форум вполне достаточно для написания Web-системы. Как результат: ошибки в коде, дыры в безопасности, взломы, потери данных и т.д.»

    отличный пример приведен, но впрочем, хотелось бы о другом немного речь затронуть.
    а можем ли мы говорить что существует реальная проблема с образованием веб-разработчиков?!
    Или же, внимательности в работе, усердия, а может даже злоупотребления спиртными напитками 😉

    Где, вы считаете, должны обучать таковых специалистов?! Проблема личной ответственности человека, я считаю.
    И главное быть специалистом В СВОЕМ деле, и не важно, где и кем научен.

  • эпохальный специалист, мое мнение, не важно где обучаться. Проблема с образованием разработчиков создается (как это не странно) самими заказчиками, стремящимися всеми силами сэкономить на разработке. Отсюда и дальнейшие проблемы. В Инете это особенно ощутимо и распространено. Бесплатного сыра нет, не было и не будет. Поэтому заказчик добровольно выбирает такой путь, а уже потом начинает «крутиться» в проблемах. А таким разработчикам нет смысла развиваться, если и так есть спрос на их услуги.

Комментарии закрыты