На работе получилась такая ситуация: после обновления программы у клиентов начали появляться ошибки (зависимые от оборудования, у себя протестировать не могли). Мне удалось обнаружить ошибку. Для её устранения потребуется переписать один класс. Класс был написан (правильнее сказать "рожден в мучениях") два года назад, комментариев ноль, автор уже уволился, короче рефакторинг делу не поможет. И все бы ничего, но надо это сделать быстро, желательно до конца недели.
Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
Здравствуйте, gandjustas, Вы писали:
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
ну так делай вид что ищешь. потом скажи что никаких версий нету
Здравствуйте, 0rc, Вы писали:
0rc>Зачем? Вы ведь сами сказали, что ошибки возникли в следствии обновления программы.
В новой версии содержатся новые отчеты, необходимые клиентам. Короче надо исправить ошибку надо по-любому и быстро. А вот в методах мы с начальником разошлись.
Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
Здравствуйте, gandjustas, Вы писали:
G>На работе получилась такая ситуация: после обновления программы у клиентов начали появляться ошибки (зависимые от оборудования, у себя протестировать не могли). Мне удалось обнаружить ошибку. Для её устранения потребуется переписать один класс. Класс был написан (правильнее сказать "рожден в мучениях") два года назад, комментариев ноль, автор уже уволился, короче рефакторинг делу не поможет. И все бы ничего, но надо это сделать быстро, желательно до конца недели.
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
IMHO, ваш начальник прав. спрашивайте клиента, ищите исходники...
"Переписать все" — типовая ошибка, ее последствия обычно еще хуже.
Хотя в вашем конкретном случае все может быть и по-другому.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
Хочется-не хочется, а при такой организации сначала правильнее будет накатить мелкий патч или сделать откат к старым версиям у клиентов, чтобы выиграть время для существенных исправлений. Возможно, ваш начальник не договаривает насчёт дальнейших планов?
(одно "но": исходя из описаний могу предположить, что ваша контора относится к тому типу, для которого рациональные пути решения проблем вряд ли будут правильными, а потому лучше тупо делать, как велит начальник, а если совсем невмоготу, увольняться с надеждой на лучшее)
Здравствуйте, bnk, Вы писали:
bnk>IMHO, ваш начальник прав. спрашивайте клиента, ищите исходники... bnk>"Переписать все" — типовая ошибка, ее последствия обычно еще хуже. bnk>Хотя в вашем конкретном случае все может быть и по-другому.
Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, bnk, Вы писали:
bnk>>IMHO, ваш начальник прав. спрашивайте клиента, ищите исходники... bnk>>"Переписать все" — типовая ошибка, ее последствия обычно еще хуже. bnk>>Хотя в вашем конкретном случае все может быть и по-другому.
G>Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
Ну так перепеши. Начальник что, изучает каждый раз код табою написанный? Ему важен результат скорей всего.
Здравствуйте, Daevaorn, Вы писали:
G>>Абсолютно не имею желания переписывать все. Переписать реально надо ОДИН класс, 600-1000 строк кода, после переписывания объем может уменьшиться в 2 раза.
D>Ну так перепеши. Начальник что, изучает каждый раз код табою написанный? Ему важен результат скорей всего.
IMHO, такая линия поведения называется словом "саботаж"
Здравствуйте, 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>Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
Начальник правильно делает.
Если это класс работы с железом, то там _могут_ _быть_ неочевидные (не поддающиеся логическому объяснеию) элементы (задержки, вставки пустых байт, последователнтсти запросов и т.д.) которые есть резултат старого опыта и "большого траха". Поскольку они "не следуют из логики", вы их наверняка потеряете при переписывании. И начнете круг "большого траха" по новой. Особенно это касается российского "железа", но и западного тоже.
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, gandjustas, Вы писали: G>>Я уже думал включить дурачка и сделать по-своему, но хочется дать понять начальнику что стоит переписывать части программы для уменьшения сложности, а он зачем-то держится за старый код, позволяя вносить только мелкие изменения.
И он прав. Вы видете только кривой код, а он видит больше. Исправить код не проблема, но чем больше вы внесете изменений, тем больше нужно будет перетестировать и перепроверять. Переписать 1000 строк кода — гарантированно получить десяток ошибок. Их нужно будет исправлять и снова тестировать. И не говорите что вы такой гениальный, что пишете код без ошибок и перепишете эту тысячу без проблем. Так не бывает. Внесение точечных изменений — правильный подход. Переписать все можно только при запасе времени на полное перетестироание системы, а при работе с железом — так еще и проверки что у всех клиентов ничего не сломалось.
Здравствуйте, gandjustas, Вы писали:
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
Здравствуйте, gandjustas, Вы писали:
G>На работе получилась такая ситуация: после обновления программы у клиентов начали появляться ошибки (зависимые от оборудования, у себя протестировать не могли). Мне удалось обнаружить ошибку. Для её устранения потребуется переписать один класс. Класс был написан (правильнее сказать "рожден в мучениях") два года назад, комментариев ноль, автор уже уволился, короче рефакторинг делу не поможет. И все бы ничего, но надо это сделать быстро, желательно до конца недели.
G>Начальник отклонил мое предложение все переписать и хочет чтобы я связался с клиентами, выяснил какие у них стояли версии программы (учет этого конечно же не ведется), нашел где-то эти версии (полу-)годичной давности (естественно CVS никакого нет, а архив храниться где-то на дисках), проанализировал эти версии и внес локальные изменения для восстановления работоспособности.
G>Мне этого делать совсем нехочется, да и переписать, по-моему, правильнее будет. Как теперь в этои убедить начальника?
гм... я прочитал правильное замечание "трофимова", потому ответы только на вопрос.
убедить начальника, что это делать не хочется просто. надо сказать, что ты не хочешь это делать. он поверит.
то, что переписать "это" проще — убедить начальника сложнее. для этого надо сделать:
1) написать план переписывания.
2) написать план тестирования.
3) написать план накатывания обновленной версии для всех пользователей.
4) не забыть включить время для исправления при тестировании и для исправления после деплоймента.
5) все это собрать в одно письмо, и оправить в адрес начальника. можно сделать сс на другого начальника или на одного из представителей заказчика. в письме мотивировано обьяснить, чем это лучше, и к чему приведет в дальнейшем. если начальник "технически правильный" — можно вложить код с подробным коментарием.
для демонстрации разницы:
1) написать план исследования клиентов
2) написать план работы с изменениями у клиентов.
3) указать количество разных систем и возможные проблемы адаптации под системы.
4) сравнить планы по времени и ресурсам.
...тока... оно тебе надо?!..
может быть, что ты зарабатываешь от времени "на клиенте" больше.
AE>Если это класс работы с железом, то там _могут_ _быть_ неочевидные (не поддающиеся логическому объяснеию) элементы (задержки, вставки пустых байт, последователнтсти запросов и т.д.) которые есть резултат старого опыта и "большого траха". Поскольку они "не следуют из логики", вы их наверняка потеряете при переписывании. И начнете круг "большого траха" по новой. Особенно это касается российского "железа", но и западного тоже.
Такие "неочевидные" элементы в большинстве случаев результат невнимательного чтения спеки, наивного подхода к решению проблем или криворукой оптимизации. Поскольку "цикл большого траха" обычно проходит в темпе гопака с чечеткой, разбираться в причинах ошибки, а уж тем более читать документацию недосуг. Вот и получается корявый код, изобилующий никак не отмеченными хаками, в котором никто не способен разобраться.
Miroff пишет: > Такие "неочевидные" элементы в большинстве случаев результат > невнимательного чтения спеки, наивного подхода к решению проблем или > криворукой оптимизации. Поскольку "цикл большого траха" обычно проходит > в темпе гопака с чечеткой, разбираться в причинах ошибки, а уж тем более > читать документацию недосуг. Вот и получается корявый код, изобилующий > никак не отмеченными хаками, в котором никто не способен разобраться.
Единственное, с чем я согласен с Вами, так это с Вашим "наивным подходом
к решению проблем".
