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

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

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

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

Вот это интересно, надо будет обдумать.

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

VD>Ни кто не обещал, что будет просто. Потому то кухарки и не занимаются программирование.

Давным давно программируют даже индусы...

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

Имхо специалисты не нарушают правил, т.к. они понимают, когда правила работают, а когда не работают.

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

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

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

Это да.

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

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

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

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

Вот это интересно, надо будет обдумать.

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

VD>Ни кто не обещал, что будет просто. Потому то кухарки и не занимаются программирование.

Давным давно программируют даже индусы...

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

Имхо специалисты не нарушают правил, т.к. они понимают, когда правила работают, а когда не работают.

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

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

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

Это да.