Roman Sevastyanov "Рефакторинг - пути улучшения кода"
•Download as PPTX, PDF•
0 likes•629 views
Рефакторинг – важная часть разработки любого большого проекта. В этом докладе я сфокусируюсь на основных техниках рефакторинга кода. Также мы обсудим следующее: Когда нужно рефакторить код? Что такое чистый код? Причем тут тесты?
Recommended
Recommended
More Related Content
Similar to Roman Sevastyanov "Рефакторинг - пути улучшения кода"
Similar to Roman Sevastyanov "Рефакторинг - пути улучшения кода" (20)
More from Fwdays
More from Fwdays (20)
Recently uploaded
Recently uploaded (20)
Roman Sevastyanov "Рефакторинг - пути улучшения кода"
- 1. Refactoring Ways to improve your code
- 2. Roman Sevastyanov Software developer Co-founder doge.codes Twitter: @romasevastyanov Github: @sevastyanovio Telegram: @davex69
- 4. Refactoring is a small intermediate steps in the direction of heaven
- 7. Refactoring steps 1. Figure out the problem
- 8. Refactoring steps 1. Figure out the problem 2. Allocate time and plan
- 9. Refactoring steps 1. Figure out the problem 2. Allocate time and plan 3. Configure “refactoring tools” and tests
- 10. Refactoring steps 1. Figure out the problem 2. Allocate time and plan 3. Configure “refactoring tools” and tests 4. Refactoring
- 11. Refactoring steps 1. Figure out the problem 2. Allocate time and plan 3. Configure “refactoring tools” and tests 4. Refactoring 5. Make problems visible
- 12. Static analysis
- 13. Psalm
- 14. Phan
- 15. phpstan
- 16. PHP-CS-Fixer
- 19. Code smells
- 20. Long method
- 21. Long method
- 22. Switch operator
- 23. Switch operator
- 24. Duplicated code
- 27. Comments
- 28. Type Embedded in Name
- 30. Large Class
- 31. Dead Code
- 33. Oddball Solution
- 34. Data Class
- 35. Refused Bequest
- 36. Shotgun Surgery
- 37. What next? ● Refactoring - Martin Fowler (book)
- 38. What next? ● Refactoring - Martin Fowler (book) ● Refactoring Guru (interactive course)
- 39. What next? ● Refactoring - Martin Fowler (book) ● Refactoring Guru (interactive course) ● https://blog.codinghorror.com/code-smells/ ● SOLID ● TDD ● DDD
Editor's Notes
- Всем привет, я Рома Севастьянов. Я создатель doge.codes. Мы делаем онлайн образование great again. Также я работал 6-7 лет как разработчик в американских стартапах/компаниях
- Чтоб такого не было, нужно рефАкторить. Но не сразу все, а (следующий слайд)
- Keep taking small steps. In the right direction of course. Progress is way more important than achieving perfection. РефАкторинг – это процесс. Постепенно улучшая и рефАкторя код – он становиться лучше. Даже если вы думаете, что проект очень плохой – лучше его не переписывать, а рефакторить Также зацепить такое понятие, как КУЛЬТУРА РЕФАКТОРИНГА
- Вам нужно делать рефакторинг и париться, чтоб код был хорошим. Не терпите небрежность в коде, это нонсенс. Но не только вы должны ЭТО делать, но и ВСЯ команда. Не имеет значения, как тяжко вы работали чтоб зарефакторить код, если кто-то один его факапит и портит. Командная дисциплина тут очень нужна. Если кто-то начинает делать левый код, вся команда в это скатиться. Не допускайте ЭТОГО.
- Правильный процесс рефакторинга позволит не превратить в mess его. Делайте МАЛЕНЬКИЕ шаги итеративно. И будет результат. Small victories generate momentum. Прогресс НАМНОГО важнее, чем единожды идеальный код. Вы со временем, зависит от размера вашего проекта УВИДЕТЕ хороший результат от рефакторинга.
- Для того, чтоб начать рефАкторить. Определитесь с проблемой. Не нужно переписывать тонны кода. Пусть для начала это будет 1 класс / контроллер. Или несколко методов. Все будет, со временем.
- Это важная тема. У нас в Украине и даже в мире, я очень редко видел КУЛЬТУРУ рефАкторинга. Поэтому, очень вероятно, что менеджмент БУДЕТ против этой непонятной штуки, которая не приносит денег. Прокачивайте свой эмоциональный интеллект, чтоб понять, как другие люди видят ситуацию. Вот вы приходите к менеджеру (я говорю о тех, кто не понимает зачем нужен рефакторинг), и просите выделить время на рефАкторинг, допустим, модели одной. Или какой-то бизнес-логики. Потому что она плохо написана и с ней сложно работать. Как это слышит и видит менеджер? Привет, я написал плохой код, вы мне заплатили за это. Давайте я сейчас попытаюсь сделать лучше и вы мне еще раз заплатите. Поэтому, попытайтесь донести для менеджера что такое рефАкторинг Это как ходить в душ Что сжатые сроки не всегда позволяют быстро писать хорошо Что продукт меняется и то, что раньше ожидалось – сейчас не подходит, другие реалии
- Настройте refАctoring tools. Под refАctoring tools я имею ввиду static analytics библиотеки и плагины, которые УПРОЩАЮТ вашу жизнь. О них я поговорю чуть позже. Это делается очень просто. Тесты помогут вам понять ваш проект. И не зафакапить после рефакторинга.
- Кроме тестов нужно еще и видеть проблемы. Настройте логирование и мониторинг ошибок (Sentry) и нагрузки. Посмотри на эти 5 шагов. Тут нету ничего сложного. Возможно часть вещей уже используется у вас на проекте. Но если это делать, допустим, сначала раз в месяц. Или выделят одну иттерацию на это – то результаты будут ошеломляющие.
- Обзор тулз для рефакторинга Эти программы / либы позволяют УПРОСТИТЬ работу разработчика. Меньше париться и меньше держать в голове ньюансов. Лучше фокусироваться на разработке ФИЧ и продукта. git hooks Psalm Phpstan https://github.com/exakat/php-static-analysis-tools
- Psalm - тулза, которую разработала компания Vimeo Статический анализатор кода. Проверяет основные ошибки в PHP коде и подсказывает, что где исправить Очень просто устанавливается через Компосер ДАЖЕ ЕСТЬ ОНЛАЙН Советую запускать перед и после рефакторинга Отлично подходит для того, чтоб превентить ошибки в проде
- Phan - более комплексная тулза, создал ее Расмус Лердорф, создатель PHP Немного сложно установить Тоже статический анализатор кода, но умеет очень много всего. Чекает PHPDoc (@property, @deprecated, @method анотации) Чекает классы, методы, уровни доступа, мертвый код и тд и многое другое Есть разные плагины к нему
- phpstan - прикольная и простая утилита, которая помогает НАХОДИТЬ PHP errors БЕЗ запуска кода Простая в использовании, подходит даже для дебага
- PHP-CS-Fixer - PHP Coding Standards Fixer Скорей всего некоторый из вас УЖЕ пользовались этим. Он используется в многих плагинах. Фиксит стиль кода по стандартам.
- git hooks Отличная и очень простая тулза, которая позволяет на определенных событиях запускать нужные скрипты. Например, PSR-2 чекер стиля Или что-то другое Это, по ститик аналитик туллс все
- Хорошим показателем цивилизации является количество библиотек на квадратный метр. Поэтому, чтобы внедрить цивилизованность в ваш проект, это может быть отличным подходом. Так же помимо библиотек – можно делать самодостаточные микросервисы с которыми общаться по API МЕНЬШЕ КОДА – МЕНЬШЕ ПРОБЛЕМ
- Разбор признаков плохого кода Code smell (запахи кода) – это не баги, но это признаки, что нужно рефакторить код. Термин придумал Kent Beck в 90-тых.
- Проблема: Часто бывает такое, что пишешь что-то новое в метод и он разрастается очень большим. Чем больше фукнция – тем сложнее ее понять Решение: Вынести часть метода в отдельный метод (или даже класс)
- Проблема: Часто бывает такое, что пишешь что-то новое в метод и он разрастается очень большим. Чем больше фукнция – тем сложнее ее понять Решение: Вынести часть метода в отдельный метод (или даже класс)
- Очень часто SWITCH оператор является очень опасным местом для рефакторинга Его можно использовать в местах, где ОН очень просто используется или например, в Фабричном паттерне ООП
- Очень часто SWITCH оператор является очень опасным местом для рефакторинга Его можно использовать в местах, где ОН очень просто используется или например, в Фабричном паттерне ООП
- Проблема: Какой-то код повторяется или повторяется частично. Происходит часто из-за того, что лень писать новый код. Или джун увидел почти такой же код, скопировал и отправил Решение: Удалить один из методов или сделать темплейт для кода
- Проблема: Сложное условие. Или много if-ов Решение: Вынести в отдельный метод, разбить на части. Использовать стратегию
- Проблема: Сложное условие. Или много if-ов Решение: Вынести в отдельный метод, разбить на части. Использовать стратегию, decorator
- Проблема: Когда в коде много комментариев, особенно, когда они объясняют не “зачем?”, а “что?” Мы говорим не об @phpdoc Также, не стоить удалять комментарии, которые объясняют сложный алгоритм Решение: Писать комментарии для людей, не машин. Делать названия функция таким, чтоб было и так понятно без комментариев.
- Проблема: Тип записан в названии переменной, это устаревший подход. Так лучше не делать. Потому что если поменяется ее тип – нужно будет изменять название Решение: Переименовать
- Проблема: Непонятное или не точное название класса, переменной, метода Решение: Переименовать
- Проблема: Есть большой класс, в котором много лишнего. Сложно работать с ним и поддерживать Решение: Большой класс, так же как и большой метод можно разбить на маленькие классы.
- Проблема: Есть код, который не работал уже давно. Мертвый код Решение: Удалить такой код
- Проблема: Пишим когд, который будет спасать нас от всех проблем в мире Решение: Пишем код, который нам нужен сегодня, сжимаєм иерархию
- Проблема: Представим, что у нас есть 1 проблема в двух разных частях системы. И это решено разными способами Решение: Нужно делать одним способом. Тут нам помогает Интерфейс с Адаптерами
- Проблема: Избегайте классов, которые просто сторят данные Решение: Либо удалять такие классы и переносить куда-то поля, либо делать их полезными
- Проблема: Унаследовались от класса, но его методы никогда не используются Решение: Замените наследование – делегированием. Засуньте в род класс нужные методы, если они нужны
- Проблема: Когда хотите сделать простое изменение, а это требует много изменений Решение: Move Method [F 142] Move Field [F 146] Inline Class [F 154]