Здравствуйте, IQuerist, Вы писали:

Просьба цитировать только то, что надо для понимания ответа (обычно это одна фраза). Наличие строчки "VD>Здравствуйте, IQuerist, Вы писали:" уже говорит о наплевательском отношении к цитированию.

IQ>Соотнося это с реальной жизнью — академический рефакторинг это запланированные изменения кода, которые вряд ли когда то будут произведены

Ну, вот представляешь? Некоторые таки делают рефакторинги отдельно от прочих изменений. А рефакторинг в процессе правки — это грубейшее нарушение техпроцесса кодирования. В этом случае никак невозможно проверить качественность рефакторинга, так как поведение программы меняется.

Если ты уже начал менять код и вдруг понял, что для дальнейшей работы нужен рефакторинг, то можно закомитить текущее положение дел с комментом "Some feature. WIP", сделать рефакторинг и продолжить работу над фичей. Как вариант — сделать сташ, произвести рефакторинг и, затем, сделать ансташ. Ну, или доделать фичу и потом уже сделать рефакторинг.

IQ>Имхо в академическом определении есть подмена (возможно издержки перевода) — когда вы пилите код вы можете увидеть очевидную необходимость рефакторинга и его цель, т.к. вы "в контексте". Когда вы код не пилите, контекста нет... остаются лишь "благие намерения".

Ни кто не обещал, что будет просто. Потому то кухарки и не занимаются программирование. И как я уже сказал, всегда есть исключения, когда проще нарушить правило, чем возиться с мерджами измененного кода. Но эталоном является то что я описал. И в принципе у высококлассных программистов это получается.

Вот, например, коммиты в нашем проекте — Nitra: https://github.com/rsdn/nitra/commits/master
Большинство коммитов атомарные. Только на второй странице можно встретить объединенный коммит.

IQ>Теоретическую мотивацию разделения рефакторинга и прочих изменений я конечно понимаю, но в реальности это имхо очень похоже на эскапизм, впрочем имхо в современной разработке очень много эскапизма...

В реальности нужно учиться работать мелкими изменениями и стараться это делать. Со временем все начнет получаться. Иногда это кажется перебором, так как несколько усложняет жизнь. Но потом, когда приходится искать проблемы в прошлых коммитах, это очень упрощает жизнь.

Ну, и надо понимать, что это только не большая часть общего набора мер по поддержанию в хорошем качестве кода большого проекта. Чтобы код не превратился в говно нужно делать много чего. Структурировать. Повышать уровень кода. Организовывать работу людей так, чтобы они не сталкивались в одном месте кода (чтобы не было кучи разруливаний при мерджах). Организовывать тестирование. И т.п.