Я люблю копаться в программных кодах чужих проектов. Только не нужно проводить параллели с грязным бельем, это совсем не так. Чужая программа - кладезь полезных знаний, и новых, порой очень оригинальных, решений. В основном, люблю покопаться с маленькими скриптами. Просто их понять гораздо проще. Последнее мое увлечение - библиотека Jquery, но речь сейчас не об этом.

Хочу рассказать о приеме, который я использую в двух случаях:

1. Начинаю анализ крупного проекта (например CMS Drupal);
2. Получаю от заказчика работу, выполнение которой требует оперативных правок базы данных системы, написанной другим программистом.

Думаю многие со мной согласятся, что структура данных программы - это ее фундамент. Если знать какие данные где хранятся разобраться в самой программе гораздо легче. Самый очевидный способ получить представление о данных программы - проанализировать код программы. Но подобная процедура сожрет очень много времени, а результаты хочется получить побыстрее. Поэтому для меня, лучший способ понять, что делает скрипт - это посмотреть, что было до его запуска, и что стало после. Сравнив данные в первом и втором случае можно понять, что делает скрипт. При этом совсем неважно, что нам неизвестна информация о реализации скрипта, к ней всегда можно обратиться позже, код становится гораздо понятнее, когда знаешь, что он должен делать!

Давайте рассмотрим конкретный пример на примере CMS Drupal:

Что у нас есть:

1. Установленная система;
2. Желание разобраться с тем как все работает.

Прежде всего нужно определить первоначальную цель, потому как, понять с наскока как работает подобная крупная система просто невозможно. Я выбрал довольно простой случай: определить как сохраняются добавляемые страницы. Для этого я сделал следующие:

1. В виду того, что система уже установлена (смотри требования), прежде чем делать какие либо изменения, создал дамп текущей базы данных Drupal. Это будет эталонный образ, к которому буду регулярно возвращаться. Данный шаг необходим, так как для эксперемнетов лучше иметь “чистую” систему;
2. Поигрался с функциями CMS, немного разобрался, что к чему;
3. Откатился к эталонному образу БД;
4. Создал дамп текущей БД и назвал его dump1.sql (просто и без вкуса :-))) );
5. Добавил простую страницу (при этом старался набивать как можно меньше данных, например в поле Title: test1, а в поле Content: test2);
6. Создал дамп под названием dump2.sql
7. Запустил утилиту diff (кто не знает - это утилита под Linux, которая вычисляет разницу между двумя файлами. Аналог есть и под Винду, но я не знаю как он называется, по традиции эту информацию можно добавить в комментарии);
8. Получил результат. Из более чем 40 друпаловских таблиц, в результате добавления новой страницы изменились следующие: cache_filter, history, node, node_comment_statistics, node_revisions, sequences, sessions, users, watchdog.

Все, первый результат получен. Теперь путем нехитрых логических рассуждений определяем “ненужные” таблицы, это: cache_filter, history, sessions, users, watchdog (думаю всем понятно, что это служебные таблицы!).

Остаются четыре кандидата на детальное рассмотрение: node, node_comment_statistics, node_revisions, sequences.
После просмотра структуры таблиц в Mysql (кто не знает комманда SHOW CREATE TABLE table_name) функции некоторых из них становятся понятными:
1. node - хранит тип узла (в данном случае “Страница”), название, и другую служебную информацию;
2. node_comment_statistics - хранит статистику по комментариям;
3. node_revisions - хранит версии страниц (что-же получается Drupal позволяет иметь несколько версий одной и той же страницы? Видимо что так, но пока это всего лишь предположение.)

Назначение таблицы sequences с первого взгляда осталось непонятным.

На этом предварительный анализ данных можно считать оконченным. Второй этап - анализ кода! Благо в данной системе он хорошо документирован и разобраться в нем не составляет особого труда.

На этом пока все. Если будет интересно (буду судить по отзывам в комментариях) напишу вторую часть об анализе кода.