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

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

IQ>>Подскажите плиз годный материал по теме. Какой должна быть стратегия, чтобы частые комиты не мешали, а помогали?

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

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

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

IQ>Это понятно, в части (кстати эта часть больше половины или меньше) случаев все довольно очевидно... Но, например, при хорошей такой загрузке рефакторинг имхо часто происходит в рамках реализации фичи

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

IQ>или исправления бага иначе его просто годами откладывают на потом. Баги нередко тоже исправляются "гроздьями". Напрашивается забавное название для стратегии — атомизация изменений.

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

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

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

IQ>>Это понятно, в части (кстати эта часть больше половины или меньше) случаев все довольно очевидно... Но, например, при хорошей такой загрузке рефакторинг имхо часто происходит в рамках реализации фичи

VD>По определению рефакторинг: "процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это да.

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

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

100% работающая практика. Просто надо сразу помнить об этом и видя, что нужен рефакторинг не начинать его делать в незакомиченном коде. Лучше разорвать коммит по фиче на два и вставить между ними коммит с рефакторингом.

IQ> Да ладно, программируют уже даже индусы...

1. Среди индусов есть неплохие программисты.
2. Индокод он и есть индокод. И не важно написал его индус или русский с руками из жопы.

Даже в коде хороших программистов другому разобраться не просто (нет тучи деталей, которые надо знать). А уж в индокоде разобраться вообще не реально. Такой код проще переписать.

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

Тут не причем "работают/не работают". Тут вопрос в том, что люди не святые и нельзя все просчитать на 100%. Плюс иногда правильный путь создает слишком много проблем и проще забить на правильность, чем тратить море сил на не очень важные вещи.

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

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