Здравствуйте, landerhigh, Вы писали:
L>Везет же людям. Рефакторинг, который можно проводить точечными изменениями, среда со средствами для рефакторинга. L>Ручками, все ручками. Разбивать зависимости, кромсать универсальные всемогуторы и выжигать статические переменные. Точечными изменениями тут уже не поможешь, тут ковровая бомбардировка нужна.
когда я был молод и горяч, я рассуждал в том-же ключе. но однажды коллега убедил меня попробовать технику малых изменений с поддержанием кода не только в компилируемом, но и в рабочем состоянии.
с тех пор жить мне стало на порядок проще.
а уж на сколько порядков проще стало тем, кто ревьювит эти рефакторинги...
Здравствуйте, John1979, Вы писали:
L>>Везет же людям. Рефакторинг, который можно проводить точечными изменениями, среда со средствами для рефакторинга. L>>Ручками, все ручками. Разбивать зависимости, кромсать универсальные всемогуторы и выжигать статические переменные. Точечными изменениями тут уже не поможешь, тут ковровая бомбардировка нужна. J>когда я был молод и горяч, я рассуждал в том-же ключе. но однажды коллега убедил меня попробовать технику малых изменений с поддержанием кода не только в компилируемом, но и в рабочем состоянии.
Здравствуйте, landerhigh, Вы писали:
L>Это позавчера что ли?
это много лет назад.
L>Задачи и проблемы вообще-то бывают разные.
ну да, один ты уникальные вещи решаешь.
кстати, реальный пример задачи, которую невозможно решить 'не по книжке', ты так и не привел.
Здравствуйте, alzt, Вы писали:
A>Ещё зависит от задач. Иногда бывает полезным написать что-то за неделю, посмотреть на результат, поэкспериментировать. Потом выкинуть весь код и написать заново.
Таки результат эксперимента, в том числе код, лучше всего сохранить где-то. Мало ли.
Здравствуйте, Silver_S, Вы писали:
S_S> Я тоже однажды похерил результаты нескольких дней. В древние времена SourceSafe — точно не помню, второпях не внимательно прочитал вопрос в диалоге, из-за не правильного ответа безвозвратно откатилось назад(похерилось), ... S_S> Это тоже попадает под статью?
Конечно попадает. Внедрение SourceSafe — это явное вредительство
Здравствуйте, ·, Вы писали:
L>>И это магическим образом заставит код собираться, да? ·>Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать. ·>Понимаю ещё, что начал что-то делать, разломал всё, потом тебя отвлекли на митинг, а потом уже домой надо.
Твой кусок собирается. Проект в целом с твоим куском не собирается.
Здравствуйте, Serg27, Вы писали:
SO>>Ежедневный (ночной) бекап рабочих машин — не очень хорошее решение.
S>Переведи! (с) S>Мнение интересное и, наверное, требует объяснения.
Сразу оговорюсь, что комментарий идёт в контексте темы (неиспользование репозитория).
Как по мне — работа с системой контроля версий для программиста, это что-то сродни гигиене. Надо чуть-чуть привыкнуть, а далее сплошной профит и отсутствие головняка. Бекап репозитория делается просто и занимает относительно немного времени. Причём, сложностей с этой задачей наверняка не будет.
Бекап _всех_ рабочих машин, это:
1. Выбор технических средств.
2. Настройка и отладка.
3. Контроль и исправление случающихся ошибок.
Т.е. этой задачей придётся целенаправленно заниматься и уделять ей время постоянно.
Далее, бекап всегда будет занимать _много_ времени и требовать _много_ места на внешнем хранилище. Как следствие решение будет не очень хорошо масштабироваться.
На контроле придётся постоянно держать предел для такого решения, который может быть достигнут довольно быстро в случае роста числа пользователей. Ну и стоимость решения надо считать внимательно. Отдельный вопрос — рост объёма информации на дисках пользователей. Ещё один отдельный вопрос — пропускная способность сети.
Самое главное. Профита от восстановления _каждого_ рабочего места разработчика будет совсем немного. С учётом использования системы контроля версий — так вообще никакой.
Здравствуйте, Pzz, Вы писали:
L>>>И это магическим образом заставит код собираться, да? Pzz>·>Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать. Pzz>·>Понимаю ещё, что начал что-то делать, разломал всё, потом тебя отвлекли на митинг, а потом уже домой надо. Pzz>Твой кусок собирается. Проект в целом с твоим куском не собирается.
Неужели это обнаруживается только на третий день?!
Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Pzz, Вы писали:
Pzz>>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня? ·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит.
А это зачем? Или это сленг такой?
·>Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.
Бекап разработчик должен оставлять/делать или администратор?
Здравствуйте, John1979, Вы писали:
L>>Задачи и проблемы вообще-то бывают разные. J>ну да, один ты уникальные вещи решаешь.
У меня тоже складывается такое мнение. Пока все гномиков сортируют, некоторым и работать приходится
J>кстати, реальный пример задачи, которую невозможно решить 'не по книжке', ты так и не привел.
Здравствуйте, ·, Вы писали:
Pzz>>Твой кусок собирается. Проект в целом с твоим куском не собирается. ·>Неужели это обнаруживается только на третий день?!
Что значит "обнаруживается"? Это было известно с самого начала.
·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.
Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.
J>>кстати, реальный пример задачи, которую невозможно решить 'не по книжке', ты так и не привел. L>Покажи, где я что-то говорил про книжки.
пардон, это был не ты.
Здравствуйте, landerhigh, Вы писали:
L>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.
вносил, делается это за много шагов, но результатом каждой итерации у тебя работающий результат.
обычно эта зависимость не является единственной проблемой этого говнокода, поэтому сначала ты рефакторишь совсем не часть завязанную на глобальный объект, попутно подготавливая почву для отвязки от него.
Здравствуйте, ·, Вы писали:
Pzz>>Твой кусок собирается. Проект в целом с твоим куском не собирается. ·>Неужели это обнаруживается только на третий день?!
Нет, немного другая ситуация.
Ты изолируешь проблему, и пытаешься ее починить для начала локально. Сознательно наплевав на то, что какие-то части проекта будут сломаны. Потом, если локальный ремонт достиг успеха, ты уже либо приведешь остальные части проекта в соответсвие, либо придумаешь, как сделать то же самое, сохранив совместимость (что может быть достаточно сложно). Но для начала тебе надо разобраться с тем, зачем ты вообще туда полез.
·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.
Я сам люблю все делать инкрементально. Но иногда "резать к чертовой матери" оказывается очень существенно делевле, чем инкрементально.
Здравствуйте, John1979, Вы писали:
L>>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал. J>вносил, делается это за много шагов, но результатом каждой итерации у тебя работающий результат.
Не, не, речь была об одном инкрементальном изменени. "Много шагов" — это уже неувязочка.
J>обычно эта зависимость не является единственной проблемой этого говнокода, поэтому сначала ты рефакторишь совсем не часть завязанную на глобальный объект, попутно подготавливая почву для отвязки от него.
Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым.
Здравствуйте, landerhigh, Вы писали:
L>Не, не, речь была об одном инкрементальном изменени. "Много шагов" — это уже неувязочка.
бинарная логика детектед.
речь шла о поддержании проекта в :
— компилябельном
— рабочем
состояниях.
одно инкрементальное изменение гарантирует тебе оба пункта.
о том, что ты одним изменением фикснешь весь говнокод никто не говорил.
L>Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым.
собирается, работает и смысл есть.
при этом ревьюверу проще
при этом такой рефакторинг в огромных проектах может растянуться на месяцы, уделяться ему может 10-20% времени.
в результате у тебя и проект не стоит на месте, и при этом конюшни помаленьку чистятся.
L>>Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым. J>собирается, работает и смысл есть.
Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде
