Здравствуйте, gandjustas, Вы писали:
G>Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
Мне с ужасным кодом доводилось очень много работать. В таких случаях делаю следующее:
1) В процессе внеседия изменений НИКОГДА не допускаю, чтобы в результате моих правок код еще более усложнялся. Если метод на 1000 строк — свой код выношу в отдельный метод, и вызываю из ужасного. Иногда делаю косметические изменения в ужасном коде рядом с моими правками, могу там еще коммент добавить перед вызовом. Часто вместе с моими правками выношу часть кода старого класса в отдельный метод, по мелочи удаляю copy-paste, если править одно и тоже приходится в нескольких местах. Основную цель преследую — чтобы хаос не увеличился, а по возможности уменьшился. Переписывать мне даже один метод лень, за это мне не заплатят, а на себя беру до черта рискоа — если что сломается — виноват буду я;
2) Если я в этот класс еще начинаю лезть раз 5 из-за постоянно всплывающих там багов — начинаю более сильный рефакторинг этого класса. Логику часто не меняю, рефакторинг преследует цель разобраться как работает код, а не переписать все. Просто тупо дроблю огромный метод на более мелкие. Пишу комментарии к каждому методу, чтобы отследить все тонкости работы. Пишу комментарий к классу — что за класс, зачем служит, какие параметры принимает и т.д. Иногда шаг 2 предшествует шагу 1, в этом случае результаты рефакторинга даже не сохраняю, если вдруг что-то порушил по невнимательности, а времени на поиск причины нет, как правило в процессе рефакторинга я нахожу место, где внести исправления и исправляю локально.
3) Если в процессе рефакторинга на шаге 2 я начал полностью понимать логику, и нахожу, что ошибка уже в алгоритме — делаю еще один рефакторинг, более похожий на переписывание. Уже меняю логику работы, спорные моменты оставляю.
4) Если возможно — предварительно пишу тесты. Мой класс против старого, на вход подаю одно и тоже, на выходе проверяю, что все совпадает. К сожалению редко так получается, код часто такой, что тесты написать практически невозможно за приемлемое время.
Здравствуйте, gandjustas, Вы писали: G>Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
Начальник правильно делает.
Если это класс работы с железом, то там _могут_ _быть_ неочевидные (не поддающиеся логическому объяснеию) элементы (задержки, вставки пустых байт, последователнтсти запросов и т.д.) которые есть резултат старого опыта и "большого траха". Поскольку они "не следуют из логики", вы их наверняка потеряете при переписывании. И начнете круг "большого траха" по новой. Особенно это касается российского "железа", но и западного тоже.
Не надо никого убеждать. Выполняйте поставленную задачу — так, как сказал начальник. Возможно, он знает что-то, чего не знаете вы. В любом случае, ему надо сообщить своё мнение, но если он настаивает на своём — выполняйте.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
Хочется-не хочется, а при такой организации сначала правильнее будет накатить мелкий патч или сделать откат к старым версиям у клиентов, чтобы выиграть время для существенных исправлений. Возможно, ваш начальник не договаривает насчёт дальнейших планов?
(одно "но": исходя из описаний могу предположить, что ваша контора относится к тому типу, для которого рациональные пути решения проблем вряд ли будут правильными, а потому лучше тупо делать, как велит начальник, а если совсем невмоготу, увольняться с надеждой на лучшее)
Здравствуйте, Daevaorn, Вы писали:
G>>Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
D>Ну так перепеши. Начальник что, изучает каждый раз код табою написанный? Ему важен результат скорей всего.
IMHO, такая линия поведения называется словом "саботаж"
Здравствуйте, gandjustas, Вы писали:
G>На работе получилась такая ситуация: после обновления программы у клиентов начали появляться ошибки (зависимые от оборудования, у себя протестировать не могли). Мне удалось обнаружить ошибку. Для её устранения потребуется переписать один класс. Класс был написан (правильнее сказать "рожден в мучениях") два года назад, комментариев ноль, автор уже уволился, короче рефакторинг делу не поможет. И все бы ничего, но надо это сделать быстро, желательно до конца недели.
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
IMHO, ваш начальник прав. спрашивайте клиента, ищите исходники...
"Переписать все" — типовая ошибка, ее последствия обычно еще хуже.
Хотя в вашем конкретном случае все может быть и по-другому.
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, gandjustas, Вы писали: G>>Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
И он прав. Вы видете только кривой код, а он видит больше. Исправить код не проблема, но чем больше вы внесете изменений, тем больше нужно будет перетестировать и перепроверять. Переписать 1000 строк кода — гарантированно получить десяток ошибок. Их нужно будет исправлять и снова тестировать. И не говорите что вы такой гениальный, что пишете код без ошибок и перепишете эту тысячу без проблем. Так не бывает. Внесение точечных изменений — правильный подход. Переписать все можно только при запасе времени на полное перетестироание системы, а при работе с железом — так еще и проверки что у всех клиентов ничего не сломалось.
На работе получилась такая ситуация: после обновления программы у клиентов начали появляться ошибки (зависимые от оборудования, у себя протестировать не могли). Мне удалось обнаружить ошибку. Для её устранения потребуется переписать один класс. Класс был написан (правильнее сказать "рожден в мучениях") два года назад, комментариев ноль, автор уже уволился, короче рефакторинг делу не поможет. И все бы ничего, но надо это сделать быстро, желательно до конца недели.
Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
Здравствуйте, gandjustas, Вы писали:
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
ну так делай вид что ищешь. потом скажи что никаких версий нету
Здравствуйте, gandjustas, Вы писали:
bnk>>IMHO, такая линия поведения называется словом "саботаж" G>И в чем саботаж то заключается? В любом случае ошибка будет исправлена, подход разный.
Будет исправлена только та ошибка, из-за который затеяли переписывание. И будет добавлено еще штук 5-10 новых, которые вылезут чуть позже. Оно, конечно, можно думать, что иначе и нельзя, но вообще вот так запросто переписать тыщу строк кода и быть уверенным что сделал точно не хуже — это пионерство.
Здравствуйте, gandjustas, Вы писали:
G>В итоге я так и не нашел иходники версии, которая стояла у клиентов и класс пришлось переписывать. Но обошелся "малой кровью", примерно 300 строк переписал, лениво было переделывать все.
Здравствуйте, 0rc, Вы писали:
0rc>Зачем? Вы ведь сами сказали, что ошибки возникли в следствии обновления программы.
В новой версии содержатся новые отчеты, необходимые клиентам. Короче надо исправить ошибку надо по-любому и быстро. А вот в методах мы с начальником разошлись.
Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
Здравствуйте, bnk, Вы писали:
bnk>IMHO, ваш начальник прав. спрашивайте клиента, ищите исходники... bnk>"Переписать все" — типовая ошибка, ее последствия обычно еще хуже. bnk>Хотя в вашем конкретном случае все может быть и по-другому.
Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, bnk, Вы писали:
bnk>>IMHO, ваш начальник прав. спрашивайте клиента, ищите исходники... bnk>>"Переписать все" — типовая ошибка, ее последствия обычно еще хуже. bnk>>Хотя в вашем конкретном случае все может быть и по-другому.
G>Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
Ну так перепеши. Начальник что, изучает каждый раз код табою написанный? Ему важен результат скорей всего.
Здравствуйте, bnk, Вы писали:
bnk>IMHO, такая линия поведения называется словом "саботаж"
И в чем саботаж то заключается? В любом случае ошибка будет исправлена, подход разный.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, bnk, Вы писали:
bnk>>IMHO, такая линия поведения называется словом "саботаж" G>И в чем саботаж то заключается? В любом случае ошибка будет исправлена, подход разный.
вообще-то это "цитата" была
- Gentlemen, I've completed my report on the crash.
— Whoa! I'm not reading that crap. Summarise it in one word.
— Sabotage!
А имел я в виду то, что без согласования с начальником делать по-своему не есть хорошая идея (в общем случае).
Здравствуйте, gandjustas, Вы писали:
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
Здравствуйте, gandjustas, Вы писали:
G>На работе получилась такая ситуация: после обновления программы у клиентов начали появляться ошибки (зависимые от оборудования, у себя протестировать не могли). Мне удалось обнаружить ошибку. Для её устранения потребуется переписать один класс. Класс был написан (правильнее сказать "рожден в мучениях") два года назад, комментариев ноль, автор уже уволился, короче рефакторинг делу не поможет. И все бы ничего, но надо это сделать быстро, желательно до конца недели.
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
гм... я прочитал правильное замечание "трофимова", потому ответы только на вопрос.
убедить начальника, что это делать не хочется просто. надо сказать, что ты не хочешь это делать. он поверит.
то, что переписать "это" проще — убедить начальника сложнее. для этого надо сделать:
1) написать план переписывания.
2) написать план тестирования.
3) написать план накатывания обновленной версии для всех пользователей.
4) не забыть включить время для исправления при тестировании и для исправления после деплоймента.
5) все это собрать в одно письмо, и оправить в адрес начальника. можно сделать сс на другого начальника или на одного из представителей заказчика. в письме мотивировано обьяснить, чем это лучше, и к чему приведет в дальнейшем. если начальник "технически правильный" — можно вложить код с подробным коментарием.
для демонстрации разницы:
1) написать план исследования клиентов
2) написать план работы с изменениями у клиентов.
3) указать количество разных систем и возможные проблемы адаптации под системы.
4) сравнить планы по времени и ресурсам.
...тока... оно тебе надо?!..
может быть, что ты зарабатываешь от времени "на клиенте" больше.
AE>Если это класс работы с железом, то там _могут_ _быть_ неочевидные (не поддающиеся логическому объяснеию) элементы (задержки, вставки пустых байт, последователнтсти запросов и т.д.) которые есть резултат старого опыта и "большого траха". Поскольку они "не следуют из логики", вы их наверняка потеряете при переписывании. И начнете круг "большого траха" по новой. Особенно это касается российского "железа", но и западного тоже.
Такие "неочевидные" элементы в большинстве случаев результат невнимательного чтения спеки, наивного подхода к решению проблем или криворукой оптимизации. Поскольку "цикл большого траха" обычно проходит в темпе гопака с чечеткой, разбираться в причинах ошибки, а уж тем более читать документацию недосуг. Вот и получается корявый код, изобилующий никак не отмеченными хаками, в котором никто не способен разобраться.
Miroff пишет: > Такие "неочевидные" элементы в большинстве случаев результат > невнимательного чтения спеки, наивного подхода к решению проблем или > криворукой оптимизации. Поскольку "цикл большого траха" обычно проходит > в темпе гопака с чечеткой, разбираться в причинах ошибки, а уж тем более > читать документацию недосуг. Вот и получается корявый код, изобилующий > никак не отмеченными хаками, в котором никто не способен разобраться.
Единственное, с чем я согласен с Вами, так это с Вашим "наивным подходом
к решению проблем".
Здравствуйте, Трофимов, Вы писали:
Т>2All: Человек спрашивает "Как убедить начальника?", а ему как всегда отвечают "Купите Windows 98!".
Да уж, никто так и не сказал как убедить начальника... как-будто никому никогда не приходилось этого делать.
В итоге я так и не нашел иходники версии, которая стояла у клиентов и класс пришлось переписывать. Но обошелся "малой кровью", примерно 300 строк переписал, лениво было переделывать все.
Здравствуйте, gandjustas, Вы писали:
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
Все-таки ты знаешь где ошибка или нет? Если знаешь, то почему тебя отправляют к клиентам ее искать. Если нет, то почему ты выбрал какой-то рандомный класс и хочешь его переписать?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, the_dip, Вы писали:
G>>В итоге я так и не нашел иходники версии, которая стояла у клиентов и класс пришлось переписывать. Но обошелся "малой кровью", примерно 300 строк переписал, лениво было переделывать все. _>300 строк за сутки?
Если знаешь что делаешь и фигачишь проверки и прочие ассерты пачками, то 100 строк в час — совсем не рекорд. Строки — они разные бывают, помни о Маяковском
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, bnk, Вы писали:
bnk>>IMHO, такая линия поведения называется словом "саботаж" G>И в чем саботаж то заключается? В любом случае ошибка будет исправлена, подход разный.
Здравствуйте, Anatolix, Вы писали:
A>Все-таки ты знаешь где ошибка или нет? Если знаешь, то почему тебя отправляют к клиентам ее искать. Если нет, то почему ты выбрал какой-то рандомный класс и хочешь его переписать?
Я знал почему ошибка происходит, но не знал где находтся коды вызывающий ошибки. Учитывая что код был написан активно применяя технологию "copy&paste", таких мест могло оказаться много.
А начальник давал такие указания, потому что так он видит процесс исправления ошибок.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, 0rc, Вы писали:
0rc>>Зачем? Вы ведь сами сказали, что ошибки возникли в следствии обновления программы.
G>В новой версии содержатся новые отчеты, необходимые клиентам. Короче надо исправить ошибку надо по-любому и быстро. А вот в методах мы с начальником разошлись.
G>Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
Он, видимо, не первый год начальник просто.
Моменты:
1. большинству программистов свойственно переоценивать свои возможности. "Все переписать, делов-то — 2 дня" часто выливается в 2 месяца.
2. код старый, недокументированный, и не твой. Есть немалая вероятность существования неочевидных моментов(в просторечии, костылей), которые перестанут работать после переписывания этого куска, а проявиться это может не сразу.
Это не значит, что твой путь неправильный. Просто в этом случае без знания конкретной ситуации советы могут быть вредными.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
G>ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
СКОЛЬКО??????
Я бы в порядке багфикса видел в страшном сне переписавыние таких классов.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Alex EXO, Вы писали:
AE>Начальник правильно делает. AE>Если это класс работы с железом, то там _могут_ _быть_ неочевидные (не поддающиеся логическому объяснеию) элементы (задержки, вставки пустых байт, последователнтсти запросов и т.д.) которые есть резултат старого опыта и "большого траха". Поскольку они "не следуют из логики", вы их наверняка потеряете при переписывании. И начнете круг "большого траха" по новой. Особенно это касается российского "железа", но и западного тоже.
+++
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
AE>>Если это класс работы с железом, то там _могут_ _быть_ неочевидные (не поддающиеся логическому объяснеию) элементы (задержки, вставки пустых байт, последователнтсти запросов и т.д.) которые есть резултат старого опыта и "большого траха". Поскольку они "не следуют из логики", вы их наверняка потеряете при переписывании. И начнете круг "большого траха" по новой. Особенно это касается российского "железа", но и западного тоже.
M>Такие "неочевидные" элементы в большинстве случаев результат невнимательного чтения спеки, наивного подхода к решению проблем или криворукой оптимизации. Поскольку "цикл большого траха" обычно проходит в темпе гопака с чечеткой, разбираться в причинах ошибки, а уж тем более читать документацию недосуг. Вот и получается корявый код, изобилующий никак не отмеченными хаками, в котором никто не способен разобраться.
Счастливый человек, верит в святую точность спек к девайсам
Рекомендую пописать(ударение на последний слог, хотя я часто думал о другом варианте) под китайские принтеры.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
