Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода.
Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
ЗЫ остальные пункты новой работы меня полностью устраивают: лучше процесс, офис, соцпакет, зарплата...
Здравствуйте, Аноним, Вы писали:
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности.
Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга.
Здравствуйте, Аноним, Вы писали:
А>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
А>ЗЫ остальные пункты новой работы меня полностью устраивают: лучше процесс, офис, соцпакет, зарплата...
1) В чем заключается необходимость рефакторинга?
2) Где те кто этот код писал?
3) Объем кода?
4) Его сложность и требования к надежности?
5) Насколько страшный код?
6) Язык\среда разработки?
7) Сколько человек будет работать над этим? Ваша должность там?
KP>Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга.
Никому оно ничего не обязано. И хороший или плохой рефакторинг определяется совершенно не этим. Просто надо взвесить все риски, и если заказчик действительно требует, чтоби все делалось по живой системе, надо или предупредить о том, что он берет на себя эти риски, либо закладывать соответствующую компенсацию.
Здравствуйте, Nikolay_Ch, Вы писали:
KP>>Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга. N_C>Никому оно ничего не обязано. И хороший или плохой рефакторинг определяется совершенно не этим. Просто надо взвесить все риски, и если заказчик действительно требует, чтоби все делалось по живой системе, надо или предупредить о том, что он берет на себя эти риски, либо закладывать соответствующую компенсацию.
Наверное имелось ввиду то, что во время рефакторинга должны проходить все тест-кейсы, и в любой момент можно было бы выпустить очередную версию продукта не боясь, что рефакторинг что-то сломал.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Никому оно ничего не обязано. И хороший или плохой рефакторинг определяется совершенно не этим. Просто надо взвесить все риски, и если заказчик действительно требует, чтоби все делалось по живой системе, надо или предупредить о том, что он берет на себя эти риски, либо закладывать соответствующую компенсацию.
Контролировать корректность проведения рефакторинга, если во время его проведения система находится в не рабочем состоянии, крайне проблематично. Особенно если код не покрыт UnitTest-ам, что с большой долей вероятности так и есть.
Если же система все время, в рамках проведения рефакторинга, находится в рабочем состоянии, то особых проблем с проведением рефакторинга на "живой системе" не должно быть.
Здравствуйте, IT, Вы писали:
IT>Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности.
Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией. Ведь часто фичи такие требуют, что требуется лезть вообще везде (например перевести весь проект на юникод, когда об этом изначально даже не задумывались, переколбасить всю безопасность, или сделать такое, что в текущую архитектуру ну никак не вписывается). При этом фичи добавляются в работающее приложение. Вероятность того, что ошибешься при правках в коде, который не понимаешь и в котором сам черт ногу сломит на порядок больше того, что ты ошибешься при рефакторинге.
Итого, ИМХО вносить изменения в неподдерживаемый код, это тоже самое, что оперировать бегуна в процессе бега, вот только оперировать будет врач после влитого в себя литра водки . А рефакторинг — это оперировать на трезвую голову. Но почему-то оперировать его в процессе бега пьяным можно, а трезвым нельзя .
KP>Контролировать корректность проведения рефакторинга, если во время его проведения система находится в не рабочем состоянии, крайне проблематично. Особенно если код не покрыт UnitTest-ам, что с большой долей вероятности так и есть. KP>Если же система все время, в рамках проведения рефакторинга, находится в рабочем состоянии, то особых проблем с проведением рефакторинга на "живой системе" не должно быть.
Да ну??? Только куда деть следствия рефакторинга, которые не влияют на тесты? Т.е. изменение пользовательской логики и скорости работы? То, что изменения в пользовательском интерфейсе могут привести к остановке системы, думаю Вам известно?
Далее, не думаю, что "плохой" код полностью покрыт тестами. Еще далее — есть многие ситуации, когда при рефакторинге проще просто переписать вообще несколько блоков системы — и если делается все это по живой системе, то система может умереть.
Если же мы говорим об итерациях, то это всегда с отрывом от системы, с планом, что то-то и то-то мы переделываем и поставляем на этой неделе, то-то и то-то на следующей, и т.п.
E>Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией.
Весь вопрос все-таки мне кажется в том, что надо определить термин "по живой системе". В моем понимании — это то, что делается без особого тестирования прямо в системе. Например WEB-программирование без тестового сервера.
Если мы оперируем все-таки с системой, когда есть тестовый сервер, то ИМХО надо просто выбрать нормальные длительности итераций (периодичность поставок новых релизов), и все пройдет нормально.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Да ну??? Только куда деть следствия рефакторинга, которые не влияют на тесты? Т.е. изменение пользовательской логики и скорости работы? То, что изменения в пользовательском интерфейсе могут привести к остановке системы, думаю Вам известно?
короче. сначала (хотя бы) прочитай что такое рефакторинг в принципе, потом будем говорить. Пока нет даже понимания того, что такое "рефакторинг", то говорить не о чем. Вот тебе для начального ознакомления статья.
Здравствуйте, kaa.python, Вы писали:
KP>Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга.
Почему только рефакторинг? А если ты добавляешь новую функциональность, то оно уже не должно работать?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, elmal, Вы писали:
E>Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией.
Кто такое утверждает? Добавление запутанных фич — это распутывание ака рефакторинг и добавление нового функционала.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
KP>короче. сначала (хотя бы) прочитай что такое рефакторинг в принципе, потом будем говорить. Пока нет даже понимания того, что такое "рефакторинг", то говорить не о чем.
Хм... Тоже в тон.
Короче, если ты считаешь, что при рефакторинге не меняется скорость работы программы или не изменяется интерфейс взаимодействия модулей, то действительно не о чем разговаривать...
А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
Ну, с таким подходом Вам будет сложно
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Затея рисковая:
если все нормально — то и проблем не будет, а вот если все запущено — то работа превратится в ад, при этом Вас легко могут сделать стрелочником.
Я бы выяснил следующее:
1) в доступе ли автор кода
2) есть ли спецификация (если есть — надо посмотреть) и не разъехалась ли она с реальностью
3) есть ли автоматизированные тесты, что они покрывают (если есть — надо их смотреть)
4) есть ли тестеры, которые ее тестили
5) как код собирается сейчас (может легко оказаться, что программа собиралась на одной машине с супер специфичным окружением, которая давно умерла)
Четкие ответы на эти вопросы — хороший признак. Невразумительные — плохой.
PS: тут еще важно чтобы начальник был адекватный и понимал, что переписывание старых чужих сорцов дело непростое.
Это по опыту проектов, в которых на старте был "отличный" чужой код (реально старый) в котором надо было "чуть-чуть" подправить.
Здравствуйте, Аноним, Вы писали:
А>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
Тут ни того ни другого явно не выйдет...
Если нам не помогут, то мы тоже никого не пощадим.
