Об обфускации и вообще ее применимости и опасности вуду колдовства

belnetmon — 11.07.2012

Хотелось бы обсудить то, что использует у себя в проектах уважаемый maxdz, а именно обработки структуры базы данных специальным механизмом, который определенным образом меняет в данном случае идентификаторы в базе данных. В итоге получается то, что видим на картинке.

Если бы мне такое показали в 1993 году, я бы радостно захлопал в ладоши и сказал бы: "Вау! Как круто!". В 2012 году рука тянется к канделябру такой подход хочется покритиковать.

Итак, это все будет хорошо только в случае, если мы работаем по методикам:

1. У нас один проект, и на нем один разработчик, который это все держит в голове и будет держать.
2. Проект настолько одноразовый, что нам все равно, что и как будет с ним дальше. Слили и забыли.

Работа любой мало-мальски серьезной системы - это куча и куча данных, которые рождаются в процессе ее работы. Это логи ее работы. Это отладка ошибок. Это попытка разобраться в проблеме местными силами тех, кому подобная система поставлена. Это жизненный цикл продукта, смена поколений разработчиков и т.п. В приведенном примере мы видим массивный фундамент заложенного на долгие годы необоснованного геморроя, когда даже понятного лога мы не увидим, понять, что происходит с базой данных штатными средствами базы данных мы не сможем. И так далее, и т.п. Это слишком варварский метод.

С учетом переноса ИТ в третьи страны тут видится и другая опасность, как я писал в исходном посте. Передадут такую вот систему, допустим, админу в Африку. Африканский админ возьмется за голову, что ж это за система такая. Потом его это заколебет. Потом он захочет отомстить. И вот автор системы в возрасте 60..70 лет вместо того, чтобы наслаждаться пивом с шахматами на скамеечке, будет биться в корчах на больничной койке. А все потому, что африканский админ от чувства безысходности отдал его на оутсорсинг вуду-шаману, и тот тычет в его куклу иголками.

Вам это нужно?

Оставить комментарий

Популярные посты:

• Ранее
• Архив