Чистка и рефатокторинг кода — это гиковская забота о себе. Можно её не делать, но с ней чувствуешь себя лучше.

Самая большая часть «стоимости» при работе с кодом в его чтении и понимании, а не в написании. Когда вы пишите код, вы не только пишете инструкцию компьютеру, но скорее объясняете свои намерения компьютеру для других людей. Просто написать код для компьютера, который будет работать, не особо интересная конечная цель. В хаотично написанный код довольно быстро станет трудно вносить изменения из-за многочисленных связей (часто неявных) между его элементами и сущностями.

Если думать о себе как о писателе, код которого будут изучать читатели, то можно и приводить в код в порядок с этой же мыслью: делать код из запутанного более понятным, единообразным, раскладывать по коду «подсказки» для его понимания, упорядочивать последовательность «повествования» кода. Всегда можно прикинуть, как будет код читаться, ведь каждый из нас читатель.

Какие вещи можно учитывать при рефакторинге

• подчистку лучше делать маленькими шагами, настолько маленькими, чтобы их было делать не страшно; небольшая подчистка — самая лучшая
• много мелких рефакторингов и подчисток дополняют друг друга и со временем становятся большой переработкой модуля или системы, за которую будут благодарны ваши коллеги
• разделение кода на мелкие части важно сделать так, чтобы это помогало пониманию; то есть если связать воедино кучу мелких несвязных сущностей, то это усложнит их понимание; а если объединить однородные сущности, то их можно без проблем вынести в отдельную упрощающую понимание абстракцию
• если собирать связанные друг с другом по смыслу и коду вещи (функции, модули, файлы) в одном месте, то нужно будет меньше держать в голове для понимания и работы с этим кодом
• «подчищающие» изменения стоит отделять от меняющего поведение в разные коммиты

Про код

• вместо того чтобы вкладывать условия друг в друга, условия проверяются в начале функции и выполнение функции прекращается, если условия не выполняются
• кусок кода, выполняющий одно понятное назначение и не сильно связанный с остальным кодом, можно вынести во внешний хелпер
• куски кода, выполняющие разные вещи, можно отделить друг от друга пустой строкой
• если в глубине кода встречается использование env-ов, лучше заменить их на явные параметры
• разросшиеся выражения лучше поделить на отдельные промежуточные части
• код про получение параметров лучше сконцентрировать в начале модуля, остальной код — после
• если объявление и инициализация переменной сильно разнесены по коду, это усложняет понимание
• если у модели есть интерфейс, который вам не нравится, можно сделать для него «фасад» — свой интерфейс, который вам нравится, а уже внутри вызывать старый интерфейс
• не выполняющийся код можно смело удалять

Про комментарии

• комментарий, который описывает дословно то, что происходит в коде, можно смело удалять
• если вы читаете файл и уловили момент, когда начали понимать, что к чему в этом файле, это ключевой момент! Можно это место/понимание зафиксировать в комменте (иногда полезно оставлять такие комменты в «шапке» файла)