Здравствуйте, landerhigh, Вы писали:
L>·>Так сколько дней? Неделя, как в начале топика и с тем же результатом? L>Неважно сколько. Важно, что это ни разу не пара дней, и в эти ни разу не пару дней в твоей конкретной ветке проект если и собирается, то не работает.
Это уже лучше. Как минимум — собирается и позволяет запускать тесты. И нужно понимать, что ветка живущая дольше нескольких дней — плохая идея для активно развивающегося проекта.
L>·>Зачем ломать существующий код? Почему нельзя написать новый рядом? L>А почему бы тогда вообще все не переписать с нуля?
Тоже как вариант, если масштаб изменений достаточно большой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, GarryIV, Вы писали:
GIV>Вот не ожидал, что так массово не собирается по три дня. Может у вас какое-то другое пониммание термина "не собирается"?
Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.
Здравствуйте, kaa.python, Вы писали:
KP>Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.
Более простой и имхо часто встречающийся пример — миграция огромного проекта с Visual Studio 6.0 на более современную версию, когда уже совсем приперло. Думаю, через такое проходили все плюсисты.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, kaa.python, Вы писали:
KP>>Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.
L>Более простой и имхо часто встречающийся пример — миграция огромного проекта с Visual Studio 6.0 на более современную версию, когда уже совсем приперло. Думаю, через такое проходили все плюсисты.
как часто в своем проекте ты мигрируешь гигабайтный проект с вижуал студио 6 на С++11 ?
зачем вы цепляетесь за какие-то исключительные случаи ?
L>>Более простой и имхо часто встречающийся пример — миграция огромного проекта с Visual Studio 6.0 на более современную версию, когда уже совсем приперло. Думаю, через такое проходили все плюсисты. J>как часто в своем проекте ты мигрируешь гигабайтный проект с вижуал студио 6 на С++11 ?
Достаточно и одного раза.
J>зачем вы цепляетесь за какие-то исключительные случаи ?
Вообще-то инженерам платят именно за нахождение решений в исключительных случаях. Рутинной работой занимаются кодеры и техподдержка.
Здравствуйте, John1979, Вы писали:
J>как часто в своем проекте ты мигрируешь гигабайтный проект с вижуал студио 6 на С++11 ? J>зачем вы цепляетесь за какие-то исключительные случаи ?
Да бывают не исключительные, к примеру сегодня заменил Json подобный протокол с кучей констант на Protobuf в одной из частей проекта. Работал с прошлой пятницы, комит чего-то минимально осмысленного сделал только сегодня под вечер.
Здравствуйте, landerhigh, Вы писали:
L>Достаточно и одного раза.
достаточно для чего ?
L>Вообще-то инженерам платят именно за нахождение решений в исключительных случаях. Рутинной работой занимаются кодеры и техподдержка.
пальцы растопырить забыл.
Здравствуйте, kaa.python, Вы писали:
KP>Да бывают не исключительные, к примеру сегодня заменил Json подобный протокол с кучей констант на Protobuf в одной из частей проекта. Работал с прошлой пятницы, комит чего-то минимально осмысленного сделал только сегодня под вечер.
и ты возьмешься утверждаешь, что это нельзя было сделать итеративно ? (оставим за скобками оверхид)
Здравствуйте, Sammo, Вы писали:
S>Есть сроки по задаче, он под ними подписался? Его вина? Тогда его проблемы.
А это с какого перепугу?
Если он — простой наемный работник, тогда это проблемы работодателя.
Вот был бы субподрядчиком — другой вопрос.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Насчет работы говорить не буду, но своим студентам на первом занятии я говорю примерно следующее. PD>Если за неделю до зачета Вы ко мне придете и скажете, что написали все как следует, но вот, увы, все пропало, я Вам искренне посочувствую, но предложу начать сначала.
Это другое.
Если фрилансер мне будет рассказывать, что у него накрылся диск — это его проблемы. Я ему посочувствую, но денег не заплачу.
Если при ремонте квартиры строитель будет рассказывать что он испортил материал — это его проблема. Я ему даже сочувствовать не буду и штрафану на стоимость материала.
Они несут все риски, но при этом получают всю прибыль.
Но штрафовать штатного сотрудника (временем или деньгами), чтобы компенсировать конторе убытки — неверно. Контора же не делится процентом прибыли? Ну так пусть и убытками не делится.
Здравствуйте, kaa.python, Вы писали:
GIV>>Вот не ожидал, что так массово не собирается по три дня. Может у вас какое-то другое пониммание термина "не собирается"? KP>Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.
Это у вас какой-то полудохлый проект с одним разработчиком, похоже. Видимо, было допустимо на целый месяц остановить разработку текущей версии и потратить столько времени на миграцию.
Серьёзные проекты в таком случае перетаскивают по кусочкам: потихоньку модицифируют код, вставляя какие-нибудь #ifdef/etc чтобы он начал собираться и работать под обе версии плюсов, потом вычищают старую, если надо. Да, такое может занять два месяца, но риски гораздо ниже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kaa.python, Вы писали:
KP>Я и делаю итеративно. Минимальная осмысленного итерация заняла 4 дня
мне, конечно, со стороны не видно, но неужели нельзя было отгородиться интерфейсами и потом просто заменить прокладку с json на протобуфер ?
Здравствуйте, John1979, Вы писали:
J>мне, конечно, со стороны не видно, но неужели нельзя было отгородиться интерфейсами и потом просто заменить прокладку с json на протобуфер ?
Можно было, но заработало бы к концу следующей недели, а так работает уже сегодня.
Здравствуйте, ·, Вы писали:
·>Это у вас какой-то полудохлый проект с одним разработчиком, похоже. Видимо, было допустимо на целый месяц остановить разработку текущей версии и потратить столько времени на миграцию.
Этот "полудохлый" проект был изрядной частью кодовой базы Антивируса Касперского. К счастью не весь, а только macOS и кроссплатформенная части.
·>Серьёзные проекты в таком случае перетаскивают по кусочкам: потихоньку модицифируют код, вставляя какие-нибудь #ifdef/etc чтобы он начал собираться и работать под обе версии плюсов, потом вычищают старую, если надо. Да, такое может занять два месяца, но риски гораздо ниже.
При таком подходе смешивались два рантайма: libcpp и libc++, что недопустимо.
Так что я бы не стал дальше на твоем месте тут пальцы гнуть и про серьезные проекты говорить.
Здравствуйте, kaa.python, Вы писали:
KP>Можно было, но заработало бы к концу следующей недели, а так работает уже сегодня.
об чем и спич, т.е. принципиально это возможно.
в некоторых ситуациях правильнее сделать все как можно более мелкими итерациями, в некоторых можно на это забить и все разломать на неделю/месяц.
я стараюсь придерживаться первого пути, но второе тоже случается. однако я считаю второй путь годным для исключительных ситуаций.
Здравствуйте, John1979, Вы писали:
J>в некоторых ситуациях правильнее сделать все как можно более мелкими итерациями, в некоторых можно на это забить и все разломать на неделю/месяц.
Так то что разломано — оно же никого кроме меня не затронуло, живет себе в отдельной ветке и кушать не просит. Зачем мне увеличивать свою работу в два раза? Тем более что при миграциях с одной технологии на другую зачастую приходится что-то переделывать так как первая идея оказывается не верной и требует доделки или модификации.
Я тоже за итеративные изменения, просто нет ничего страшного в том, что длинна итерации составляет одну неделю. Зачем привязывается к одному или двум дням?
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, Pavel Dvorkin, Вы писали:
G>Если фрилансер мне будет рассказывать, что у него накрылся диск — это его проблемы. Я ему посочувствую, но денег не заплачу. G>Но штрафовать штатного сотрудника (временем или деньгами), чтобы компенсировать конторе убытки — неверно. Контора же не делится процентом прибыли? Ну так пусть и убытками не делится.
Мне не совсем ясно, в чем разница. А если фрилансер (да хоть кто угодно) принят на срочный договор ? В штате числится, но временно. Контракт на 4 месяца, 3 из них уже прошло, зарплату ему за них платили. А если он принят на договор, но на конкретную работу, без срока ? Где граница ?
Здравствуйте, kaa.python, Вы писали:
KP>·>Серьёзные проекты в таком случае перетаскивают по кусочкам: потихоньку модицифируют код, вставляя какие-нибудь #ifdef/etc чтобы он начал собираться и работать под обе версии плюсов, потом вычищают старую, если надо. Да, такое может занять два месяца, но риски гораздо ниже. KP>При таком подходе смешивались два рантайма: libcpp и libc++, что недопустимо.
Что значит "смешивались"? Просто один и тот же исходник проекта собирается разными компиляторами. Для С/С++ мира это заурядное явление, ничего ни у кого не смешивается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kaa.python, Вы писали:
KP>Так то что разломано — оно же никого кроме меня не затронуло, живет себе в отдельной ветке и кушать не просит. Зачем мне увеличивать свою работу в два раза?
если увеличит в 2 раза, то это, конечно, повод задуматься. в такой ситуации, возможно, проще забить и сломать.
но в общем случае, ведь это потом кому-то ревьювить. лично мне такие атомарные ревью даются гораздо проще и жрут меньше времени.
KP>Зачем привязывается к одному или двум дням?
упрощение процесса. я не молюсь на какие-то догмы, но если за счет увеличения сроков на 30% удастся в разы уменьшить его сложность — почему нет ?
