Рефакторинг. Что нужно понять в первую очередь

Если начать читать книгу Марина Фаулера «Рефакторинг. Улучшение проекта существующего кода» в первый раз, то для программиста с небольшим опытом можно легко запутаться в том, что же сделать в первую очередь в своей программе чтобы навести там более-менее порядок или чтобы не допустить беспорядка если программа еще не написана. Т. к. рефакторингов там очень много, и чтобы их как следует освоить нужны годы, а программу нужно написать сейчас. Опишу здесь самые главные рефакторинги, без которых не обойтись.

1. «Извлечение метода». На смену одному большому методу, который делает много всего должны прийти несколько методов каждый из которых делает что-то одно. Названия этим методам нужно давать строго в соответствии с тем, что они делают. В идеале другой программист должен только взглянуть на название метода и ему сразу должно стать понятно какой код находится внутри.

2. «Извлечение класса». Если класс разрастается (в нем становится много переменных и методов), то нужно проверить его на предмет того, что он делает, сколько обязанностей он выполняет. Здесь я придерживаюсь принципа из S.O.L.I.D. (https://habr.com/ru/articles/811305/) “Принцип единственной ответственности (single responsibility principle)”. «Каждый класс должен отвечать только за одну зону ответственности (действий)». Исходя из этого можно выделить один или несколько классов и передать обязанности в них, перенеся соответствующие переменные и методы. Либо разбив класс на наследника/родителя. Например, класс собирает данные и печатает отчет. Нужно разделить на 2 класса: сбор данных в одном, а печать отчета в другом. Если класс сбора данных раздуется, то можно посмотреть на него: наверняка сбор одних данных можно перенести в один класс, сбор других в другой, а аккумулирование всех данных в третий.

3. Переименование метода (переменной/класса) (Rename Method/Variable/Class). Имя метода (переменной/класса) должны обозначать ровно то, что они делают, ни больше ни меньше. Если, например функция называется findVend, то она только должна искать поставщика, а не его проводки и пр. Здесь нужно придерживаться принципов «самодокументируемого кода» (https://habr.com/ru/articles/458264/). Если имя придумано удачно, то к нему не потребуются дополнительные комментарии, пояснения. Мартин Фаулер писал: «Создание хороших имен — это искусство, требующее практики; овладение этим искусством — важный шаг на пути к превращению в действительно хорошего программиста.»

Представьте, что вы начинаете реализовывать какой-то функционал. Создаете несколько классов и начинаете накидывать туда переменные и методы. С течением времени количество методов разрастается, они становятся все более большими. Допустим, что, находясь на каком-то этапе разработки вам поручают добавить в этот функционал что-то еще. Вы вклиниваете код в существующие функции существующего класса: функции разрастаются, класс разрастается и в результате получается какой-то монстр с распухшими функциями и что-то новое добавить все труднее и труднее. Вы думаете, что это все, но вам приносят все новые и новые ТЗ. А вклинивать уже некуда там и так бардак. Что здесь можно сделать? Посмотрите на класс, придумайте как разделить его. Скорее всего его можно разделить на несколько (по обязанностям, которые он выполняет). Делайте это смело. Это окупится. Раздутые функции тоже нужно делить на небольшие. А лучше выделять новые классы и функции сразу при добавлении функционала. И названиям классов, функций, переменных давать точные имена. В результате вместо раздутых классов, которые делают всё подряд получится множество небольших, компактных классов с небольшими функциями и осмысленными названиями всех артефактов. И потом опять можно их раздувать (шутка).

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