Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Аноним, Вы писали:
А>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>>>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
G>>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
J>Тут это... Меру надо знать
J>Потому что твой вопрос звучит как J>- Меня тут зовут лазить в затопленные канализационные коллекторы, стоит за это браться? J>- А ты хочешь научиться лазить по лестницам или нет?
Вопрос автора: А>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
При чем тут "канализации"? Я ничего подобного не вижу — обычная характеристика кода, который имеет возраст и писался большим количеством людей. ВСЕ большие проекты с возрастом выглядят примерно так.
J>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду.
Я в посте автора не видел ничего про малограмотных кодеров. Более того,
1) Малограмотные кодеры не смогут написать большую работоспособную систему в любом случае. Это миф.
2) Твой собственный код будет казаться помойкой другому "малограмотному кодеру", не умеющему работать с чужим кодом. На мой взгляд, такая позиция — симптом неумения работать с чужим кодом, не более того.
J>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были.
Здравствуйте, IT, Вы писали:
IT>Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности.
Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга.
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Рефакторинг это процесс перехода из одного состояния в другое без изменения внешнего поведения. Прям в определении все пункты:
1) "из одного состояния" — оцени старое значить. возми метрики (профайлы, оцени по смеллам, возми тулзы)
2) "новое состояние" — пойми что ты хочешь, прибрось будущую систему, оцени её
3) "без изменения внешнего" — обложись тестами. два вариант либо всё — но это сказка, либо места хирургического вмешательства.
4) примени безопасную технику рефакторинга.
п.4 — для реинженеринга (не путать рефакторинг крупных вещей называется реинженеринг)
Нюансы:
1. Косвенно сужу, что система слишком связанная (раз не было тестов) — это хреново
2. Реинженеринг это целый waterfall, он должен аккуратно планироваться и выполнятся
3. Если у вас команда первым делом нужно привести порядок в головах разработчиков
4. Нужно разработать внутрикомандное взаимодействие и выработка общей стратегии
5. Жри слона по частям.
А лучше позвать спецов, которые помогут вам провести это
Например меня.
Здравствуйте, Аноним, Вы писали:
А>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
Здравствуйте, Аноним, Вы писали:
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности.
Если нам не помогут, то мы тоже никого не пощадим.
KP>Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга.
Никому оно ничего не обязано. И хороший или плохой рефакторинг определяется совершенно не этим. Просто надо взвесить все риски, и если заказчик действительно требует, чтоби все делалось по живой системе, надо или предупредить о том, что он берет на себя эти риски, либо закладывать соответствующую компенсацию.
KP>Контролировать корректность проведения рефакторинга, если во время его проведения система находится в не рабочем состоянии, крайне проблематично. Особенно если код не покрыт UnitTest-ам, что с большой долей вероятности так и есть. KP>Если же система все время, в рамках проведения рефакторинга, находится в рабочем состоянии, то особых проблем с проведением рефакторинга на "живой системе" не должно быть.
Да ну??? Только куда деть следствия рефакторинга, которые не влияют на тесты? Т.е. изменение пользовательской логики и скорости работы? То, что изменения в пользовательском интерфейсе могут привести к остановке системы, думаю Вам известно?
Далее, не думаю, что "плохой" код полностью покрыт тестами. Еще далее — есть многие ситуации, когда при рефакторинге проще просто переписать вообще несколько блоков системы — и если делается все это по живой системе, то система может умереть.
Если же мы говорим об итерациях, то это всегда с отрывом от системы, с планом, что то-то и то-то мы переделываем и поставляем на этой неделе, то-то и то-то на следующей, и т.п.
Здравствуйте, Gaperton, Вы писали:
J>>Сабж автора: "чужой _плохой_ код".
G>Я не заметил в посте автора упоминания индусокодеров, извини. Знаешь, почему? Потому, что его там нет. Все, чего там нет — ты додумал сам. Спорить с этим я не буду.
там было упоминание плохого кода.
плохой код у нас обычно производится индусокодерами (независимо от национальности, потому что в моей команде по крайней мере один этнический индус — очень толковый парень) или как хочешь их обзови
Ты тоже додумал сам, что там есть концепции и прочая, а там может оказаться 20 мегабайт тупого копи-пейста.
G>>>У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были. J>>Ну я очень рад за тебя и твоих программистов J>>У меня вот были (и есть) и примеры, которые я описал, и о которых ты говоришь. G>Сочувствую.
Наверное, в этом и разница.
Тебе, видимо, сплошь попадались проекты, в которых насквозь была архитектура и концепции, и там действительно можно было чему-то научиться, а мне зачастую — маленькое-маленькое ядро, в котором действительно есть концепции и дизайн, а вокруг — гора тупейшего копипейста и кода в стиле java+basic=c++, естественно, никак не комментированного (как со стороны кода, так и со стороны задач, которые должны этим кодов исполняться) и с недоступными разработчиками. И те пафосые слова, которые ты говорил ("понять мысль и концепцию автора и следовать им" и т.д.) в реальности выливается в то, что ты убиваешь добрую неделю на то, чтобы осознать, что _никакой_ концепции и _никаких_ мыслей в голове автора не было вообще, было только желание сделать тяп-ляп и пойти пить пиво.
И процесс этот выглядит обычно так: ага, тут, наверное, автор просто скопипейстил эту девятистраничную функцию и поменял в ней а на б, а тут другой автор скопипейстил из второй и поменял б на в и г на д (надо бы следовать замыслу автора, т.е. заняться тем же копи-пейстом, да?) и в результате мы имеем полтора десятка функций, которые, вроде бы, делают одно и то же, но результаты все выдают разные, и ты понятия не имеешь, которая же из них работает правильно, потому что когда от юзера приходил баг-репорт, правилась только одна из этих функций (потому что именно она зовется из того места, на которое напоролся юзер) или вообще отпочковывалась еще одна, потому что исходная зовется еще из кучи мест — не дай бог ведь сломаешь, поэтому в коде появляется скопипейсченная функция специально для кнопки А, которую нажал юзер, а для всех остальных мест — остается старая функция, но ты-то об этом не знаешь и думаешь, что запрос от юзера был изменить поведение именно кнопки А, и что _все_ функции работают правильно, просто вот в этом месте нужно исключение.
Я думаю, ни один человек в здравом уме добровольно за копание в горе мусора в течение нескольких лет не возьмется и другому советовать пойти поплавать в подобном водоеме не будет, разве что кровному врагу.
Тем более делать это такими пафосными словами, что это, мол, единственный путь научиться работать с чужим кодом.
Здравствуйте, jazzer, Вы писали:
J>А вот если ты посадишь этого же индуса наваять новый проект с нуля, т.е. сформулировать и отранжировать требования, спроектировать и закодить, причем так, чтобы обеспечить высокий уровень поддерживаемости — вот на это нужна очень высокая квалификация.
Не согласен. Да, чтобы написать с нуля — нужна высокая квалификация.
А чтобы отрефакторить готовое — еще выше. Тебе же надо делать все тоже самое, что и в первом случае, но с учетом ограничений, которые на тебя наложила предыдущая реализация — гораздо более ювелирная работа.
Здравствуйте, IT, Вы писали:
IT>Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности.
Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией. Ведь часто фичи такие требуют, что требуется лезть вообще везде (например перевести весь проект на юникод, когда об этом изначально даже не задумывались, переколбасить всю безопасность, или сделать такое, что в текущую архитектуру ну никак не вписывается). При этом фичи добавляются в работающее приложение. Вероятность того, что ошибешься при правках в коде, который не понимаешь и в котором сам черт ногу сломит на порядок больше того, что ты ошибешься при рефакторинге.
Итого, ИМХО вносить изменения в неподдерживаемый код, это тоже самое, что оперировать бегуна в процессе бега, вот только оперировать будет врач после влитого в себя литра водки . А рефакторинг — это оперировать на трезвую голову. Но почему-то оперировать его в процессе бега пьяным можно, а трезвым нельзя .
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Да ну??? Только куда деть следствия рефакторинга, которые не влияют на тесты? Т.е. изменение пользовательской логики и скорости работы? То, что изменения в пользовательском интерфейсе могут привести к остановке системы, думаю Вам известно?
короче. сначала (хотя бы) прочитай что такое рефакторинг в принципе, потом будем говорить. Пока нет даже понимания того, что такое "рефакторинг", то говорить не о чем. Вот тебе для начального ознакомления статья.
KP>короче. сначала (хотя бы) прочитай что такое рефакторинг в принципе, потом будем говорить. Пока нет даже понимания того, что такое "рефакторинг", то говорить не о чем.
Хм... Тоже в тон.
Короче, если ты считаешь, что при рефакторинге не меняется скорость работы программы или не изменяется интерфейс взаимодействия модулей, то действительно не о чем разговаривать...
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
А>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
G>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
Тут это... Меру надо знать
Потому что твой вопрос звучит как
— Меня тут зовут лазить в затопленные канализационные коллекторы, стоит за это браться?
— А ты хочешь научиться лазить по лестницам или нет?
Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду.
У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
Для того, чтоб научиться лазить по лестницам, необязательно проделывать это в течении нескольких месяцев в затопленных коллекторах.
Если, конечно, нет острого желания сделать разгребание дерьма своей основной профессией.
Если есть — тогда, конечно, другое дело, "надо брать", и потом большими буквами в резюме писать: "Работаю исключительно с legacy-кодом, от которого все ваши программисты шарахаются" — оторвут с руками, ассенизаторы всем нужны.
J>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду. J>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
Не факт, что это плохо. "Вкус к хорошему коду", во-первых, субъективен, во-вторых, следование ему тратит время ужасным образом.
J>Если есть — тогда, конечно, другое дело, "надо брать", и потом большими буквами в резюме писать: "Работаю исключительно с legacy-кодом, от которого все ваши программисты шарахаются" — оторвут с руками, ассенизаторы всем нужны.
Ага. Ремонт чего-то в канализации — дело востребованное, реальное, оплачиваемое, а вот маниловские мечты о прекрасном коде — не всегда.
Кстати, это не обязательно legacy код. Legacy — это то, что подлежит переделке, но очень осторожной, ибо оно работает. Старый код — не обязательно legacy, там далеко не все нуждается в переделке.
Здравствуйте, Maxim S. Shatskih, Вы писали:
J>>Вот я понимаю под ним ясно написанный, простой, понятный, безопасный, в котором к месту используются паттерны и т.п. Если у тебя есть привычка так писать сразу — это у тебя времени отнимет столько же, сколько и написание макарон. Ну, или я тебя не понял.
MSS>Не понял. Никто не призывает сразу писать макароны. Но они при не очень хорошем управлении требованиями все равно накопятся.
Тогда я опять не понял, почему написание хорошего и понятного кода (естественно, в сравнении с макаронами) должно отнимать море времени (цитата: "следование ему тратит время ужасным образом")
Ну и управление требованиями в саппортном проекте — само по себе ад и кошмар.
J>>Потому что лучше следовать плохому коду, который пользуется какой-нть ужасной концепцией (например, копи-пейст, или в коде на С++ создание локальных объектов через new), и продолжать в его стиле, чем врубаться в него со своими привычками, внося стилистический разнобой — от этого код станет еще труднее поддерживать.
MSS>Это да. Хотя явную грязь, ведущую к багам, развазюкивать не следует.
Так ты еще пойди пойми, где грязь, а где так и надо.
J>>Хоть старый код, хоть легаси (это если мы говорим о софте для внутреннего пользования, а не о коробочном) — и те и другие в 99% случаев характеризуются тем, что совершенно непонятно, почему данная функция написана именно так, а не иначе
MSS>Это вообще риторический вопрос. "Оно работает". И это главное. Если рефакторить — то так, чтобы работало.
Так вопрос-то в том, как работает?
Иначе твой рефакторинг сведется к красивому заворачиванию багов в паттерны, после чего уже точно никто не разберется, баг это копи-пейста был или правда так и надо.
А на выяснение того, как оно работает и, особенно, как оно _должно_ работать, уйудет море времени и сил — прослеживание всех цепочек вызовов, выяснение всех граничных случаев и всех расхождений, выяснение, как каждое аукнется в видимом юзеру интерфейсе, и после этого выяснение у юзера, где оно работает корректно, а где — нет, причем в 3/4 случаев ответ юзера будет "не знаю, это было очень давно, еще до меня, и этой фичей мы пользуемся раз в месяц".
Если кому очень нравится подобной работой заниматься — велкам, но для меня эта работа сродни "у нас тут мусорное ведро стоит, заполненное до краев, и если подозрение, что мы туда выкинули что-то важное — так что ты посмотри, пожалуйста, что там и как".
J>>Поэтому старый код в таких проектах для простоты объявляется священной коровой — ибо, как ты правильно сказал, работает и приносит деньги — и выносится официальный запрет на любое изменение,
MSS>Метание из крайности в крайность.
Тем не менее это — примеры из реальной жизни реальных (и успешных экономически — а этого абсолютному большинству менеджеров достаточно, чтобы следовать этой практике) саппортных проектов.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Никому оно ничего не обязано. И хороший или плохой рефакторинг определяется совершенно не этим. Просто надо взвесить все риски, и если заказчик действительно требует, чтоби все делалось по живой системе, надо или предупредить о том, что он берет на себя эти риски, либо закладывать соответствующую компенсацию.
Контролировать корректность проведения рефакторинга, если во время его проведения система находится в не рабочем состоянии, крайне проблематично. Особенно если код не покрыт UnitTest-ам, что с большой долей вероятности так и есть.
Если же система все время, в рамках проведения рефакторинга, находится в рабочем состоянии, то особых проблем с проведением рефакторинга на "живой системе" не должно быть.
E>Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией.
Весь вопрос все-таки мне кажется в том, что надо определить термин "по живой системе". В моем понимании — это то, что делается без особого тестирования прямо в системе. Например WEB-программирование без тестового сервера.
Если мы оперируем все-таки с системой, когда есть тестовый сервер, то ИМХО надо просто выбрать нормальные длительности итераций (периодичность поставок новых релизов), и все пройдет нормально.
Здравствуйте, kaa.python, Вы писали:
KP>Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга.
Почему только рефакторинг? А если ты добавляешь новую функциональность, то оно уже не должно работать?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
V>Есть конкретный индусский проект на C#, который надо срочно реанимировать. Ты предлагаешь научиться понимать мысль автора и достраивать систему в рамках его концепций. Давай рассмотрим твое предложение на конкретных примерах.
Индусский проект != произвольный чужой проект.
V>Дак вот, ты действительно предлагаешь развивать систему в рамках этих "концепций"?
Херовый стиль кодирования != концепции.
V>P.S.: этот проект после "евроремонта" таки удачно ушел в продакшен и теперь от него воняет не так сильно, как сначала. Более того, он даже начал работать!
Ты все таки не выбросил его, и не переписал его с нуля, а заставил его работать серией переделок. Этого не надо уметь делать? Это не есть отдельный навык? На это разве не требуется более высокая квалификация, чем просто выкинуть этот код, и написать собственный кусок дерьма?
Здравствуйте, Gaperton, Вы писали:
G>Вопрос автора: А>>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
Сабж автора: "чужой _плохой_ код".
G>При чем тут "канализации"? Я ничего подобного не вижу — обычная характеристика кода, который имеет возраст и писался большим количеством людей. ВСЕ большие проекты с возрастом выглядят примерно так.
Дьявол — в деталях, в данном случае — в слове "примерно".
Если ты один и тот же проект отдашь лет на пять квалифицированным программистам и индусокодерам с плохим менеджером над ними — "примерно" по прошествии этих пяти лет будет _очень_ разным.
J>>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду.
G>Я в посте автора не видел ничего про малограмотных кодеров. Более того, G>1) Малограмотные кодеры не смогут написать большую работоспособную систему в любом случае. Это миф.
Зато малограмотные кодеры отлично могут поддерживать изначально вменяемый продукт и за несколько лет превратить его в помойку.
Очень, кстати, распространенная практика: сначала хорошие программеры пишут ядро, а потом остаются одни индусы.
G>2) Твой собственный код будет казаться помойкой другому "малограмотному кодеру", не умеющему работать с чужим кодом. На мой взгляд, такая позиция — симптом неумения работать с чужим кодом, не более того.
Я не очень понимаю, как нежелание работать с плохим кодом связано со способностью работать с чужим кодом, в том числе и с плохим. Это во-первых.
А во-вторых, я не очень понимаю, зачем для того, чтобы научиться работать с чужим кодом, надо обязательно садиться на саппорт древнего проекта, когда практический любой проект, в котором разработчиков больше одного, предполагает эту самую работу с чужим кодом.
J>>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
G>У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были.
Ну я очень рад за тебя и твоих программистов
У меня вот были (и есть) и примеры, которые я описал, и о которых ты говоришь.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, jazzer, Вы писали:
J>>А вот если ты посадишь этого же индуса наваять новый проект с нуля, т.е. сформулировать и отранжировать требования, спроектировать и закодить, причем так, чтобы обеспечить высокий уровень поддерживаемости — вот на это нужна очень высокая квалификация.
DAS> Не согласен. Да, чтобы написать с нуля — нужна высокая квалификация. DAS> А чтобы отрефакторить готовое — еще выше. Тебе же надо делать все тоже самое, что и в первом случае, но с учетом ограничений, которые на тебя наложила предыдущая реализация — гораздо более ювелирная работа.
J>Вот я понимаю под ним ясно написанный, простой, понятный, безопасный, в котором к месту используются паттерны и т.п. Если у тебя есть привычка так писать сразу — это у тебя времени отнимет столько же, сколько и написание макарон. Ну, или я тебя не понял.
Не понял. Никто не призывает сразу писать макароны. Но они при не очень хорошем управлении требованиями все равно накопятся.
J>Потому что лучше следовать плохому коду, который пользуется какой-нть ужасной концепцией (например, копи-пейст, или в коде на С++ создание локальных объектов через new), и продолжать в его стиле, чем врубаться в него со своими привычками, внося стилистический разнобой — от этого код станет еще труднее поддерживать.
Это да. Хотя явную грязь, ведущую к багам, развазюкивать не следует.
J>Хоть старый код, хоть легаси (это если мы говорим о софте для внутреннего пользования, а не о коробочном) — и те и другие в 99% случаев характеризуются тем, что совершенно непонятно, почему данная функция написана именно так, а не иначе
Это вообще риторический вопрос. "Оно работает". И это главное. Если рефакторить — то так, чтобы работало.
J>Поэтому старый код в таких проектах для простоты объявляется священной коровой — ибо, как ты правильно сказал, работает и приносит деньги — и выносится официальный запрет на любое изменение,
Здравствуйте, chipsеt, Вы писали:
C>Здравствуйте, <Аноним>, Вы писали:
А>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода.
C>Я ни в коей мере не считаю себя опытным. Но имхо (и из собственного опыта) рефакторинг это очень интересно -- не путать с поддеркой существующего проекта.
Ты всерьез думаешь, что одно бывает без другого?
Вот ты сам подумай, зачем бизнесу тратить ресурсы на "рефакторинг и приведение в порядок" кода, который не предполагается поддерживать?
Одно дело, когда говорят: "Ускорьте-ка нам эту систему в пять раз и распараллельте на 50 компов" и еще что-то в этом роде, тогда ясна конечная цель рефакторинга и тогда действительно можно браться и работа действительно может быть интересной.
Но в формулировке "привести код в порядок" это, имхо, может означать только "нам нужен кто-нть, чтоб ориентировался в коде и был на подхвате, когда нужно будет все это активно поддерживать". Причем, вполне возможно, что задачи поддержки уже готовы и тебе просто скажут: "рефакторинг — это все хорошо, и ты обязательно займешься им, когда пофиксишь вот эти 50 багов" и в результате к реальному рефакторингу ты приступишь года через три, если не сбежишь раньше.
You will always get what you always got
If you always do what you always did
чужой плохой код
От:
Аноним
Дата:
19.11.07 21:37
Оценка:
Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода.
Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
ЗЫ остальные пункты новой работы меня полностью устраивают: лучше процесс, офис, соцпакет, зарплата...
Здравствуйте, Аноним, Вы писали:
А>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
А>ЗЫ остальные пункты новой работы меня полностью устраивают: лучше процесс, офис, соцпакет, зарплата...
1) В чем заключается необходимость рефакторинга?
2) Где те кто этот код писал?
3) Объем кода?
4) Его сложность и требования к надежности?
5) Насколько страшный код?
6) Язык\среда разработки?
7) Сколько человек будет работать над этим? Ваша должность там?
Здравствуйте, Nikolay_Ch, Вы писали:
KP>>Грамотный рефакторинг, как раз характеризуется тем, что приложение обязанно работать в течении всего периода рефакторинга. N_C>Никому оно ничего не обязано. И хороший или плохой рефакторинг определяется совершенно не этим. Просто надо взвесить все риски, и если заказчик действительно требует, чтоби все делалось по живой системе, надо или предупредить о том, что он берет на себя эти риски, либо закладывать соответствующую компенсацию.
Наверное имелось ввиду то, что во время рефакторинга должны проходить все тест-кейсы, и в любой момент можно было бы выпустить очередную версию продукта не боясь, что рефакторинг что-то сломал.
Здравствуйте, elmal, Вы писали:
E>Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией.
Кто такое утверждает? Добавление запутанных фич — это распутывание ака рефакторинг и добавление нового функционала.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
Ну, с таким подходом Вам будет сложно
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Затея рисковая:
если все нормально — то и проблем не будет, а вот если все запущено — то работа превратится в ад, при этом Вас легко могут сделать стрелочником.
Я бы выяснил следующее:
1) в доступе ли автор кода
2) есть ли спецификация (если есть — надо посмотреть) и не разъехалась ли она с реальностью
3) есть ли автоматизированные тесты, что они покрывают (если есть — надо их смотреть)
4) есть ли тестеры, которые ее тестили
5) как код собирается сейчас (может легко оказаться, что программа собиралась на одной машине с супер специфичным окружением, которая давно умерла)
Четкие ответы на эти вопросы — хороший признак. Невразумительные — плохой.
PS: тут еще важно чтобы начальник был адекватный и понимал, что переписывание старых чужих сорцов дело непростое.
Это по опыту проектов, в которых на старте был "отличный" чужой код (реально старый) в котором надо было "чуть-чуть" подправить.
G>Разумеется, уметь понимать мысль автора кода, и продолжать ее, достраивая систему в рамках концепций, выдуманных не тобой — это сложнее, чем неудержимый полет собственной гениальной мысли. Это просто принципиально другой класс специалиста, если вы понимаете о чем я. Свои-то идеи развивать любой может.
G>Вы задайте себе сами вопрос — вы хотите научится эффективно работать с чужим кодом, или нет?
Есть конкретный индусский проект на C#, который надо срочно реанимировать. Ты предлагаешь научиться понимать мысль автора и достраивать систему в рамках его концепций. Давай рассмотрим твое предложение на конкретных примерах.
1) Есть объект. У объекта есть поле IsEmpty типа int. Если IsEmpty == 0 — то объект пустой; если IsEmpty == 1, то объект непустой.
2) Есть метод. void DoSomething(int val). Я придумал тут только название метода; название и состав параметров сохранено оригинальным. Дак вот, этот метод выполняет три совершенно разных действия и то, что именно он будет делать зависит от значения параметра val. Если val == 0, то выполняется первое действие; если val == 1 — второе; а при val == 2 — третье. Естественно, никаких коментариев, документации и т.д. нет. В коде использование метода выглядит так: DoSomething(0); DoSomething(1); DoSomething(2) и т.д.
3) Есть метод GetUserInformation. Этот метод, в зависимости от параметров, либо возвращает информацию о пользователе, либо апдейтит её и возвращает null.
4) Про исключения в этом проекте я уже когда-то писал здесь
Дак вот, ты действительно предлагаешь развивать систему в рамках этих "концепций"?
P.S.: этот проект после "евроремонта" таки удачно ушел в продакшен и теперь от него воняет не так сильно, как сначала. Более того, он даже начал работать!
Здравствуйте, prVovik, Вы писали:
V>Дак вот, ты действительно предлагаешь развивать систему в рамках этих "концепций"?
Вопрос, наверное, насколько сильно развивать. Во-вторых, мне кажется, это скорее не концепции, а культура кодирования (вполне может быть, что некие общие принципы продуманы хорошо, но потом это дело зажило, обросло полипами и завитками и прочее).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: чужой плохой код
От:
Аноним
Дата:
21.11.07 14:46
Оценка:
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Здравствуйте, Аноним, Вы писали: А>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
Всем спасибо, что откликнулись, но проблема отпала сама собой: мне этим на старой работе хорошо...
Потому продолжаем в рамках общего развития...
NW>1) В чем заключается необходимость рефакторинга?
большая связность библиотек, запутанность кода, отсутствие саппорта, другие проблемы NW>2) Где те кто этот код писал?
недоступны за давностью лет... многим либам больше 10 лет NW>3) Объем кода?
более 50 мегабайт, библиотек так же больше 50... количество строк я не знаю... NW>4) Его сложность и требования к надежности?
сложность различная, требования наверное к разным либам разные NW>5) Насколько страшный код?
различной страшности... встречается ужасный код с названиями функций на непонятных языках NW>6) Язык\среда разработки?
студия 2005, С++ NW>7) Сколько человек будет работать над этим? Ваша должность там?
2-3, девелопер, тимлид
Re[2]: чужой плохой код
От:
Аноним
Дата:
21.11.07 14:56
Оценка:
Здравствуйте, Gregory Liokumovich, Вы писали:
А>>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода? GL>Затея рисковая: GL>если все нормально — то и проблем не будет, а вот если все запущено — то работа превратится в ад, при этом Вас легко могут сделать стрелочником.
GL>Я бы выяснил следующее: GL>1) в доступе ли автор кода
некоторые частей. В основном нет GL>2) есть ли спецификация (если есть — надо посмотреть) и не разъехалась ли она с реальностью
почти нет. GL>3) есть ли автоматизированные тесты, что они покрывают (если есть — надо их смотреть)
почти нет GL>4) есть ли тестеры, которые ее тестили
тестеры, которые тестили некоторые части этого кода. Да и то в составе другой программы GL>5) как код собирается сейчас (может легко оказаться, что программа собиралась на одной машине с супер специфичным окружением, которая давно умерла)
без руля. Должен собираться GL>Четкие ответы на эти вопросы — хороший признак. Невразумительные — плохой.
ответы четкие... только мне не помогают
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, IT, Вы писали:
IT>>Если при этом приложение должно продолжать работать в течении всего процесса рефакторинга, то сравнимо с оперированием ноги бегуна во время забега. Впрочем, всё зависит от уровня запущенности. E>Вот интересно, почему добавлять фичи в работающее приложение (которое запутано настолько, что вообще никто не понимает как оно работает) можно, а рефакторинг все считают рискованной операцией.
Наверное, потому, что в основном новые фичи — это пристегивание нового кода "сбоку", что с очень небольшой вероятностью может сломать уже существующую функциональность — а это обычно всех очень даже устраивает.
При этом вся существующая помойка кода оказывается нетронутой.
А "переписывание всего на Юникод" — это именно переписывание всего, а не просто добавление фичи.
Хотя, конечно, кто как назовет.
Здравствуйте, Gaperton, Вы писали:
G>Индусский проект != произвольный чужой проект. G>Херовый стиль кодирования != концепции.
зато "Индусский проект" + "Херовый стиль кодирования" = отвращение к работе и мысли о самоубийстве.
V>>P.S.: этот проект после "евроремонта" таки удачно ушел в продакшен и теперь от него воняет не так сильно, как сначала. Более того, он даже начал работать!
G>Ты все таки не выбросил его, и не переписал его с нуля, а заставил его работать серией переделок. Этого не надо уметь делать? Это не есть отдельный навык?
Это, вообще-то, базовый навык.
Если этого навыка нет — такому вообще в программизме не место.
G>На это разве не требуется более высокая квалификация, чем просто выкинуть этот код, и написать собственный кусок дерьма?
Нет, не требуется, ибо это базовый навык.
Посадить на поддержку можно любого индуса, и он copy-paste-ом пофиксит тебе любые баги, и все будет приемлемо работать и тебя во всех отношениях удовлетворит, пока ты в код не заглянешь.
А вот если ты посадишь этого же индуса наваять новый проект с нуля, т.е. сформулировать и отранжировать требования, спроектировать и закодить, причем так, чтобы обеспечить высокий уровень поддерживаемости — вот на это нужна очень высокая квалификация.
Здравствуйте, jazzer, Вы писали:
G>>Вопрос автора: А>>>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>>>>>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить).
J>Сабж автора: "чужой _плохой_ код".
G>>При чем тут "канализации"? Я ничего подобного не вижу — обычная характеристика кода, который имеет возраст и писался большим количеством людей. ВСЕ большие проекты с возрастом выглядят примерно так.
J>Дьявол — в деталях, в данном случае — в слове "примерно". J>Если ты один и тот же проект отдашь лет на пять квалифицированным программистам и индусокодерам с плохим менеджером над ними — "примерно" по прошествии этих пяти лет будет _очень_ разным.
Я не заметил в посте автора упоминания индусокодеров, извини. Знаешь, почему? Потому, что его там нет. Все, чего там нет — ты додумал сам. Спорить с этим я не буду.
G>>У меня никогда не было таких примеров. А вот примеры, когда люди нихрена не разбираясь в чужой работе объявляли ее помойкой — были. J>Ну я очень рад за тебя и твоих программистов J>У меня вот были (и есть) и примеры, которые я описал, и о которых ты говоришь.
MSS>Кстати, это не обязательно legacy код. Legacy — это то, что подлежит переделке, но очень осторожной, ибо оно работает. Старый код — не обязательно legacy, там далеко не все нуждается в переделке.
Макс, а как тебе такое определение легаси кода.
Легаси код — это код написанный (может и недавно) предыдущей командой, из которой почти никого не осталось
DM>Легаси код — это код написанный (может и недавно) предыдущей командой, из которой почти никого не осталось
Определить в общем можно как угодно, но для меня слово legacy стоит где-то рядом со словом obsolete. То, что будет подвергаться тотальной переделке в обозримом будущем.
Если код не планируется весь глубоко рефакторить — то зачем его называть legacy?
Здравствуйте, Maxim S. Shatskih, Вы писали:
J>>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду. J>>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
MSS>Не факт, что это плохо. "Вкус к хорошему коду", во-первых, субъективен, во-вторых, следование ему тратит время ужасным образом.
Вообще говоря, это неверно. Точнее, про написание ничего не могу сказать, хотя тоже есть подозрение, а вот исправление "хорошего кода" занимает заметно меньше времени, чем "плохого".
NW>>5) Насколько страшный код? А>различной страшности... встречается ужасный код с названиями функций на непонятных языках NW>>6) Язык\среда разработки? А>студия 2005, С++ NW>>7) Сколько человек будет работать над этим? Ваша должность там? А>2-3, девелопер, тимлид
Здравствуйте, Maxim S. Shatskih, Вы писали:
J>>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду. J>>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
MSS>Не факт, что это плохо. "Вкус к хорошему коду", во-первых, субъективен, во-вторых, следование ему тратит время ужасным образом.
мы, наверное, разное понимаем под хорошим кодом.
Вот я понимаю под ним ясно написанный, простой, понятный, безопасный, в котором к месту используются паттерны и т.п. Если у тебя есть привычка так писать сразу — это у тебя времени отнимет столько же, сколько и написание макарон. Ну, или я тебя не понял.
Под плохим, соответственно, различные формы спагетти.
При работе же с чужим кодом ты должен, как совершенно верно сказал Gaperton, следовать этому самому коду, а качество его, по моему опыту, по крайней мере, очень часто далеко от хорошего.
Потому что лучше следовать плохому коду, который пользуется какой-нть ужасной концепцией (например, копи-пейст, или в коде на С++ создание локальных объектов через new), и продолжать в его стиле, чем врубаться в него со своими привычками, внося стилистический разнобой — от этого код станет еще труднее поддерживать.
Единственная проблема в том, что если ты слишком много времени проводишь за работой такого рода, то эти концепции постепенно становятся твоими, ты просто привыкаешь к ним и они уже не кажутся тебе такими уж ужасными, а глаз постепенно натренировывается разбирать спагетти-код, и, соответственно, твоя граница, которая отделяет спагетти-код от не-спагетти, смещается в сторону спагетти.
J>>Если есть — тогда, конечно, другое дело, "надо брать", и потом большими буквами в резюме писать: "Работаю исключительно с legacy-кодом, от которого все ваши программисты шарахаются" — оторвут с руками, ассенизаторы всем нужны.
MSS>Ага. Ремонт чего-то в канализации — дело востребованное, реальное, оплачиваемое, а вот маниловские мечты о прекрасном коде — не всегда.
Ну так я же не спорю, что дело это нужное, и ассенизаторы не зря свой хлеб едят.
Просто надо четко понимать, что идя в такой проект, ты становишься именно ассенизатором.
И если тебя это устраивает (ну или попался вменяемый работодатель, который понимает, что за чистку авгиевых конюшен надо платить вдвое) — тогда вперед, и это честно.
А нечестно — говорить, что это показывает, что у тебя квалификация выше, чем у всех остальных, которые этим не занимаются, и что это единственный способ научиться работать с чужим кодом. О чем я, собственно, и спорю с Gaperton-ом.
MSS>Кстати, это не обязательно legacy код. Legacy — это то, что подлежит переделке, но очень осторожной, ибо оно работает. Старый код — не обязательно legacy, там далеко не все нуждается в переделке.
Да хоть горшком назови.
Хоть старый код, хоть легаси (это если мы говорим о софте для внутреннего пользования, а не о коробочном) — и те и другие в 99% случаев характеризуются тем, что совершенно непонятно, почему данная функция написана именно так, а не иначе — то ли был соответствующий запрос от пользователя, то ли это просто баг.
И выяснить это обычно не представляется возможным, если код действительно старый, потому что уже не найти ни авторов, ни заказчиков — и то, и другое уже успело несколько раз смениться.
А выяснение требований по-новой с новым штатом заказчиков, и соответствующий рефакторинг — сравним по трудозатратам (и особенно по затратам времени) с переписыванием системы с нуля.
Поэтому старый код в таких проектах для простоты объявляется священной коровой — ибо, как ты правильно сказал, работает и приносит деньги — и выносится официальный запрет на любое изменение, если не было явного запроса на таковое изменение со стороны пользователя. А это означает в результате что? Если пришел запрос на дополнительную или измененную функциональность, и получается, что код, который ты пишешь сверху, в результате уходит в священный, и тот работает неправильно? Правильно, копи-пейст священного кода и затачивание его под тот запрос, который пришел от клиента, потому что сам священный код трогать не моги — запрос был на доп. функциональность.
Удовольствия во всем этом крайне мало.
Здравствуйте, <Аноним>, Вы писали:
А>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
А>ЗЫ остальные пункты новой работы меня полностью устраивают: лучше процесс, офис, соцпакет, зарплата...
Я ни в коей мере не считаю себя опытным. Но имхо (и из собственного опыта) рефакторинг это очень интересно -- не путать с поддеркой существующего проекта.
Я бы влез
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, chipsеt, Вы писали:
C>>Здравствуйте, <Аноним>, Вы писали:
А>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода.
C>>Я ни в коей мере не считаю себя опытным. Но имхо (и из собственного опыта) рефакторинг это очень интересно -- не путать с поддеркой существующего проекта.
J>Ты всерьез думаешь, что одно бывает без другого?
Поддержка, имхо, это добавление новых фич и фиксанье багов.
Рефакторинг, имхо, это переделка кода в нормальный вид.
Т.е. либо вкалываем больному стимулятор, либо лечим его
J>Вот ты сам подумай, зачем бизнесу тратить ресурсы на "рефакторинг и приведение в порядок" кода, который не предполагается поддерживать?
J>Одно дело, когда говорят: "Ускорьте-ка нам эту систему в пять раз и распараллельте на 50 компов" и еще что-то в этом роде, тогда ясна конечная цель рефакторинга и тогда действительно можно браться и работа действительно может быть интересной. J>Но в формулировке "привести код в порядок" это, имхо, может означать только "нам нужен кто-нть, чтоб ориентировался в коде и был на подхвате, когда нужно будет все это активно поддерживать". Причем, вполне возможно, что задачи поддержки уже готовы и тебе просто скажут: "рефакторинг — это все хорошо, и ты обязательно займешься им, когда пофиксишь вот эти 50 багов" и в результате к реальному рефакторингу ты приступишь года через три, если не сбежишь раньше.
Здравствуйте, Maxim S. Shatskih, Вы писали:
DM>>Легаси код — это код написанный (может и недавно) предыдущей командой, из которой почти никого не осталось MSS>Определить в общем можно как угодно, но для меня слово legacy стоит где-то рядом со словом obsolete. То, что будет подвергаться тотальной переделке в обозримом будущем.
MSS>Если код не планируется весь глубоко рефакторить — то зачем его называть legacy?
Имхо, ты намеренно или ненамеренно путаешь два термина: "legacy" — это "старое, работает, полезное", "obsolete" — просто таки дословно "старое, просто лежит, нигде не работает". Последнее рефакторить смысла нет — оно ведь все равно не работает в живой системе. В смысле, в живой системе оно никак не используется или его просто вообще нет — есть ведь целый вагон такого кода в старых проектах. Тратить время на его рефакторинг?
А вот тратить время на legacy приходится по разным причинам: обычно просто для того чтобы внедрить — не "приекрутить слева", а именно "внедрить как часть системы" — что-то новое, для чего придется так или иначе изменить старое — иногда довольно сильно. имхо.
Тут ни того ни другого явно не выйдет...
Если нам не помогут, то мы тоже никого не пощадим.
Знаешь, почему? Потому, что его там нет. Все, чего там нет — ты додумал сам. Спорить с этим я не буду.
"Всё что не убивает нас, делает нас сильнее..."
