Эффективный рефакторинг / Блог им. rmrevin
Оригинал: Effective Refactoring Strategies
Мой брат называет предновогоднюю неделю «потерянной» — за это время почти ничего невозможно сделать, потому что большинство людей уходят в отпуск, а оставшиеся заняты предновогодними приготовлениями. В это время у начинающих разработчиков программного обеспечения появляется прекрасная возможность сделать одну вещь, на которую у них всегда вечно не хватало времени: самое время сделать код более доступным для понимания.
У большинства разработчиков есть возможность выкроить несколько часов свободного времени для рефакторинга. Они могут, наконец, поменять сделанную в спешке еще в сентябре архитектуру разделов, могут написать тесты для разделов, которые остались непроверенными с апреля. Иными словами, за «потерянную неделю» можно сделать много полезных дел.
Но прежде чем погрузиться в пучину оптимизации кода не на шутку, следует учесть некоторые соображения.
Сначала протестируйте
Это самый простой способ избежать в рождественское утро звонка от бешеного босса, который сообщит вам, что вся система рухнула в одночасье. Нет способа убедиться в последующем функционировании кода, кроме как написание юнит-тестов, даже если речь идет о структурных изменениях.Я отнюдь не специалист по написанию модульных тестов. А вот Chris Hartjes — да: он написал книгу о тестировании и часто освещает эту тему в блоге. Суть заключается в следующем: тесты выступают гарантом уверенности, что ваши изменения не нарушают целостность приложения в некоторых местах, из-за чего оно может работать неожиданным образом.
Без тестирования, изменения в коде могут кардинально нарушить работу вашего приложения, и при этом вы никогда не узнаете, чем проблема была вызвана. Поскольку приложение постоянно расширяется, становится все сложнее следить за разрастающимся кодом и выявлять ошибки вручную. Юнит-тесты помогают обнаружить их заранее. Рефакторинг без тестирования — это большая ошибка.
Один метод, одна задача (один класс, одна задача)
Убедитесь, что ваш код подчиняется принципу единой ответственности, не только в классе абстракции, но и в методе абстракции. Методы, которые выполняют больше, чем одну задачу, по своей природе не очень подходят для многоразового использования, в отличие от методов, которые имеют только одну роль. Кроме того, сложнее определить сбои, когда метод или функция имеют более чем одну роль.Общие направления совершенствования кода напрямую связаны с методами, которые содержат строки кода, или код, который проверяет данные. Это первые кандидаты для рефакторинга, как и математические операции.
В своей книге я подробно описываю проблему абстракции объектно-ориентированных приложений. Важно также не переусердствовать в процессе реорганизации методов и функций. Хорошим правило: удаление кода для функции должно сделать код более многоразовым и простым для проверки.
Не бойтесь объектов и классов
Единый принцип ответственности означает, что вы неизбежно останетесь в конечном итоге с несколькими объектами и классами. Это прекрасно! На самом деле, это лучше, чем один большой класс.Объекты по сути не так уж и каверзны. Они не уничтожат ваш компьютер и не замедлят работу вашего приложения. Если у вас есть веские причины для введения нового объекта, создайте его.
Удалите неиспользуемый, ненужный или старый код
Если посмотреть вокруг, большинство приложений имеют залежи неиспользуемого кода. Этот код должен периодически удаляться. Настало время найти и удалить этот код.Читайте код внимательно и запустите dead code detector, чтобы увидеть, какие его части больше не используются. Первыми клиентами на удаление являются переменные, которые больше не используются, но все еще определены. Не занимайтесь микрооптимизацией кода. Посмотрите на него критически и очистите от хлама.
Но не забывайте об осторожности!
Документируйте код
Все жалуются на нехватку времени для написания документации. Рассмотрите небольшой перерыв как возможность вернуться к написанию блоков документации, т. е. документированию кода, который вы написали еще в прошлом году. Хотя зачастую это утомительный процесс, результат окажется очень полезным. Вы поймете это, столкнувшись с функцией, которую когда-то писали и понятия не имеете, что она делает. Документация призвана решить эту проблему.Рассмотрите возможность использования стандартизированых форматов для блоков документации. Это позволяет скомпилировать документацию в удобный для чтения вид. При наличии стандартизированных документов возможно их использование в IDE или других средствах разработки.