Мастерство программирования

Автор: Giuseppe Maxia
Оригинал статьи: A cool idea - Revision engine
Перевод: Ярослав Ворожко

Недавно в списке MySQL internals@list появился анонс, про выпуск нового storage engine. Компания DDengine создала новый движок revision engine, набор встроенных прокси внутри MySQL, которые следят за изменениями данных в вашей базе.

Идея отличная. Вы пишите в свою таблицу, обновляете и удаляете данные, не беспокоясь ни о чем, в то время как revision engine будет сохранять все ваши изменения работая за сценой.

На данный момент revision engine хорошо работает под Linux. Под другие системы пока, что есть проблемы, но это и понятно, так как версия пока еще 0.1.

В документации говорится, что существует два пути использования revision engine. Первый с встроенным хранением, которые тихо изменит структуру таблицы и добавит revision информацию в нее, и второй метод использует две таблицы, одна из которых создается за сценой.

Например:

create table t1 (
 id int not null primary key,
 c char(10)
) engine=revision comment="InnoDB:DOUBLE";
show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
| t1_revision    |
+----------------+
desc t1;
+-------+----------+------+-----+---------+-------+
| Field | Type     | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| id    | int(11)  | NO   | PRI | NULL    |       |
| c     | char(10) | YES  |     | NULL    |       |
+-------+----------+------+-----+---------+-------+

desc t1_revision;
+--------------------+---------------------+------+-----+
| Field              | Type                | Null | Key |
+--------------------+---------------------+------+-----+
| id                 | int(11)             | NO   | PRI | 
| c                  | char(10)            | YES  |     |
| revision_id        | int(10) unsigned    | NO   | PRI |
| revision_timestamp | timestamp           | NO   |     | 
| revision_deleted   | tinyint(3) unsigned | NO   |     |
+--------------------+---------------------+------+-----+

Ключевое слово “InnoDB:DOUBLE” говорит engine, что надо использовать метод двух таблиц для хранения revision info, в данном случае t1_revision создается автоматически.

Операции над таблицами прозрачны.

insert into t1 (id,c) values (1, 'aaa'), (2, 'bbb');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

insert into t1 (id, c) values (3, 'ccc'), (4, 'ddd');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

select * from t1;
+----+------+
| id | c    |
+----+------+
|  1 | aaa  |
|  2 | bbb  |
|  3 | ccc  |
|  4 | ddd  |
+----+------+
4 rows in set (0.00 sec)

select * from t1_revision;
Empty set (0.00 sec)

Ничего необычного. Давайте попробуем, что нибудь поменять.

update t1 set c ='changed' where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  2 | bbb     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
4 rows in set (0.00 sec)

