Здравствуйте, Maxim S. Shatskih, Вы писали:
J>>Имхо, работа с плохим чужим кодом, написанным малограмотными кодерами двух месяцов от роду, абсолютно ничего хорошего в себе не содержит и является просто тратой времени и порчей собственного вкуса к хорошему коду. J>>У меня перед глазами были примеры, когда люди, писавшие нормальный код, попадали в "помоечные" проекты и через некоторое время (т.е. по окончании фазы крайнего неприятия кодопомойки) они сами начинали писать новый код в таком же помоечном стилде, который они полгода назад ненавидели.
MSS>Не факт, что это плохо. "Вкус к хорошему коду", во-первых, субъективен, во-вторых, следование ему тратит время ужасным образом.
мы, наверное, разное понимаем под хорошим кодом.
Вот я понимаю под ним ясно написанный, простой, понятный, безопасный, в котором к месту используются паттерны и т.п. Если у тебя есть привычка так писать сразу — это у тебя времени отнимет столько же, сколько и написание макарон. Ну, или я тебя не понял.
Под плохим, соответственно, различные формы спагетти.
При работе же с чужим кодом ты должен, как совершенно верно сказал Gaperton, следовать этому самому коду, а качество его, по моему опыту, по крайней мере, очень часто далеко от хорошего.
Потому что лучше следовать плохому коду, который пользуется какой-нть ужасной концепцией (например, копи-пейст, или в коде на С++ создание локальных объектов через new), и продолжать в его стиле, чем врубаться в него со своими привычками, внося стилистический разнобой — от этого код станет еще труднее поддерживать.
Единственная проблема в том, что если ты слишком много времени проводишь за работой такого рода, то эти концепции постепенно становятся твоими, ты просто привыкаешь к ним и они уже не кажутся тебе такими уж ужасными, а глаз постепенно натренировывается разбирать спагетти-код, и, соответственно, твоя граница, которая отделяет спагетти-код от не-спагетти, смещается в сторону спагетти.
J>>Если есть — тогда, конечно, другое дело, "надо брать", и потом большими буквами в резюме писать: "Работаю исключительно с legacy-кодом, от которого все ваши программисты шарахаются" — оторвут с руками, ассенизаторы всем нужны.
MSS>Ага. Ремонт чего-то в канализации — дело востребованное, реальное, оплачиваемое, а вот маниловские мечты о прекрасном коде — не всегда.
Ну так я же не спорю, что дело это нужное, и ассенизаторы не зря свой хлеб едят.
Просто надо четко понимать, что идя в такой проект, ты становишься именно ассенизатором.
И если тебя это устраивает (ну или попался вменяемый работодатель, который понимает, что за чистку авгиевых конюшен надо платить вдвое) — тогда вперед, и это честно.
А нечестно — говорить, что это показывает, что у тебя квалификация выше, чем у всех остальных, которые этим не занимаются, и что это единственный способ научиться работать с чужим кодом. О чем я, собственно, и спорю с Gaperton-ом.
MSS>Кстати, это не обязательно legacy код. Legacy — это то, что подлежит переделке, но очень осторожной, ибо оно работает. Старый код — не обязательно legacy, там далеко не все нуждается в переделке.
Да хоть горшком назови.
Хоть старый код, хоть легаси (это если мы говорим о софте для внутреннего пользования, а не о коробочном) — и те и другие в 99% случаев характеризуются тем, что совершенно непонятно, почему данная функция написана именно так, а не иначе — то ли был соответствующий запрос от пользователя, то ли это просто баг.
И выяснить это обычно не представляется возможным, если код действительно старый, потому что уже не найти ни авторов, ни заказчиков — и то, и другое уже успело несколько раз смениться.
А выяснение требований по-новой с новым штатом заказчиков, и соответствующий рефакторинг — сравним по трудозатратам (и особенно по затратам времени) с переписыванием системы с нуля.
Поэтому старый код в таких проектах для простоты объявляется священной коровой — ибо, как ты правильно сказал, работает и приносит деньги — и выносится официальный запрет на любое изменение, если не было явного запроса на таковое изменение со стороны пользователя. А это означает в результате что? Если пришел запрос на дополнительную или измененную функциональность, и получается, что код, который ты пишешь сверху, в результате уходит в священный, и тот работает неправильно? Правильно, копи-пейст священного кода и затачивание его под тот запрос, который пришел от клиента, потому что сам священный код трогать не моги — запрос был на доп. функциональность.
Удовольствия во всем этом крайне мало.
J>Вот я понимаю под ним ясно написанный, простой, понятный, безопасный, в котором к месту используются паттерны и т.п. Если у тебя есть привычка так писать сразу — это у тебя времени отнимет столько же, сколько и написание макарон. Ну, или я тебя не понял.
Не понял. Никто не призывает сразу писать макароны. Но они при не очень хорошем управлении требованиями все равно накопятся.
J>Потому что лучше следовать плохому коду, который пользуется какой-нть ужасной концепцией (например, копи-пейст, или в коде на С++ создание локальных объектов через new), и продолжать в его стиле, чем врубаться в него со своими привычками, внося стилистический разнобой — от этого код станет еще труднее поддерживать.
Это да. Хотя явную грязь, ведущую к багам, развазюкивать не следует.
J>Хоть старый код, хоть легаси (это если мы говорим о софте для внутреннего пользования, а не о коробочном) — и те и другие в 99% случаев характеризуются тем, что совершенно непонятно, почему данная функция написана именно так, а не иначе
Это вообще риторический вопрос. "Оно работает". И это главное. Если рефакторить — то так, чтобы работало.
J>Поэтому старый код в таких проектах для простоты объявляется священной коровой — ибо, как ты правильно сказал, работает и приносит деньги — и выносится официальный запрет на любое изменение,
Здравствуйте, Maxim S. Shatskih, Вы писали:
J>>Вот я понимаю под ним ясно написанный, простой, понятный, безопасный, в котором к месту используются паттерны и т.п. Если у тебя есть привычка так писать сразу — это у тебя времени отнимет столько же, сколько и написание макарон. Ну, или я тебя не понял.
MSS>Не понял. Никто не призывает сразу писать макароны. Но они при не очень хорошем управлении требованиями все равно накопятся.
Тогда я опять не понял, почему написание хорошего и понятного кода (естественно, в сравнении с макаронами) должно отнимать море времени (цитата: "следование ему тратит время ужасным образом")
Ну и управление требованиями в саппортном проекте — само по себе ад и кошмар.
J>>Потому что лучше следовать плохому коду, который пользуется какой-нть ужасной концепцией (например, копи-пейст, или в коде на С++ создание локальных объектов через new), и продолжать в его стиле, чем врубаться в него со своими привычками, внося стилистический разнобой — от этого код станет еще труднее поддерживать.
MSS>Это да. Хотя явную грязь, ведущую к багам, развазюкивать не следует.
Так ты еще пойди пойми, где грязь, а где так и надо.
J>>Хоть старый код, хоть легаси (это если мы говорим о софте для внутреннего пользования, а не о коробочном) — и те и другие в 99% случаев характеризуются тем, что совершенно непонятно, почему данная функция написана именно так, а не иначе
MSS>Это вообще риторический вопрос. "Оно работает". И это главное. Если рефакторить — то так, чтобы работало.
Так вопрос-то в том, как работает?
Иначе твой рефакторинг сведется к красивому заворачиванию багов в паттерны, после чего уже точно никто не разберется, баг это копи-пейста был или правда так и надо.
А на выяснение того, как оно работает и, особенно, как оно _должно_ работать, уйудет море времени и сил — прослеживание всех цепочек вызовов, выяснение всех граничных случаев и всех расхождений, выяснение, как каждое аукнется в видимом юзеру интерфейсе, и после этого выяснение у юзера, где оно работает корректно, а где — нет, причем в 3/4 случаев ответ юзера будет "не знаю, это было очень давно, еще до меня, и этой фичей мы пользуемся раз в месяц".
Если кому очень нравится подобной работой заниматься — велкам, но для меня эта работа сродни "у нас тут мусорное ведро стоит, заполненное до краев, и если подозрение, что мы туда выкинули что-то важное — так что ты посмотри, пожалуйста, что там и как".
J>>Поэтому старый код в таких проектах для простоты объявляется священной коровой — ибо, как ты правильно сказал, работает и приносит деньги — и выносится официальный запрет на любое изменение,
MSS>Метание из крайности в крайность.
Тем не менее это — примеры из реальной жизни реальных (и успешных экономически — а этого абсолютному большинству менеджеров достаточно, чтобы следовать этой практике) саппортных проектов.
Здравствуйте, <Аноним>, Вы писали:
А>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода. А>Качество кода обещает быть далеко не лучшим (мол хороший код и так не нужно рефакторить). А>Обычно хреновый код я либо не трогаю, либо полностью переписываю Тут ни того ни другого явно не выйдет...
А>Просьба к опытным программерам: посоветуйте, стоит в это лезть или нет? Насколько это сложнее например в сравнении с написанием нового кода?
А>ЗЫ остальные пункты новой работы меня полностью устраивают: лучше процесс, офис, соцпакет, зарплата...
Я ни в коей мере не считаю себя опытным. Но имхо (и из собственного опыта) рефакторинг это очень интересно -- не путать с поддеркой существующего проекта.
Я бы влез
Здравствуйте, chipsеt, Вы писали:
C>Здравствуйте, <Аноним>, Вы писали:
А>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода.
C>Я ни в коей мере не считаю себя опытным. Но имхо (и из собственного опыта) рефакторинг это очень интересно -- не путать с поддеркой существующего проекта.
Ты всерьез думаешь, что одно бывает без другого?
Вот ты сам подумай, зачем бизнесу тратить ресурсы на "рефакторинг и приведение в порядок" кода, который не предполагается поддерживать?
Одно дело, когда говорят: "Ускорьте-ка нам эту систему в пять раз и распараллельте на 50 компов" и еще что-то в этом роде, тогда ясна конечная цель рефакторинга и тогда действительно можно браться и работа действительно может быть интересной.
Но в формулировке "привести код в порядок" это, имхо, может означать только "нам нужен кто-нть, чтоб ориентировался в коде и был на подхвате, когда нужно будет все это активно поддерживать". Причем, вполне возможно, что задачи поддержки уже готовы и тебе просто скажут: "рефакторинг — это все хорошо, и ты обязательно займешься им, когда пофиксишь вот эти 50 багов" и в результате к реальному рефакторингу ты приступишь года через три, если не сбежишь раньше.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, chipsеt, Вы писали:
C>>Здравствуйте, <Аноним>, Вы писали:
А>>>Предлагают работу, которая заключается в рефакторинге и приведению в порядок тонн чужого кода.
C>>Я ни в коей мере не считаю себя опытным. Но имхо (и из собственного опыта) рефакторинг это очень интересно -- не путать с поддеркой существующего проекта.
J>Ты всерьез думаешь, что одно бывает без другого?
Поддержка, имхо, это добавление новых фич и фиксанье багов.
Рефакторинг, имхо, это переделка кода в нормальный вид.
Т.е. либо вкалываем больному стимулятор, либо лечим его
J>Вот ты сам подумай, зачем бизнесу тратить ресурсы на "рефакторинг и приведение в порядок" кода, который не предполагается поддерживать?
J>Одно дело, когда говорят: "Ускорьте-ка нам эту систему в пять раз и распараллельте на 50 компов" и еще что-то в этом роде, тогда ясна конечная цель рефакторинга и тогда действительно можно браться и работа действительно может быть интересной. J>Но в формулировке "привести код в порядок" это, имхо, может означать только "нам нужен кто-нть, чтоб ориентировался в коде и был на подхвате, когда нужно будет все это активно поддерживать". Причем, вполне возможно, что задачи поддержки уже готовы и тебе просто скажут: "рефакторинг — это все хорошо, и ты обязательно займешься им, когда пофиксишь вот эти 50 багов" и в результате к реальному рефакторингу ты приступишь года через три, если не сбежишь раньше.
Здравствуйте, Maxim S. Shatskih, Вы писали:
DM>>Легаси код — это код написанный (может и недавно) предыдущей командой, из которой почти никого не осталось MSS>Определить в общем можно как угодно, но для меня слово legacy стоит где-то рядом со словом obsolete. То, что будет подвергаться тотальной переделке в обозримом будущем.
MSS>Если код не планируется весь глубоко рефакторить — то зачем его называть legacy?
Имхо, ты намеренно или ненамеренно путаешь два термина: "legacy" — это "старое, работает, полезное", "obsolete" — просто таки дословно "старое, просто лежит, нигде не работает". Последнее рефакторить смысла нет — оно ведь все равно не работает в живой системе. В смысле, в живой системе оно никак не используется или его просто вообще нет — есть ведь целый вагон такого кода в старых проектах. Тратить время на его рефакторинг?
А вот тратить время на legacy приходится по разным причинам: обычно просто для того чтобы внедрить — не "приекрутить слева", а именно "внедрить как часть системы" — что-то новое, для чего придется так или иначе изменить старое — иногда довольно сильно. имхо.
Тут ни того ни другого явно не выйдет...
"Всё что не убивает нас, делает нас сильнее..."
