Comments 21
Статья о рефакторинге без единого примера и строчки кода?
Да, это так. Статья посвящена инструментам и правилам, которых стоит придерживаться, а также тому, как определить потребность в рефакторинге. Я сознательно решил не включать примеры кода потому, что:
1) Пример будет написан на конкретном языке программирования, и это может оказаться бесполезным или неинтересным для части аудитории.
2) Рефакторинг без четких договоренностей в команде — спорный шаг (я отметил это в статье). У разных разработчиков может быть разный опыт и подход к одной и той же задаче, поэтому важно избегать навязывания субъективных решений. Мой акцент был на универсальных принципах, а не на частных примерах.
Тем не менее, я согласен, что примеры могли бы быть полезны для кого-то. Без иронии буду рад, если вы поделитесь своими примерами или расскажете о своем опыте рефакторинга. Мы здесь, чтобы учиться друг у друга и делиться знаниями :)
«Вот почему даже Ной сделал бэкап всей фауны» - отлично сказано ☺️ Интересно было узнать, что столько различных современных инструментов существует для рефакторинга, буду использовать в работе. Полезно, спасибо!
Спасибо за системную статью.
Вот вроде бы и какие-то вещи знаешь, умеешь, используешь.
Но когда все разложено по полочкам - знания становятся упорядоченными и легче передаются.
Удивительно пустая статья. Как будто кто-то палкой по пустой бочке постучал.
Я всегда рад конструктивной критике и замечаниям, как, например, это было сделано тут: https://habr.com/ru/articles/873386/comments/#comment_27791258 . Из вашего комментария я не могу понять суть недовольства, поэтому я с ним просто не согласен. В статье описаны: 1) признаки систем, требующих и не требующих рефакторинга; 2) основные инструменты и подходы анализа кодовой базы; 3) подсвечена необходимость метрик, для обоснования рефаторинга с точки зрения бизнеса; 4) и, наконец, даны рекомендации по самому рефакторингу. При этом, учитывая широкую аудиторию ресурса, я не зацикливался на каком-то определенном языке программирования и давал общие рекомендации по этому процессу, не углубляясь в подробности. Кстати, именно поэтому материал отмечен сверху как "простой". Если вы считаете, что в статье чего-то не хватает, буду рад, если вы добавите это здесь, в комментарии, чем существенно его "наполните".
Статья о рефакторинге без единого примера и строчки кода?
Да, это так. Статья посвящена инструментам и правилам, которых стоит придерживаться, а также тому, как определить потребность в рефакторинге. Я сознательно решил не включать примеры кода потому, что:
1) Пример будет написан на конкретном языке программирования, и это может оказаться бесполезным или неинтересным для части аудитории.
2) Рефакторинг без четких договоренностей в команде — спорный шаг (я отметил это в статье). У разных разработчиков может быть разный опыт и подход к одной и той же задаче, поэтому важно избегать навязывания субъективных решений. Мой акцент был на универсальных принципах, а не на частных примерах.
Тем не менее, я согласен, что примеры могли бы быть полезны для кого-то. Без иронии буду рад, если вы поделитесь своими примерами или расскажете о своем опыте рефакторинга. Мы здесь, чтобы учиться друг у друга и делиться знаниями :)
"Работает? Трогай! Рефакторинг (возврат к исходному)"
Работает? Трогай! Модернизируй
Штирлиц сел в такси и сказал водителю:
—Трогай.
Водитель потрогал:
— Ого-го!
На тему рефакторинга советую глянуть доклад "Тагир Валеев - Атомарный рефакторинг в IntelliJ IDEA: прогибаем IDE под себя" - доклад с большим количеством примеров как атомарно проводить рефакторинг ничего не ломая.
"Старайтесь использовать больше готовых библиотек и фреймворков."
Крайне спорное утверждение, каждая внешняя библиотека это зависимость, которая может тянуть за собой другие зависимости и является потенциальной проблемой: совместимости и безопасности.
Стоит хорошо подумать прежде чем что-то добавлять в проект. Рекомендовать использовать как можно больше библиотек и фреймворков, мне кажется вредный совет, лучше использовать как можно меньше внешних библиотек, а там, где использовать свою специализированную реализацию не оправдано, так как сложно, долго, или еще что-то уже прибегать к сторонним библиотекам и фреймворкам.
Согласен, к выбору сторонних решений, используемых в проекте, необходимо подходить с максимальной ответственностью. В статье я подчеркнул, что предпочтение следует отдавать проверенным инструментам, одобренным сообществом. В то же время не стоит добавлять библиотеки ради решения совсем базовых задач. Но и стремление полностью избегать готовых решений — по моему мнению тоже не безупречный подход, который в будущем может усложнить жизнь из-за необходимости поддерживать дополнительный (возможно весьма объемный) код. Изобрести все с нуля невозможно, поэтому важно находить баланс между использованием готовых решений и разработкой собственного функционала.
Особенно спорный на фоне озвученного факта о том, что большинство библиотек не поддерживаются, или находятся в неудовлетворительном состоянии.
Недавно пришлось работать с xml и xsd в дотнете. Да, это даже звучит устаревшим, но надо было, для интеграций. После изучения исходного кода даже встроенных библиотек и утилит, выяснилось что там код 15ти летней давности. Оказалось, что написать собственный кодогенератор, вместо использования СИСТЕМНОЙ библиотеки - решение на порядок лучше. Избавило от кучи неразрешимых изначально проблем, дало совершенно иной уровень контроля и тестирования, при этом вряд ли придется много его рефакторить в будущем, ибо xml давно уже окаменелость и меняться навряд ли будет. Пример может и не очень стандартный, но показательный. Если бы я не полез в исходники библиотек, то даже сложно оценить тот уровень костылирования, к которому пришлось бы прибегнуть, чтобы добиться желаемого функционала от стандартных библиотек.
Я бы перефразировал с точностью до наоборот. Старайтесь тщательно изучить каждую библиотеку и фреймворк, прежде чем использовать. Оцените их код, поддержку, частоту релизов, выпуск новых версий, зависимости, багфикс и тд. Не используйте ничего, в чем уверены меньше, чем в своем собственном коде.
Я абсолютно согласен с тем, что к выбору библиотек нужно подходить очень осторожно, так как они действительно могут не поддерживаться сейчас, или же это поддержка может закончиться в будущем. Собственно именно поэтому я в статье и написал, что следует выбирать проверенные решения, выработанные и одобренные сообществом, а также то, что перед подключением таких решений следует убедиться в том, что библиотека активно поддерживается. Дополнительно в статье было отмечено, что следует периодически проводить их аудит, и если используемое решение было заброшено создателями, возможно следует подумать о его замене.
При этом я по-прежнему считаю, что в первую очередь следует использовать готовые библиотеки. Если подходящего решения не нашлось, тогда уже можно задуматься о разработке собственного. А в случаях, когда выбранное opensource решение оказалось заброшенным, вместо создания аналога (вероятно приватного), лучше рассмотреть возможность внести вклад в развитие этой библиотеки, доработав и улучшив ее самостоятельно.
Библиотеки это частный случай более общего правила использовать готовые решения. Любой системный дизайн начинается с поиска готового решения, готовых сервисов и тд. С библиотеками то же самое, только в меньшем масштабе и своей спецификой. Вот эту специфику я и попытался описать. Конечно лучше использовать готовое решение, всегда и везде, чем изобретать свой велосипед. Главное чтоб потом не зайти с этим решением в тупик и не пришлось экстренно все-таки этот велосипед строить, что может грозить большим объемом двойной работы.
Согласен со всем кроме метрик.
Метрики, измерение полезности рефакторинга: уменьшение времени исправления багов, уменьшение времени изменений по новым требованиям, уменьшение нарушений норм превышения сроков исправления багов, снижение стоимости разработки и сопровождения..
Они вполне измеримы, обосновать выделение денег на реф можно через систему менеджмента качества (СМК). Но обычно СМК отсутствует. Русский менталитет - с.
Спасибо за ваше замечание! Некоторые из предложенных вами метрик уже были упомянуты в статье, но ваше дополнение действительно ценно. Но из собственного опыта могу сказать, что в крупных проектах рефакторинг невозможно проводить без постоянного анализа продуктовых метрик, дополнительно к предложенным вами. Даже небольшие изменения в устаревшем коде могут привести к неожиданным эффектам на продуктовой стороне. И в таких случаях может потребоваться откат изменений и переосмысление подхода к рефакторингу.
А я наоборот, всегда совмещаю рефакторинг соответствующего модуля с выполнением бизнес-задач: новая фича всё равно проходит полный цикл тестирования, в том числе ручное и пользовательское, заодно и рефакторинг проверяется. Риск поймать функциональный регресс из за рефакторинга в этом случае ниже.
Работает? Трогай! Рефакторинг