show variables like '%revision%';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| revision_select_mode | current |
+----------------------+---------+
1 row in set (0.00 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

delete from t1 where id = 2;
Query OK, 1 row affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

set revision_select_mode = 'deleted';
Query OK, 0 rows affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  2 | bbb  |           1 | 2008-09-30 05:47:14 |                1 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
3 rows in set (0.00 sec)

Переменная сессии revision_select_mode , переключает режим отображения данных в revision engine.

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

Перевод не оригинальный, текст немного видоизменен, без потери смысла статьи передаваемого Автором текста.

Хочу сказать спасибо всем, кто дал отзыв в первой части статьи «Рефакторинг для начинающих». Особенно спасибо Yury Veretelnikov, за его (в большинстве случаев) справедливую критику, которая открыла мне глаза на проблемы в оформлении и написании статьи.

Это статья дополнение, в которой я попытался описать видимые и невидимые проблемы, которые будут стоять перед программистом при провидении рефакторинга. Я не претендую на полноту изложения, пусть это послужит для вас отправной точкой к профессиональному рефакторингу.

Кратко содержание:

• Цель рефакторинга
• Простые и сложные методы рефакторинга
• Когда начинать рефакторинг?
• Как начать рефакторинг?
• Как не поломать рабочий код?
• Когда рефакторинг не нужен?
• Каталог методов рефакторинга и примеры рефакторинга

А теперь кратко по каждому пункту.

Цель рефакторинга

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

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

Простые и сложные методы рефакторинга

Простые методы рефакторинга — это базовые, фундаментальные методы применяемые в рефакторинге. Например это: выделение метода, перемещение поля класса, выделение класса, переименование метода, класса или поля и т.д.

Учите простые методы рефакторинга, так как это фундамент на основе которого строится любой вид рефакторинга. Нельзя начать рефакторинг не зная фундаментальные методы.

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

Когда начинать рефакторинг?

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

Применяйте рефакторинг, если требуется исправить ошибку. При исправлении ошибок польза рефакторинга в том, что код становиться более понятным. Если мы получаем сообщение об ошибке, то это признак необходимости рефакторинга, потому что код не был достаточно ясным и мы не смогли увидеть ошибку.

Применяйте рефакторинг при разборе кода. Разбор кода это хорошая практика, когда в команде разработчиков, разработчики проверяют код друг друга.

Как начать рефакторинг?

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

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

Как не поломать рабочий код?

Постройте набор тестов для перерабатываемой части кода. Тесты важны, так как даже при последовательном проведении рефакторинга можно допустить ошибки, тесты помогут вам исключить возможные ошибки.

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

Когда рефакторинг не нужен?

Иногда рефакторинг не нужен. Например, когда надо переписать программу с нуля. Иногда имеющийся код настолько запутан, что подвергнуть его рефакторингу, конечно, можно, но проще начат все с самого начала.

Явный признак необходимости переписать код — это его неработоспособность. Это обнаруживается при его тестировании, когда ошибок так много, что сделать код устойчивым не удается.

Другой случай, когда следует воздержаться от рефакторинга, это близость даты завершения. Однако приближение срока окончания работ — единственный случай, когда можно отложить рефакторинг, ссылаясь на недостаток времени.

Каталог методов рефакторинга и примеры рефакторинга

Большой каталог методов рефакторинга можно найти на refactoring.com вместо примеров кода, тут применяются примеры на языке UML.

Также, хороший каталог методов рефакторинга можно найти на wikipeadia, каждый метод снабжен примером на C#.

В заключении

Применение методов рефакторинга требует от вас: хорошего знания ООП, умение писать тесты, быть терпеливым делая рефакторинг небольшими шагами, проверять каждый шаг и постоянно учиться.

Рефакторинг - это реорганизация существующего кода без изменения функциональности.

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

Вот 7 хороших советов для проведения рефакторинга:

1. Всегда выполняйте рефакторинг короткими шагами с перерывом на перекомпиляцию и запуском тестов. Чем меньше ваши шаги, тем лучше вы локализуете потенциальные ошибки и тем быстрее вы их устраните. То, что ошибки будут можно не сомневаться. ;-)
2. Проводите рефакторинг снизу вверх, особенно, если у вас длинная и запутанная цепочка наследования классов. Старайтесь всегда сначала производить изменения в потомственных классах, прежде чем приступать к базовым классам.
3. Вы должны знать основные методы рефакторинга, для этого советую вам купить книгу Мартина Фаулера - “Рефакторинг”.
4. У вас всегда должна быть цель с которой вы производите рефакторинг, не делайте его там где он не нужен или только, если это не первоочередная задача. Чем лучше вы понимаете зачем вы это делаете, тем качественнее будет результат.
5. Не увлекайтесь рефакторингом, рефакторинг не добавляет функционала в программу, поэтому и каких либо видимых результатов вы также не получите. Делайте перерывы для того, чтоб сделать, что то, что можно увидеть и оценить. Тогда ваш начальник будет вами доволен. :)
6. Любой вид рефакторинга можно сделать за 5, 20 минут, максимум за один час. Но в основном рефакторинг является комплексной задачей, которая может выполняться в течении недель или месяцев над действующим проектом. Идея в том, что двигаться нужно постепенно и небольшими шагами, и возможно уделяя этому не больше одного часа в день. Это хороший метод рефакторинга, потому как не занимает много времени и убедить начальство в необходимости будет намного проще, ведь 1 час это так мало, не так ли?
7. В долгосрочной перспективе у вас будет красивый и легко сопровождаемый код, код который написан для людей, а не для машин, код которым вы можете гордиться и показывать в пример, код который работает так как вы этого хотите, и все это за невысокую цену рефакторинга!