refactoring.guru
refactoring.guru облегчает вам поиск всего, что вам нужно знать о рефакторинге, шаблонах проектирования, принципах SOLID и других темах интеллектуального программирования.
Dive Into REFACTORING
После двух лет работы я рад представить вам мой курс по рефакторингу, который сделает вас лучшим программистом. Я программировал с 13 лет. В Windows тогда даже не было кнопки «Пуск». С тех пор я работал в пяти компаниях, выучил полдюжины языков программирования и запустил несколько успешных проектов.
В этом курсе я поделюсь с вами своими знаниями и научу вас:
Курс научит вас 21 запаху плохого кода и 66 методам рефакторинга, чтобы исправить его.
Каждая глава содержит примеры на Java, C # и PHP.
Зачем мне покупать этот курс вместо толстой книги о рефакторинге?
refactoring.guru облегчает вам поиск всего, что вам нужно знать о рефакторинге, шаблонах проектирования, принципах SOLID и других темах интеллектуального программирования.
Отлично об это проблеме сказано в заключительной части отличной небольшой книги (рекомендую) про подходы к именованию вот тут https://namingthings.donedone.com/#ch-naming-and-teaching
И, по-моему, вот эта перелинковка между проблемами и методами а-ля реляционные базы данных создаёт скорее дополнительную ментальную нагрузку. Как когда ты читаешь код и видишь метод с каким-то общим расплывчатым названием и тебе приходиться заглянуть в реализацию метода, чтоб понять, что же все таки происходит.
Некоторые решения вообще, по-моему, спорные. Вместо переменной которая используется в нескольких местах предлагается заменить несколькими вызовами одного и того же метода. Это хорошая практика? Да, есть случаи в которых есть смысл вынести какие-то выражения/вычисления в отдельный метод. Но можно подобрать какие-то более удачные примеры без сомнительных побочных эффектов. Автору было просто лень думать или искать в своём опыте такие примеры.
Ну и наименее важное это иллюстрации. Они типа симпатичные, но как метафоры, по-моему, тоже никакие. И очевидно это проёб не иллюстратора.